3702i AP Won't Join 5508 Over VPN

[davidcarter1971]

I have a 3702i that I have joined to my 5508 WLC and primed.  When I move the AP to the branch location via VPN tunnel the AP won't connect/join to the WLC.  I have both DNS set for cisco-capwap-controller, and option 43 set on the DHCP scope.  The AP correctly obtains the WLC IP but when it tries to connect I receive the following error:

%CAPWAP-3 EVENTLOG: Could Not discover any MWAR.

I have tested communication from branch site to HQ via ping.  A PC on the branch network (AP Subnet), can ping the HQ network, WLC Network, and WLC.  The AP can ping the HQ network, WLC Network, but not the WLC.

Forgot to add that the 5508 is running 8.0.133.0 and the AP is running 15.3(3)JA8$

Any help appreciated. 

[davidcarter1971]

Forgot to add that the 5508 is running 8.0.133.0 and the AP is running 15.3(3)JA8$

[Cristian Matei]

Hi,

 Connect to AP console, authenticate, reboot and post the complete boot output.

Regards,

Cristian Matei.

[davidcarter1971]

Hello Cristian,

Unfortunately this had to be deployed less than 24 hours after I posted.  I am currently unable to troubleshoot more but will if I can find equipment to replicate the issue.  The resolution I found was to use a 3602.  It worked immediately after I plugged it in.  As an extra note the solution isn't viable due to low speeds over wireless.  I'm guessing that the encryption of the SSID, encapsulation of the CAPWAP, and the encrypt/encap of the VPN tunnel is causing issues with fragmentation.  I tried modifying the MSS and it helped but it was a joke.  The wireless speeds are .3 Mbps after modifying the MSS. 

Thanks again for help and interest.  If I can lab and simulate this again I will update.

[patoberli]

NTP on the WLC enabled?
The required CAPWAP ports open?
MTU large enough?
https://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/211405-Configure-CAPWAP-Path-MTU-Discovery.html

[davidcarter1971]

Hello @patoberli,

Unfortunately this had to be deployed less than 24 hours after I posted.  I am currently unable to troubleshoot more but will if I can find equipment to replicate the issue.  The resolution I found was to use a 3602.  It worked immediately after I plugged it in.  As an extra note the solution isn't viable due to low speeds over wireless.  I'm guessing that the encryption of the SSID, encapsulation of the CAPWAP, and the encrypt/encap of the VPN tunnel is causing issues with fragmentation.  I tried modifying the MSS and it helped but it was a joke.  The wireless speeds are .3 Mbps after modifying the MSS. 

Thanks again for help and interest.  If I can lab and simulate this again I will update.

[drouleau]

Look at MTU.  IPSEC site to site has an overhead and your CAPWAP might be too big to fit in it.

[drouleau]

From Google: When IPsec is being used, it is customary to set the MTU size on the tunnel interfaces to 1,400 bytes and to set the TCP-MSS-adjust to 1,360 bytes. This can be configured in a Cisco IOS device using these commands.

[JPavonM]

I have suffered similar scenario with Meraki AutoVPN and all Cisco AP models.

Due to the way it works, Meraki AutoVPN topology uses the lower MTU in the head-ends that they see in the full topology. Cisco AP on a site with higher MTU than that on the WAN side of the head-ends negotiates local MTU with the spoke device (another Meraki MX) and will try to join using 576 / 1005 / 1485 path MTUs, plus any value received in ICMP destination unreachable packet with a fragmentation required message. In the case of Cisco C9800, they respond to such association using a packet which is 32 bytes smaller than that in use by the AP. At the end it resulted that a MTU assymetry was causing the CAPWAP tunnel to be constantly renegotiated so clients were disconnecting or unable to connect, and sometimes some APs were unable to join (CSCwc05350).

You could be suffering a similar scenario with MTU flapping so my recommendation is to upgrade to 8.5 version which supports your AP3602's, and maybe not suffering that weird behaviours. If they keep doing that, it is maybe time to consider moving forward and remove AP3602 in order to move code to 8.10 and see if that solves the issue (or deploy a virtual WLC for testing this on 8.10 and AP3702).