Recenlty we have replaced Cisco router with ASA at a branch office, This ASA also has IPSEC tunnel to my head office.
WLC is located behind router at the head office and AP is at the brach office located behind Firewall.
Now AP is not getting registered to WLC.Earlier when we had router at the brach site everything was working as per expectation.
Below is the topology:-
AP>>>ASA<<IPSEC TUNNEL> Router>>>WLC
I put Capture at the asa and could see traffic coming from AP however there is no any return traffic from WLC. I put Access list at the exit interface of the router(at the head office) putting AP ip as a source and WLC as a destination there is no hit counts.
1- Do we need to have any special ipsec ocnfiguration for this?
2- there is no NAT and inspection rule in the firewall.
i am not sure if this a firewall issue, i am seeking help as might someone here already have faced similar issue.
If your firewall is currently configured to allow traffic only from access points that use LWAPP, you must change the rules of the firewall to allow traffic from access points that use CAPWAP.
Make sure that the CAPWAP UDP ports 5246 and 5247 (similar to the LWAPP UDP ports 12222 and 12223) are enabled and are not blocked by an intermediate device that could prevent an access point from joining the controller.
If access control lists (ACLs) are in the control path between the controller and its access points, you need to open new protocol ports to prevent access points from being stranded.
The access points use a random UDP source port to reach these destination ports on the controller. In controller software release 5.2, LWAPP was removed and replaced by CAPWAP, but if you have a new out-of-the-box access point, it could try to use LWAPP to contact the controller before it downloads the CAPWAP image from the controller. Once the access point downloads the CAPWAP image from the controller, it uses only CAPWAP to communicate with the controller.
Note: After 60 seconds of trying to join a controller with CAPWAP, the access point falls back to using LWAPP. If it cannot find a controller using LWAPP within 60 seconds, it tries again to join a controller using CAPWAP. The access point repeats this cycle of switching from CAPWAP to LWAPP and back again every 60 seconds until it joins a controller.
An access point with the LWAPP recovery image (an access point converted from autonomous mode or an out-of-the-box access point) uses only LWAPP to try to join a controller before it downloads the CAPWAP image from the controller.
This is because of Cisco bug ID CSCsd94967. LWAPP APs might fail to join a WLC. If the LWAPP join request is larger than 1500 bytes, LWAPP must fragment the LWAPP join request. The logic for all LWAPP APs is that the size of the first fragment is 1500 bytes (including IP and UDP header) and the second fragment is 54 bytes (including IP and UDP header). If the network between the LWAPP APs and WLC has a MTU size less than 1500 (as might be encountered when using a tunneling protocol such as IPsec VPN, GRE, MPLS, etc.), WLC cannot handle the LWAPP join request.
You will encounter this problem under these conditions:
WLC that runs version 3.2 software or earlier
Network path MTU between the AP and WLC is less than 1500 bytes
In order to resolve this issue, use any one of these options:
Upgrade to WLC software 4.0, if the platform supports it. In WLC version 4.0, this problem is fixed by allowing the LWAPP tunnel to reassemble up to 4 fragments.
Increase the network path MTU to 1500 bytes.
Use 1030 REAPs for the locations reachable via low MTU paths. REAP LWAPP connections to 1030 APs have been modified to handle this situation by reducing the MTU used for REAP mode.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...