Problem with ipsec vpn session

[admin3r]

Hi

I hope that someone can bring some insight in to this problem.

The situation is this:

Two out of seven configured ipsec tunnels are having some kind of connection issue. Our monitoring system will notify me that the VPN connection is down. I have then tried to "ping" the inside interface of the remote firewall (Fortigate in this case), with no response as result. Followed by the basic troubleshooting steps to check Internet connectivity and if other ipsec tunnels are up and working (all other connections and tunnels are OK).

So I logged in to the main PA unit. We have a pair of PA-500 (3.1.4) in HA. Went to monitoring and clicked to open "Session Browser". Then I searched for the remote firewall's external IP address. And to my suprise it was listed. So I clicked on the X to close the session and then reloaded the page. Now a new session is listed. I then go back to "Network" and "IPSEC tunnels", and now the tunnel is up again.

This has happen on three occasions on two different ipsec tunnel connections.

The remove firewalls are all Fortigate units (different models and firmware versions). The ipsec tunnels in the PA all have their own tunnel interfaces but share IKE and IPSec crypto profiles. So all tunnels should be identical except the interface and PSK.

Regards, Marcus Feltsen

[mrajdev]

Hi Marcus,

Seems like the tunnel is getting created when the traffic is initiated from one side of the VPN peer, this could be your issue. When the tunnel fails, please check the system log equivalent of the PAN device on the IPSec peer which is the responder. From the logs you will be able to check if phase 1 is failing or phase 2.

Also when the session on the PAN for the remote VPN peer is there, can you please check the session information for the old and the new session which gets created after you clear the session. Please check what is different between the two sessions.

Suggest to upgrade to 3.1.9 if possible.Hope this helps.

Thanks

[admin3r]

Hi mrajdev

Great input! I will try to remember this the next time it happens, hopefully it will not happen again (but you never know).

Can system time play any part in this? I mean if the time would be wrong in either end.

I just went and looked in the Session Browser. If I add filter (application eq ike) then I can see 4 sessions. But there are 7 active ipsec tunnels. Two of the sessions I see is the two that I have had problems with, the other two have newer caused problems.

Any ideas on that?

I will also contact our PaloAlto partner for assistance about possibly updating to 3.1.9.

[mrajdev]

System time will not matter for VPN issue you are seeing.

Once the IPSec tunnels are up the IKE session is not needed anymore, so the IKE session will timeout, this is the reason why you see only 4 IKE sessions and have 7 IPSec tunnels up.

Thanks

[friento]

I would check for time-out setting on the third party VPN. We had similar issue with Cisco ASA and Palo.

[admin3r]

I have verified the time-out settings on both Phase1 and Phase2, and they are both correctly set.

I will however upgrade the firmware on the remote firewall (a Fortigate unit), just to see if I can see any difference intraffic/sessions.

mrajdev: if the IKE sessions time-out, then why doesn't all of them time out?

I have never digg this deep in to how IKE and IPSec sessions are established.

[admin3r]

On the PA it is possible to choose between Days, Hours, Minutes and Seconds when defining Lifetime on the IKE crypto.

Does it matter if I define Lifetime on the PA as 1 Hour, and defined as 3600 seconds on the third-party firewall (Fortigate in this case)?

Or do I have to choose the same time definition; use seconds on both sides for example?

[mrajdev]

If there is traffic on a IKE session then the session will not timeout, I would think if you have DPD enabled on either end it would keep the IKE session. That would be one reason the other reason would be that the IKE regnegotiation happened recently due to which you see that IKE session. Hope this helps.

Thanks

[admin3r]

We do indeed have DPD enabled on both ends.

We will upgrade to PANOS 4.0.4 next week. So I hope that I will not "see" this problem any more after that.

Thanks

[admin3r]

Upgrade to PANOS 4.0.4 seems to have solved the issue.