IPSEC tunnel Phase-2

[Sujanya]

We have created an tunnel with SAP and as per their suggestion we have disabled tunnel monitoring, keepalive settings from our end. It is IKEV2 tunnel.

We noticed that after sometime due to traffic not flowing suddenly Phase-2 is going down, as soon as it goes down we were seeing the issue in connectivity.

As soon as manually trigger the tunnel and if the tunnel comes up, connectivity works again. Any suggestion here.

[OtakarKlier]

Hello,

Its only a guess, but I think it could be the other side dropping the tunnel due to lack of traffic? I typically use keep alives for this, not sure why they require it disabled.

Regards,

[Sujanya]

Hi @OtakarKlier ,

Thanks for responding. We are not able to ping the customer gateway and as well as network as ping is not allowed from them. Will the keepalive still works in that situation.

[OtakarKlier]

Hello,

The keepalive should still send a ping even if they drop or block it on their end. Meaning that there is traffic on the tunnel. But sounds like their side that might be dropping it? What do the logs state for the tunnel?

Regards,

[Sujanya]

Hi @OtakarKlier ,

Thanks for your response. We also noticing that there is no ike-phase-1 delete message being send from Palo-Alto to peer end device.

Whenever we were seeing 1 IKE SA has been created at Palo-Alto , there would be multiple IKE-SA is visible at the peer Cisco router end.

[Raido_Rattameister]

How come can you see issues with connectivity if there is no traffic on the tunnel?

"traffic not flowing suddenly Phase-2 is going down, as soon as it goes down we were seeing the issue in connectivity"

If you see issues with connectivity it means you do have traffic on the tunnel.

This points to either different Phase1/2 timeout values or their side pulling down tunnel due DPD/Liveness check.

[Sujanya]

Hi @Raido_Rattameister ,

Yes we can see via GUI that IPSEC tunnel info is showing red but the IKE Info is showing always green. In this situation if any traffic has been initiated by backend server communication is allowed with no return traffic. 

There is no keepalive and tunnel monitor is enabled at both the ends. The interested traffic is the telnet traffic which will be randomly initiated by user.

[Raido_Rattameister]

If peer site does not reply to pings then it would be best to shut down tunnel monitor.

Otherwise Palo thinks that tunnel is down as no tunnel monitor replies.

If there is interesting traffic then phase 2 is negotiated and tunnel stays up (or comes up if down).

If you really need tunnel to stay up even if no interesting traffic and remote side is configured not to reply to pings then configure extra fake static route let's say /32 to one of IPs at remote side with ping interval 60 (it is biggest you can set).

[Sujanya]

Actually there is no tunnel-monitor or Keepalive configured at both the end. We have kept the continues ping as well from the backend server to the other end IP address to keep the tunnel active. But exactly after 1 hour ( lifespan set for IPSEC phase 2 ) tunnel went down and we started getting timeout for tunnel.

After I using the below two commands , tunnel came up again and ping started working fine.

test vpn ike-sa gateway <gateway_name>

show vpn ike-sa gateway <gateway_name>

test vpn ipsec-sa tunnel <tunnel_name>

show vpn ipsec-sa tunnel <tunnel_name>

[Raido_Rattameister]

On Palo side default Phase 2 timeout is 1 hour.

Seems like VPN settings don't match on both sides.

Other side probably has longer than 1 hour timeout set for Phase 2.

[Sujanya]

Hi @Raido_Rattameister , Peer end engineer team confirmed that phase-2 lifespan is set for 1 hour only. 

Also they have observed one more thing whenever the tunnel goes down, we are using test commands ( both for gateway and ipsec tunnel) to manually bring up the tunnel. We are seeing our phase-1 IKE-SA is being refreshed with newer-spi, but at the peer end which is cisco router 1000 there were multiple SA being generated( older SA is not terminating until they clear it manually)

[Sujanya]

Hi @Raido_Rattameister ,

Also we noticed that even though we are pushing the DHgroup value as 16 from Panorama , Palo-alto firewall taking the configuration at its end as DH14. and as per the communication with Cisco router end we asked them to keep the tunnel parameters as 16. Do you feel will it case any issue.

[Raido_Rattameister]

You can enable debug on this VPN tunnel and ikemgr.log shows what timeouts other peer negotiates with.

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClcKCAS

Set Palo side to be passive so other side initiates connection.

[Sujanya]

Hi @Raido_Rattameister ,

The issue was fixed when we set the DHGroup value as 14 in the other end as well.

One Thing to notice and need clarity is, Will Palo-Alto with 440 model and PAN-OS version 10.1.6-h6 will not supports DHGroup 16 ??? I was able to see only 1,2,5,14, 19 and 20 

[Raido_Rattameister · Accepted solution]

10.2 has DH group 16.