- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
04-24-2017 02:48 AM
Hi,
We have a site A with PAN Firewall and site B with Cisco 5510 ASA. IPsec VPN tunnel is built between these 2 sites.
In certain occasions, we have the ISP site B network link up, but the users is experiencing no internet in siteB. As it is only a single link, the only way we did is to reboot the Cisco ASA appliance and the user is able to access the internet again.
On the PAN firewall side, there is a constant ping and monitoring to the ASA and applications like outlook and AD servers are constantly exchanging/syncing AD information, etc. So, it means that there should be no VPN idle timout for traffic traversing across the VPN tunnel.
I am confused and curious to know what is happening during these period of internet outage at site B in the cisco ASA appliance. Is there any related case happening like this before ?
Regards
Lawrence
04-24-2017 01:08 PM
Not sure it is your issue but Palo Alto has DPD enabled by default so Palo will send ISAKMP R-U-THERE packets to VPN peer.
It other side does not have DPD enabled then it will not reply with ISAKMP R-U-THERE-ACK.
Palo thinks that peer is down and will bring VPN tunnel down.
Tunnel should be re-established as soon as there is interesting traffic but it can interrupt voip calls etc.
04-24-2017 03:25 AM - edited 04-26-2017 03:03 AM
Hi,
Did you check for the possible reasons before the firewall reboot? Like if the client still was able to resolve the DNS? Were they still able to ping DG? ASA logs? How about you trying to ping some servers from site A > site B.
04-24-2017 06:54 AM
Hi,
Unfortunately, we did not ask the client in Site B to ping to the DG and check for DNS resolution to see if it is working.
However, from Site A, we try to ping to one of the server ip address in Site B. The ping timed got timeout.
At that time, we are not able to login to access the ASA.
04-24-2017 01:08 PM
Not sure it is your issue but Palo Alto has DPD enabled by default so Palo will send ISAKMP R-U-THERE packets to VPN peer.
It other side does not have DPD enabled then it will not reply with ISAKMP R-U-THERE-ACK.
Palo thinks that peer is down and will bring VPN tunnel down.
Tunnel should be re-established as soon as there is interesting traffic but it can interrupt voip calls etc.
04-24-2017 02:30 PM
I would really look at the ike logs and see what the issue is; there are a lot of possible situations that could be going on here. Do you have any idea how long the traffic actually processes before the issue presents itself, could you possibly just have a key lifetime mismatch?
04-25-2017 09:01 AM
Hi,
For certain reasons, to maintain confidentality, i am not able to re-produce the logs here. But there is no lifetimes mistmatch. For IKE Phase 1. lifetime is 24 hrs on both PAN and ASA side. and Phase 2 lifetime is 8 hrs.
In the ASA configs, i have a vpn-idle-timeout 30 mins. Could this be one of the reason that the tunnel is teared down after 30 mins of inactivity? i have intended to configure this to "vpn-idle-timeoute none" instead. will this helps?
Regards
04-25-2017 09:06 AM - edited 04-25-2017 09:25 AM
As far as l am aware P1 and P2 timers will be negotiated to the lower value between the peers and will be the same in the end :0 Winning the peer who is proposing a lower value. Not sure about the idle timeout value. If you have a monitoring future enable that means that the tunnel timer should be refreshed after every check (if l am not mistaken).
04-26-2017 08:18 AM
Hi
Right now, the ASA firewall is up and traffic is passing through. We did not check, during that time, because there is no remote IT personnal there. Only office users there.
I will take note of the above mentioned to check if the same incident happens again.
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!