This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(294.40000000000003, 42%, 38%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EI%3C/text%3E%3C/svg%3E)
I am unable to change main mode lifetime for l2tp over ipsec vpn setting.
This is a windows 10 machine.
It is set to 8h by default and nothing I have done seems to change rekeying timer.
I used netsh commands to do that, changed the cryptoset using powershell, used gui to set the settings from 8h to 1h, all these changes are persistent, but when the negotiation happens, it does not use the settings, it always comes up with 8h lifetime.
MainModeSA:
KeyModule : IkeV1
MaxQMSAs : 0
LifetimeSeconds : 28800
CryptoSet:
MaxMinutes : 60
GPO setting for ipsec is set to 60 min as well.
Global settings:
KeyLifetime 60min,0sess
Followed all documentation, tried all posibilites, nothing seems to change that 8h default.
The peer it connects to always receives an 8h lifetime proposal.
I hope someone had this issue and would have an answer.
Hello iCebreaker,
Can you be specific about what you have tried changing? That is, provide the netsh command that you tried, describe how to use a GUI to set the period (at best with a snapshot of the dialog box) and anything else that you tried.
Do you have control of the settings of both the VPN server and the VPN client? On which side would you like to specify the lower value?
It would also be helpful (perhaps essential) to know why you want to change the SA lifetime. There is an undocumented method to specify the main mode SA lifetime on the client (initiator); this seems to be "global" (affecting all IKE (L2TP/IPsec) and IKEv2 VPN connections).
There is also an undocumented method to specify main mode SA lifetime on the server (responder); this seems to affect all IKE (L2TP/IPsec) connections – there is a separate setting for IKEv2.
According to RFC 2407:
When an initiator offers an SA lifetime greater than what the responder desires based on their local policy, the responder has three choices: 1) fail the negotiation entirely; 2) complete the negotiation but use a shorter lifetime than what was offered; 3) complete the negotiation and send an advisory notification to the initiator indicating the responder's true lifetime. The choice of what the responder actually does is implementation specific and/or based on local policy.
The Windows responder seems to choose option 2 for the main mode SA and option 3 for the quick mode SA. Using the PowerShell Get-NetIPsecMainModeSA and Get-NetIPsecQuickModeSA cmdlets to examine the SAs on both server and client, the reported “LifetimeSeconds” value for the main mode SA can differ between the two.
Gary
Hello Gary,
Thank you for your detailed response.
Here's a summary of what I've tried so far to change the main mode lifetime setting for L2TP over IPsec VPN on a Windows 10 machine, where I aim to reduce the default 8-hour lifetime to 1 hour:
Get-NetIPsecMainModeSA Get-NetIPsecQuickModeSA Set-NetIPsecMainModeCryptoSet -KeyLifetimeHours 1 Get-NetIPsecMainModeCryptoSet Get-NetIPsecQuickModeCryptoSet Restart-Service -Name IKEEXT -Force Restart-Service -Name PolicyAgent -Forcenetsh to adjust the key lifetime and view the existing policies and global settings: netsh advfirewall set global mainmode mmkeylifetime 60min netsh advfirewall monitor show mmsa netsh advfirewall show globalDespite these changes, during the negotiation phase, the settings seem not to be applied as the peer still receives an 8-hour lifetime proposal.
Control over Settings: I have administrative control over the VPN client settings on the Windows 10 machine. The VPN server is a Cisco router which sees the lifetime proposed by the client as 8 hours.
Reason for Change: The main reason for wanting to change the Phase 1 lifetime is due to the behavior of Phase 2, which is set to renegotiate every 1 hour. Each time Phase 2 renegotiates, it triggers Phase 1 to renegotiate as well, although the previous session remains open for the remaining 7 hours. This cycle increases traffic unnecessarily, as multiple sessions are open concurrently. Ideally, I would like to align the Phase 1 lifetime closer to the Phase 2 duration to optimize the traffic and management of these sessions.
It feels like lifetime is hardcoded and it does not comply with any changes I have made by following microsoft documentation and anything else I found on Internet.
Note: L2TP over IPSec is in transport mode, as it does not support tunnel mode, but Microsoft is not specific what are the limitations in this instance, wether mmkeylifetime can be changed or not:
Thank you for your assistance.
Regards
Here is a snapshot of the IPsec security settings:
I also read this:
https://learn.microsoft.com/en-us/troubleshoot/windows-client/windows-security/default-encryption-settings-for-l2tp-ipsec-vpn-client?source=recommendations
Hoewever no sure what to make of this:
Hello iCebreaker,
The Get-NetIPsecMainModeSA and Get-NetIPsecQuickModeSA cmdlets report on the active security associations (SA) maintained by IKEEXT independent from the system component that created them.
The Set-NetIPsecMainModeCryptoSet and related cmdlets manage settings for “Microsoft Windows Defender Firewall IPsec Provider”; these settings are independent from the settings used by the VPN client. The VPN client settings are managed with cmdlets such as Set-VpnConnectionIPsecConfiguration (the settings are persisted in the rasphone.pbk file).
The “netsh advfirewall” and the “Windows Defender Firewall with Advanced Security” MMC snap-in also manage settings for “Microsoft Windows Defender Firewall IPsec Provider”.
L2TP connections are in transport mode because the IP traffic is “tunnelled” in the L2TP datagram – there is little benefit in sending tunnelled traffic through another tunnel.
The behaviour that might need investigation is contained in the statement “Each time Phase 2 renegotiates, it triggers Phase 1 to renegotiate as well”. There could be a simple explanation for this (e.g. a short main mode SA lifetime on the Cisco router).
Shortening the main mode SA lifetime on the client won’t reduce the traffic (“optimize the traffic”) and a few orphaned security associations don’t pose much of a management burden.
Gary
Unfortunately "Set-VpnConnectionIPsecConfiguration" does not contain the parameter to change the lifetime, tried to expore this as well.
The quick mode is set to 1 hour due to the settings and limitations of the L2TP over ipsec, compatibility and other requirements.
In the case of one device, the traffic for additional security association does not make an impact, but when you have over 10000 devices, then everything starts to matter, which is my case.
@Gary thanks for trying to understand and direct me to explore other paths.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(192, 78%, 28%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ENM%3C/text%3E%3C/svg%3E)
I'm having the same problem.
I want to use GCM on both Phase 1 and Phase 2. When using GCM for both, only my Windows clients seem to have an issue with the server instantiating the rekey on Phase 1.
Neither Windows nor Android has any problem with rekeying the Child SA in Phase 2 using GCM.
Ultimately, I'm trying to set only this Window clients lifetimeseconds to something less than the IPsec server rekey lifetime.
PowerShell "Get-NetIPsecMainModeCryptoSet" does output "MaxMinutes" of 60.
PowerShell "Get-NetIPsecMainModeSA" still outputs a LifetimeSeconds value of 28800.
I would expect LifetimeSeconds of the Main Mode SA to reflect MaxMinutes set on the Main Mode Crypto Set.
Could this be a bug?
Hello Mathew,
I would suggest first focussing on the failure of the main mode rekeying rather than on the behaviour of your idea to workaround the failure (trying to force the client to initiate main mode rekeying).
Windows can log quite a lot of information about its behaviour (e.g. via the ETW providers "IKEEXT Trace Provider" or Microsoft.Windows.Networking.Ikeext). If you are prepared to trace the behaviour and share the resulting trace data then I would be happy to take a look at it.
Gary