Capwap Active Sessions in 2 ISP topology

[afalfaro]

Kind regards

Team

We currently have a topology in which the remote site has 2 VPNS configured (each VPN established by a different channel). The VPNs are configured against our Perimeter FW and the switching between them is done with Path Monitoring. The remote site has some Access Points that established a session (Capwap) against a controller that is located behind our Perimeter FW. The situation we present is the following.

1. When the APs connect to the controller, a Capwap session is established through tunnel 1. (Everything is fine up to there)
2. When tunnel 1 goes down, the new traffic begins to be routed through tunnel 2, however, we have seen that the Capwap sessions are being activated on tunnel 1 causing the APs to lose connectivity with the controller and the remote site's wifi is affected.
3. The way to solve this has been manually clearing all the Capwap sessions that were active so that when it tries to establish the capwap with the controller again it does so through the tunnel active at the time.

According to the evidence, we see that there are active Capwap sessions that will last up to 2 days or even more.

The question is, is there any way to modify the Capwap application timers so that the FW identifies or closes those active sessions?

Or what possible solutions could be evaluated?

[TomYoung · Accepted solution]

Hi @afalfaro ,

There is a way to override application timeouts with custom services.  https://docs.paloaltonetworks.com/pan-os/11-1/pan-os-admin/app-id/service-based-session-timeouts

Here is another doc that describes your problem very well and provides a unique solution of sending an API call to itself!  https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000HBmqCAG  I would clear all sessions filtered by destination-port, e.g. your tunnel interface, instead of UDP, but it is a great doc nonetheless.

Please let us know if any of these solutions work for you!

Thanks,

Tom

[afalfaro]

Cordial greetings

@TomYoung 

I have read the document you have provided and it is excellent. That is exactly what is happening to us at the moment. I will perform the proper configurations and tests on Monday and will keep you informed of the results.

Thank you very much for the help.

[TomYoung]

Hi @afalfaro ,

Were you able to fix your problem?

I have a coworker who ran into the same problem.  What he did was create a security policy rule that blocked traffic to the destination out the unwanted interface.  If you never want your CAPWAP traffic to go out tunnel 2, then you could do that.  The invalid sessions would never setup.

For others that may experience this issue with a default route on the NGFW, a practice carried over from routers is to create null routes for RFC1918 addresses so that internal traffic will never follow the default route.

Those are 2 more options that could be used to solve the problem.

Thanks,

Tom

[afalfaro]

Cordial greetings

@TomYoung 

I am setting up a lab environment, since in the production FWs where we had planned to do it, it has not been possible because one of the channels where the tunnel 2 goes is down, so the traffic switching test would not be done.

Now, since it is essential to have this high availability, I can not create the rule you mention, because I need the traffic to travel through one of the tunnels as long as one channel is down to avoid asymmetric traffic.

As soon as I have some progress I will let you know, hopefully this week.

[afalfaro]

Cordial greetings

@TomYoung 

I have performed the corresponding tests and they have been successful. I simulated exactly the same scenario and configured the HTTP profile and set the event logs to the following (( subtype eq 'routing' ) and ( eventid eq 'path-monitor-failure' )) or (( subtype eq 'routing' ) and ( eventid eq 'path-monitor-recovery' )) Taking into account that we have configured the path monitoring to check the vpns routes, in the same way, set the command to be only for Capwap protocol.

In the same way, and being restrictive to the user of the api I applied a role with only permission to Operational Requests, because I realized that it was not necessary to leave the device admin role as it says in the KB that you provided me.

Thank you very much for all your collaboration and professional support. Your proposal has been an effective solution