Wireless Access

Reply
Occasional Contributor II

IPSec Failing for RAPs and CAPs - Control Plane Security

Hi,

 

We are currently setting up a new greenfield Aruba deployment with a 7205 controller terminating both RAPs and CAPs.

 

We have an active open case with TAC for days now and still trying to troubleshoot why the APs are not coming up correctly.

 

There is a firewall in path at the datacentre where the controller has been deployed between the CAPs @ the branches and the RAPs but the policy is currently an IP any to and from the controller (to elminate the FW being the problem) - we do not see any denies and do see an active session in the session table.

 

The IPSEC tunnel seems to be flapping constantly - trauling through the logs I'm seeing the below for the CAPs.

 

Sep 7 21:54:13 :103063:  <3960> <DBUG> |ike|  192.168.2.88:4500-> ikev2_same_sa:
Sep 7 21:54:13 :103063:  <3960> <DBUG> |ike|  192.168.2.88:4500->   Cookies : Initiator cookie:dbb0bcbf2b4a345c new sa Initiator cookie:668ed1df46d25865
Sep 7 21:54:13 :103063:  <3960> <DBUG> |ike|  192.168.2.88:4500-> ikev2_same_sa: compareResult not equal for Initiator cookies

 

The RAPs connect to the controller look to go through IPSEC phase 1 and phase 2, get an IP address from the vpdn pool and then fall over.

 

show datapath session | include 4500
220.244.129.186 10.160.0.20     17   36079 4500   0/0     0    0   0   pc0         32   11         1504       FC
220.244.129.186 10.160.0.20     17   31270 4500   1/0     0    0   0   pc0         1    8          3480       FC
10.160.0.20     220.244.129.186 17   4500  36079  0/0     0    0   1   pc0         32   0          0          F
10.160.0.20     220.244.129.186 17   4500  31270  0/0     0    0   0   pc0         1    9          6557       F

 

show crypto ipsec sa peer 220.244.129.186

 Initiator IP: 220.244.129.186
 Responder IP: 10.160.0.20
 Initiator: No
 SA Creation Date: Thu Sep  7 23:02:47 2017
 Life secs: 7200
 Exchange Type: IKE_SA (IKEV2)
 Phase2 Transform:Encryption Alg: AES 256 Authentication Alg: SHA1
 Encapsulation Mode Tunnel
 IP Compression Disabled
 PFS: no
 IN SPI: 3AE17800, OUT SPI: 98729000
 CFG Inner-IP 10.160.17.110
 Responder IP: 10.160.0.20


show crypto ipsec sa peer 220.244.129.186

 Initiator IP: 220.244.129.186
 Responder IP: 10.160.0.20
 Initiator: No
 SA Creation Date: Thu Sep  7 23:04:16 2017
 Life secs: 7200
 Exchange Type: IKE_SA (IKEV2)
 Phase2 Transform:Encryption Alg: AES 256 Authentication Alg: SHA1
 Encapsulation Mode Tunnel
 IP Compression Disabled
 PFS: no
 IN SPI: 5B81F700, OUT SPI: DBC800
 CFG Inner-IP 10.160.17.111

 Responder IP: 10.160.0.20

 

Notice that due the IPSEC flapping I can never ping the inner IP of the RAP and they rotate through the RAP pool addressing - notice the Inner-IP change above.

 

Does anyone have any ideas? I have followed the following to no avail...

 

http://community.arubanetworks.com/t5/Controller-Based-WLANs/Understanding-and-Troubleshooting-IPSec-issues/ta-p/240527

 

http://www.arubanetworks.com/techdocs/ArubaOS_65x_WebHelp/Web_Help_Index.htm#ArubaFrameStyles/Firewall_Port_Info/Communication_Between__D.htm

 

http://community.arubanetworks.com/t5/Controller-Based-WLANs/How-do-I-troubleshoot-RAP-in-ArubaOS/ta-p/178634

 

Guru Elite

Re: IPSec Failing for RAPs and CAPs - Control Plane Security

I would put an AP on the same side of the firewall as the controller just to test.



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Occasional Contributor II

Re: IPSec Failing for RAPs and CAPs - Control Plane Security

Hi,

 

thanks for the review/reply. I've done this with a PoE injector at the datacentre and the AP came up, both as a RAP and as a CAP with control plane sec on.

 

I've also turned off CPSec and the campus AP comes up fine.

 

:(

 

 

 

 

Guru Elite

Re: IPSec Failing for RAPs and CAPs - Control Plane Security

RAPs can survive a nat boundary, as long as it is a 1:1 NAT.  CPSEC APs will not survive any type of NAT boundary because it uses GRE.  Put your controller on the same side of the firewall as your APS.  It is much easier to poke a couple holes for SSH, Radius than it is for all of the ports between APs and the controller.



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Occasional Contributor II

Re: IPSec Failing for RAPs and CAPs - Control Plane Security

The firewall is the datacentres gateway to the WAN and the Internet. There is no NAT occuring on the WAN leg into the wireless controller.

 

Highlighted
Guru Elite

Re: IPSec Failing for RAPs and CAPs - Control Plane Security

I would continue to work with TAC.  There is not enough information in your post to easily determine what is wrong.



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Occasional Contributor II

Re: IPSec Failing for RAPs and CAPs - Control Plane Security


NicholasH wrote:

The firewall is the datacentres gateway to the WAN and the Internet. There is no NAT occuring on the WAN leg into the wireless controller.

 

given no nat, have you inadvertantly reused the same address space for the IPs of the APs at each site, e.g. two CAP or RAP without NAT at two different locations but each location has the same dhcp scope being served up? (Obviously the same address space can be used if there is a NAT involved)

Occasional Contributor II

Re: IPSec Failing for RAPs and CAPs - Control Plane Security

Hi,

 

thanks for the reply, no the WAN connectivity comes over a private link and routes natively to 192.168 addressing.

 

the RAPs NAT to the wireless controllers master IP and use a seperate pool address of 1.1.1.1-254 for the moment.

 

 

Occasional Contributor II

Re: IPSec Failing for RAPs and CAPs - Control Plane Security

a bit confusing as to how the IPs are all laid out, can you hack up an ascii art that shows how you have it all glued together? It seems that you may have a situation where something is getting overlapped, and/or the firewall port forward is doing bad things. Some sort of stick diagram may help to clarify/narrow that down.

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: