Cisco CAPWAP AP stuck in Discovery

[KevinJB]

Hi All,

Has anyone had problems with CAPWAP AP's separated from the WLC by a PA-220 firewall get stuck in a DISCOVERY OperationState?

>show capwap client rcb
AdminState : ADMIN_ENABLED
OperationState : DISCOVERY
Name : ***
SwVer : 8.5.151.0
HwVer : 1.0.0.0
MwarApMgrIp : 10.1.1.2
MwarName : CISCO-LWAPP-CONTROLLER
MwarHwVer : 0.0.0.0
Location : ***
ApMode : FlexConnect
ApSubMode : Not Configured
CAPWAP Path MTU : 1421
CAPWAP UDP-Lite : Enabled
IP Prefer-mode : IPv4
AP Link DTLS Encryption : OFF
AP TCP MSS Adjust : Enabled
AP TCP MSS size : 1250
LinkAuditing : disabled
Efficient Upgrade State : Disabled
Flex Group Name : ***
AP Group Name : default-group
Cisco Trustsec Config
AP Inline Tagging Mode : Disabled
AP Sgacl Enforcement : Disabled
AP Override Status : Disabled

If I do a clear session all filter source <IP of AP> the AP will shortly come online again so it does appear to be the PA220 that's causing the problem.

>show capwap client rcb
AdminState : ADMIN_ENABLED
OperationState : UP

Even when the AP is offline I can ping the WLC just fine and interestingly if I add application capwap to the clear session filter it doesn't come back up.

We did create an application-override rule for the capwap traffic but that hasn't helped and since clearing on the capwap session doesn't help and there isn't any other session from that IP I am very confused.

Thanks in advance for any suggestions will also open a TAC case but they seem to take so long to respond these days with COVID and all.

Kevin

[BPry]

@KevinJB,

You honestly shouldn't even need an application-override entry to keep this operational and have it identified properly. CAPWAP is easily enabled solely by setting the application as capwap and setting the service to application-default without any sort of override in place. You aren't performing any sort of NAT on the traffic are you? 

[KevinJB]

Nope, there is no NAT occurring to this traffic, it gets back to the WLC via a IPSec SDWAN Tunnel. Interestingly from the debugs it would appear the WLC is receiving the join from the client, it's the reply that never makes it back to the AP. Also since this was usually affecting one AP in particular I tried shutting down that one AP yesterday, but the problem just reoccurred on a different AP later that day.

[BPry]

@KevinJB,

So if the CAPWAP join request doesn't get a response that AP should sit there and continue to try and restart that CAPWAP discovery and join process repeatedly. Is the WLC not responding to any of those further join requests? I would take a capture from the WLC and see if it's responding to those join requests at all or not. 

[joseph.chen]

@KevinJB I'm having the same issue you're describing over SDWAN on a PA-220. Were you able to get it working?

[KevinJB]

Exact same situation, we had to create an application override:

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClVLCA0

create an objects -> applications called capwap-override

Under Advanced Tab, Scanning untick all (maybe default?) - file types, viruses and data patterns

and then under policies -> application override create:

capwap-override

Source Zone: name of zone your AP's are in

Destination Zone: zone-to-hub

Destination Address: IP of WLC

Protocol/Application:

UDP

Port: 5246-5247

Application: capwap-override

However after this we are still having some weird issues with wireless but having difficulty nailing down if they are related to connection reliability or more widespread so keen to hear back on your experience after making these changes.

[joseph.chen]

Thanks for the information.  Since the issue for us only started after we added a 2nd internet circuit, on the SDWAN policy, we classified CAPWAP  traffic to use a Top Down traffic distribution profile instead of best availability and it is working fine now. 

Policies>SDWAN

capwap SDWAN policy

SourceZone:  zone where your AP is

Source address:   IP of your AP

Destination address:  IP of WLC or Any

Application:  capwap

Not sure how your connections are configured but this seemed to work for us.