Cisco VPN Behind PA-3220

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Cisco VPN Behind PA-3220

L1 Bithead

We have a third-party that borrows our network to establish a VPN tunnel back to their office via a Cisco 881 ISR. We have it on a segregated guest network and it establishes an ike/ipsec tunnel back to their ASA over our internet connection.


Workstation --> Cisco 881 --> [Guest Network] --> Palo Alto FW --> Internet --> Cisco ASA 


Any time the network hiccups (or something loses power), the VPN drops and refuses to come back up for them until I go in the Session Browser on the PA and clear the stale sessions associated with the device. Rebooting the Cisco 881 does nothing. I've tried moving this device to another PA firewall (a 220) for them and the same thing happens on it. About once a week, I have to go manually clear the port 4500/500 sessions associated with their Cisco 881 IP from our firewall.


They don't seem to have this issue with any similar setups they run and we don't have the issue with any other ipsec tunnels originated from inside our network. Any idea where we should start troubleshooting this?


Cyber Elite
Cyber Elite

Good Day


You should consider seting up path monitoring on the VPN tunnel, so that there can be some icmp "hello" that will keep the tunnel up.


Help the community: Like helpful comments and mark solutions

I think you misunderstood - the VPN endpoint is not our Palo Alto firewall, so we can't apply a tunnel monitoring profile to it. We don't control either side of the tunnel (it's coming from a Cisco ISR inside our network to an ASA outside the network). We just have to clear the connections in the PA's session table each time there's a blip on the network.

Cyber Elite
Cyber Elite

Hello there.   Thank you for the clarification, and yet, the response could still be valid.  I am not sure how to do it, but there should be some vpn tunnel monitoring done on the VPN, from either side.  I think/understand that this thread may be thinking it is  is PANW issue, but it is not.   If the session is indeed intact, then the PANW is doing its job and it is up the either the client or server side (from a TCP connection perspective) to send hellos/traffic/pings, whatever.    If the SPI gets out of sync and tearing down the port 500/4500 makes sense, but again, not sure that the PANW side needs to resolved as much as fixing the issue, being the Ciscos. 

Another suggestion could be to modify the AppID to have a smaller timeout of 3600 secs (default) to something smaller (5 min?) so that you do not need to manually clear of the session tables. 

Help the community: Like helpful comments and mark solutions

Yes, I do think this is ultimately a Cisco issue, just odd that it only seems to happen for this agency when behind our firewall - I suspect they may have a config issue, maybe something with NAT-T.
The AppID timeout doesn't really seem to matter - even at the default 3600s, the sessions stay in the table indefinitely in our PA until I clear it out. It'll be offline for hours or even a day before I clear it sometimes.
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!