Auto key keep alive and VPN uptime

[Peddy1976]

Hi all,

I know that auto key keep alive is usefull to keep the VPN phase2 UP. My doubt is if this parameter must be enabled on both sides or it is enough to set it up only on one of the two peer.

Another question regard VPN Uptime under the Monitor IPsec section: with version 5.6 this field is no longer available. Is there another way to see it? Maybe through the console.

Many thanks,

Maurizio

[daac]

Hello I have the same doubt someone could give us a hand about whether it is necessary to apply it at both ends the   keepalive auto-negotiate Thank you

[emnoc]

I will not hurt. Keep in mind SAs are bi-directional and enabling on your end ensure SA from FGT-2-<whatever> is  bringing up the phase2 SAs regardless of traffic

Now auto-negotiate is a 2nd method but auto-keyalive is the recommended and your SA ( from your perspective ) will always be up phase2 negotiations are correct.

[ede_pfau]

Some more background information.

The 'keepalive' option is necessary to trigger the calculations of the SA keys in phase2 just before they timeout. As SA lifetimes are not synchronized in any way on both sides of a VPN tunnel it it advisable to enable the 'keepalive' option on both devices. Otherwise, one side might timeout while the other still is within it's lifetime. This would lead to a tunnel failure (tunnel down), probably but not necessarily followed by a full re-negotiation (see next), causing some data loss and SNMP traps etc. Things you would want to avoid.

Recalculation of an SA triggers a (small) re-negotiation between tunnel endpoints which usually is not noticed except for in the logs. But this is not comparable or equal to a full tunnel negotiation. The parameter 'auto-negotiate' is meant to trigger a tunnel build-up even in the absence of data trying to flow across the tunnel. (Sessions for the remote side of the tunnel will ALWAYS trigger a tunnel negotiation if the tunnel is down). As the status 'tunnel is UP' is valid for both ends only one device needs to be configured for auto-negotiation if you desire to have the tunnel always up, even without data transport. While the tunnel is up, data can immediately be routed across without any delay or packet loss.