MX non-Meraki peer tunnel type Iddle timeout

[josfonse]

Hi Team,

Could you please clarify what the default idle timeout is for the non-Meraki peer IPsec tunnel type and if it can be changed?

Thank you.

[alemabrahao]

I think that you are talking about the Lifetime.

Cisco Meraki products, by default, use a lifetime of 8 hours (28800 seconds) for both IKE phase 1 and IKE phase 2. 

https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-Site_VPN_Settings#IPsec_Policies

Non-Meraki VPN Peers

You can create Site-to-site VPN tunnels between a Security Appliance or a Teleworker Gateway and a Non-Meraki VPN endpoint device under the Non-Meraki VPN peers section on the Security & SD-WAN > Configure > Site-to-site VPN page. 

[josfonse]

Hi Alessandro,

Thank you for your prompt response.

I appreciate the information about phase 1 and phase 2 rekey lifetimes. Could you also confirm if there is any idle timeout— amount of time the VPN connection can remain idle (with no activity on the tunnel) before it is automatically disconnected.

Thank you.

[alemabrahao]

This is defined according to what is configured in lifetime.

[AlexP · Accepted solution]

To hopefully give some slightly more technically precise answers here:

We have no explicit option for "idle timeout" that would do something like prompt us to send a DELETE message to a non-meraki peer that would tear down an established tunnel.

For IKEv1, the tunnel will be torn down after the lifetime expires, unless interesting client traffic has already prompted a rekey beforehand, or, if DPD is in use, after the peer stops responding to any R-U-THERE (yes, that's really what they're called) packets for too long.

For IKEv2, owing to changes in how the protocol operates, DPD is mandatory. However, by default, we won't send any DPD informational messages unless there is no client traffic traversing the tunnel (but will still ACK any DPD messages we receive from the peer in question). Otherwise, the same rules with lifetimes continue to apply, though it's also worth noting that since IKEv2 no longer requires equal lifetimes on each end of the tunnel like IKEv1 did (again, this is a change in the protocol itself, not one we forced), you may see a tunnel getting torn down as a result of a DELETE message getting sent by one peer to the other, rather than being logged as a lifetime expiring.

[josfonse]

I appreciate the technical explanation. Thank you for taking the time.