Wireless Access

Background:

AOS 8.6.0.2

AP 207 (RAP)

*  This RAP is directly connected to the internet. No NAT on the AP side.

2 7005 Clustered. NAT IP on this member is set to the external IP of my PAN.

Firewall: PAN

* DNAT is setup on the PAN for my external IP pointing to the IP of one of the controllers (internal IP). Security policy is in place for ipsec-esp-sa (UDP 4500)

Basic setup on the controller side. . no LMS settings, L2TP pool and a VAP profile in the AP group.

Question 1:

When I setup the Cluster-RAP-Pool at the MM level, the controller throws an error that no l2tp addresses are available. I thought this was required for clusters. However, it doesn't work, and if I set it at the /md level, an IP address is found and the RAP moves onto authentication.

Question 2:

The RAP finds the controller, appears to authenticate successfully using a certificate, and builds the IPSEC tunnel. I can even occasionally catch it in the user-table. When I catch it in the user-table it gets the role of sys-ap-role & default-rap roles.

192.168.2.200   00:00:00:00:00:00  34:fc:b9:CC:EE:FF  sys-ap-role     00:00:00    VPN            RAP.IP  N/A                                                             default-rap      tunnel                            WIRELESS   Internal        0 (0)       OFF/0/0

Shortly (a couple seconds) after that the IPSEC tunnel is torn down and the process starts over. I don't see anything in the debugging logs on the controller. I'm wondering if the PAN is breaking it somehow because I'm seeing zero issues in the debug logs.

Jul 2 17:59:54 :103063:  <3339> <DBUG> |ike|     ESP spi=ede00300 <CON.IP> << <RAP.IP> udp-enc(62585)*  spd=0(0) exp=7200 secs  auth=
Jul 2 17:59:54 :103063:  <3339> <DBUG> |ike|   IKE_addIPsecKey k:0 swapping spi/dst/src
Jul 2 17:59:54 :103063:  <3339> <DBUG> |ike|   IKE_addIPsecKey k:0
Jul 2 17:59:54 :103063:  <3339> <DBUG> |ike|   IKE_addIPsecKey spi:a80d6100  opp-spi:ede00300   src:<CON.IP>   dst:<RAP.IP>    initiator:NO   out:1
Jul 2 17:59:54 :103063:  <3339> <DBUG> |ike|   IPSEC_keyAddEx spdid:0
Jul 2 17:59:54 :103063:  <3339> <DBUG> |ike|   IPSEC_newSa Added outbound-hash for pxSa 0x978cec IP:<RAP.IP> status:0 inbound:0  hash:3023728366
Jul 2 17:59:54 :103063:  <3339> <DBUG> |ike|   IPSEC_newSa SADB:0x978cec Proto:50 SPI:a80d6100 OppSPI:ede00300 Dst:<RAP.IP> Src:<CON.IP>  natt:62585 Dport:0 Sport:0 Oprot:0 Mode:2 Inner:192.168.2.200 DstIP:0.0.0.0 DstIPe:255.255.255.25
Jul 2 17:59:54 :103076:  <3339> <INFO> |ike|  IKEv2 IPSEC Tunnel created for peer <RAP.IP>:62585
Jul 2 17:59:54 :103063:  <3339> <DBUG> |ike|   arubaIPSecSetKeys:IPSECKEY proto:50 ospi:a80d6100 ispi:ede00300 auth:2 len:20 enc:4 len:32 add:1 out:1 
Jul 2 17:59:54 :103063:  <3339> <DBUG> |ike|   DP SA out:1 natt:1 mode:1 proto:1 cipher:4 auth:2 spi:a80d6100 oppspi:ede00300 esrc:<CON.IP> edst:<RAP.IP> dstnet:192.168.2.200 dstmask:0.0.0.0 nattport:62585 trust:0 dpd:0 ingress:0 sacl:
Jul 2 17:59:54 :103063:  <3339> <DBUG> |ike|    Added the IPSEC SA --- DONE  !! 
Jul 2 17:59:54 :103060:  <3339> <DBUG> |ike|   ipc.c:is_HA_crypto_map_present:3090 Looking for MAP  default-ha-ipsecmap<RAP.IP>
Jul 2 17:59:54 :103063:  <3339> <DBUG> |ike|   DP SA out:0 natt:1 mode:1 proto:1 cipher:4 auth:2 spi:ede00300 oppspi:a80d6100 esrc:<RAP.IP> edst:<CON.IP> dstnet:0.0.0.0 dstmask:0.0.0.0 nattport:62585 trust:0 dpd:0 ingress:0 sacl:0 fami
Jul 2 17:59:54 :103063:  <3339> <DBUG> |ike|    Added the IPSEC SA --- DONE  !! 
Jul 2 17:59:54 :103063:  <3339> <DBUG> |ike|   sha1  encr=aes  ESP spi=a80d6100 <RAP.IP> << <CON.IP> udp-enc(62585)*  spd=0(0) exp=7200
Jul 2 17:59:54 :103078:  <3339> <INFO> |ike|  IKEv2 CHILD_SA successful for peer <RAP.IP>:62585
Jul 2 17:59:54 :103063:  <3339> <DBUG> |ike|     CHILD_SA [v2 R
Jul 2 17:59:54 :103063:  <3339> <DBUG> |ike|   cleanup_and_free_context delete ctx memory
Jul 2 17:59:54 :103063:  <3339> <DBUG> |ike|   xlp_rcv_response: Nothing to be read from cryptolib fd
Jul 2 17:59:55 :103063:  <3339> <DBUG> |ike|   ipc_fpapps_lbgroup_cfg_req Requesting lbgroup config
Jul 2 17:59:55 :103063:  <3339> <DBUG> |ike|   Sent lbgroup config req msg
Jul 2 17:59:55 :103063:  <3339> <DBUG> |ike|   ipc_fpapps_lbgroup_cfg_req Started timer for lbgroup config req msg
Jul 2 17:59:56 :103063:  <3339> <DBUG> |ike|   exchange_start_ikev2 pre-connect check duplicate mapname:default-local-master-ipsecmap
Jul 2 17:59:57 :103060:  <3339> <DBUG> |ike|   ipc.c:ipc_rcvcb:4099 Auth ip down message.ip=192.168.2.200. flags 4
Jul 2 17:59:57 :103063:  <3339> <DBUG> |ike|   IPSEC_deleteSaByInnerIPExtIP delete IPSEC SA <RAP.IP>:(inner:192.168.2.200)
Jul 2 17:59:57 :103101:  <3339> <INFO> |ike|  IPSEC SA deleted for peer <RAP.IP>
Jul 2 17:59:57 :103103:  <3339> <WARN> |ike|   IPSec SA Deletion: IPSEC_delSa SPI:a80d6100 OppSPI:ede00300 Dst:<RAP.IP> Src:<CON.IP> flags:1001 dstPort:0 srcPort:0
Jul 2 17:59:57 :103063:  <3339> <DBUG> |ike|    IPSEC_delSa: Removing spi 0xede00300 from hash table 
Jul 2 17:59:57 :103063:  <3339> <DBUG> |ike|   ipsec_spi_hash_tbl_entry_remove: Successfully removed IPSEC spi 0xede00300 from SPI hash table  
Jul 2 17:59:57 :103063:  <3339> <DBUG> |ike|   IPSEC_delSa: Removing entry from m_hashTableOutbnd. RAP: 1 Innerip: 192.168.2.200 Dst: <RAP.IP> Src: <CON.IP>
Jul 2 17:59:57 :103063:  <3339> <DBUG> |ike|   IPSEC_delSa (RESPONDER) Outgoing=1 SADB Proto:50 SPI:a80d6100 OppSPI:ede00300 Dst:<RAP.IP> Src:<CON.IP>  natt:62585 Dport:0 Sport:0 Oprot:0 Mode:2 Inner:192.168.2.200 DstIP:0.0.0.0 DstIPe:
Jul 2 17:59:57 :103063:  <3339> <DBUG> |ike|   arubaIPSecSetKeys:IPSECKEY proto:50 ospi:a80d6100 ispi:ede00300 auth:2 len:20 enc:4 len:32 add:0 out:1 
Jul 2 17:59:57 :103063:  <3339> <DBUG> |ike|   DP SA out:1 natt:1 mode:1 proto:1 cipher:4 auth:2 spi:a80d6100 oppspi:ede00300 esrc:<CON.IP> edst:<RAP.IP> dstnet:192.168.2.200 dstmask:0.0.0.0 nattport:62585 trust:0 dpd:0 ingress:0 sacl:
Jul 2 17:59:57 :103063:  <3339> <DBUG> |ike|    Deleted the IPSEC SA --- DONE  !! 
Jul 2 17:59:57 :103063:  <3339> <DBUG> |ike|   DP SA out:0 natt:1 mode:1 proto:1 cipher:4 auth:2 spi:ede00300 oppspi:a80d6100 esrc:<RAP.IP> edst:<CON.IP> dstnet:0.0.0.0 dstmask:0.0.0.0 nattport:62585 trust:0 dpd:0 ingress:0 sacl:0 fami

 
I've sanitized the logs with RAP.IP and CON.IP for the RAP and controller respectively. 

Hi Zemerick,

Are all requirement set?

• At the MM you need indeed to configure the Controller Cluster RAP Pool. The l2tp issue is possible a firmware issue, check the release notes on that and decide a update to 8.6.0.5.
• At the Managed Networks you need to whitelist the accesspoints in the RAP whitelist.
• At the Managed Device Group you need to add two RAP Public WAN IP addresses in the Controlller Cluster Profile.

Aruba also create a nice teleworkers guide due covid, did you see it allready?

https://support.arubanetworks.com/Documentation/tabid/77/DMXModule/512/Command/Core_Download/Default.aspx?EntryId=38489

Yes, I was using the guide to setup a test in my lab.

• The l2tp issue appears to be a bug in at least 8.6.0.2. I upgraded to 8.7 and now the l2tp settings are applied from the MM level.
• The RAP is whitelisted.
• The cluster nodes do have a RAP Public IP attached to each node. This is the external interface/IP of my Palo. It is being DNAT'd to one of my controller's IP. 

The setup appears to be solid. One thing I find frustrating is that there is nothing in the controller logs, even with debugging enabled, letting me know why the tunnel is being torn down.
Below you can see the IPSEC SA ---- DONE , signifying the tunnel being completed. Then a line saying Auth ip down. I'm not sure what to make of that.

Jul 3 12:19:27 :103063:  <3360> <DBUG> |ike|    Added the IPSEC SA --- DONE  !! 
Jul 3 12:19:27 :103063:  <3360> <DBUG> |ike|   sha1  encr=aes  ESP spi=40249d00 <RAP.IP> << <CON.IP> udp-enc(59066)*  spd=0(0) exp=
Jul 3 12:19:27 :103078:  <3360> <INFO> |ike|  IKEv2 CHILD_SA successful for peer <RAP.IP>:59066
Jul 3 12:19:27 :103063:  <3360> <DBUG> |ike|     CHILD_SA [v2 R
Jul 3 12:19:27 :103063:  <3360> <DBUG> |ike|   cleanup_and_free_context delete ctx memory
Jul 3 12:19:27 :103063:  <3360> <DBUG> |ike|   xlp_rcv_response: Nothing to be read from cryptolib fd
Jul 3 12:19:28 :103063:  <3360> <DBUG> |ike|   exchange_start_ikev2 pre-connect check duplicate mapname:default-local-master-ipsecmap
Jul 3 12:19:30 :103060:  <3360> <DBUG> |ike|   ipc.c:ipc_rcvcb:4134 Auth ip down message.ip=192.168.2.200. flags 4
Jul 3 12:19:30 :103063:  <3360> <DBUG> |ike|   IPSEC_deleteSaByInnerIPExtIP delete IPSEC SA <RAP.IP>:(inner:192.168.2.200)

 
I'm going to try and see what I can dig up on the PAN side. . They can be a real PIA sometimes, just dropping traffic for seemingly no reason.

Well, I've eliminated the PAN as the issue by bypassing it. Not sure what else to try. .

Well. I've got this partially working by removing a controller from the cluster. So, the RAP only points the standalone controller. Which leads me to think it was trying to establish a connection with the secondary controller, which was not reachable externally by design.

I guess my question is now: If a controller is part of a cluster is there any way to have a RAP connect to only ONE of the members? In my home lab I do not have a second static IP to give my second cluster member.

Hi Zemerick1,

• For RAP deployment in a cluster each member must have it's own WAN IP in the cluster profile.
• When having 1 WAN IP, don't use clustering at all, its not supported.
• With having 1 WAN IP you can use two controllers without clustering and use a VRRP address

See also my early presentation about this, https://community.arubanetworks.com/t5/Wireless-Access/ArubaOS8-RAP-Deployment-Non-Cluster/td-p/648571

Hope this helps you.

Gotcha. I have stood up a third controller as a VMC and this appears to function as intended. 

I wish that Aruba would rethink this deployment model. Or, add it as a feature. If a customer doesn't have two WAN IPs available, then I would never advise them to break the cluster just so they can utilize RAPs.

To add, if they don't have multiple WAN IPs, they most likely won't have the resources to spin up a 3rd, 4th, or 5th controller in the DMZ to handle RAPs.