MX non-Meraki peer tunnel type Iddle timeout

Solved
josfonse
Here to help

MX non-Meraki peer tunnel type Iddle timeout

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.

 

 

1 Accepted Solution
AlexP
Meraki Employee
Meraki Employee

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.

View solution in original post

5 Replies 5
alemabrahao
Kind of a big deal
Kind of a big deal

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. 

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
josfonse
Here to help

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
Kind of a big deal
Kind of a big deal

This is defined according to what is configured in lifetime.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
AlexP
Meraki Employee
Meraki Employee

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
Here to help

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

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels