Cisco VPN Behind PA-3220

[phite_cpso]

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?

[S.Cantwell]

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.

https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/vpns/set-up-site-to-site-vpn/set-up-tunnel...

[phite_cpso]

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.

[S.Cantwell]

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. 

[phite_cpso]

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.