During a network security review for a logistics company we took over last year, we pulled their Windows Server 2025 IPsec policy and found the main mode crypto set negotiating DH Group 1 — a 768-bit key exchange that has been considered broken for over a decade. It was not malice. It was defaults left untouched. Set-NetIPsecMainModeCryptoSet was the tool that corrected it in under ten minutes, without rebuilding the rule structure from scratch.
Why Weak IKE Crypto Sets Stay in Production
IKE main mode is the first handshake in an IPsec negotiation. Two endpoints agree on encryption, hashing, and Diffie-Hellman group before any security association is established. That agreement is governed by an ordered list of cryptographic proposals in the main mode crypto set. Windows negotiates down that list until both sides match — which means a weak proposal sitting at the bottom is still reachable if a peer endpoint insists on it.
Most environments do not audit this configuration at deployment. The set gets created with defaults, a rule gets bound to it, and it runs for years untouched. Auditors benchmarking against the NIST Cybersecurity Framework will flag DH1 and DH2 immediately. MITRE ATT&CK T1557 (Adversary-in-the-Middle) describes exactly the attack class that weak IKE key exchange enables. The fix is not complex. The challenge is knowing which cmdlet controls it and how the underlying object model works.
What Set-NetIPsecMainModeCryptoSet Controls
The cmdlet modifies properties on existing main mode cryptographic sets. It does not create them. A main mode crypto set is an ordered collection of proposals — each proposal defines three parameters: the encryption algorithm, the hash algorithm, and the DH key exchange group. New-NetIPsecMainModeCryptoProposal builds individual proposals; the crypto set holds the ordered list.
One constraint worth knowing early: Set-NetIPsecMainModeCryptoSet cannot move an object between policy stores. If the set needs to live in a GPO-backed store, it must be placed there at creation time using New-NetIPsecMainModeCryptoSet or Copy-NetIPsecMainModeCryptoSet. This matters for enterprise deployments pushing policy via Intune or Group Policy — get the policy store right at creation, not after the rule is already bound in production.
For full context on how main mode crypto sets fit into the broader IPsec policy hierarchy, the IPsec Main Mode Crypto Sets: PowerShell Hardening Guide covers the complete rule-to-SA mapping in detail.
The Three Parameters That Define a Negotiation Proposal
When building a proposal with New-NetIPsecMainModeCryptoProposal, three parameters control what gets offered during negotiation:
- -Encryption: AES128, AES192, AES256, DES3
- -Hash: SHA1, SHA256, SHA384, MD5
- -KeyExchange: DH1, DH2, DH14, DH19, DH20, DH24
DH19 is 256-bit elliptic curve. DH14 is 2048-bit MODP. Both pass current hardening benchmarks. DH1 and DH2 do not appear on any credible approved algorithm list in a post-2020 hardening baseline.
Two Patterns for Updating a Crypto Set in Production
Method 1 — Index-Based Proposal Replacement
Build the proposals, create the set, bind it to a rule, retrieve it, and modify a specific proposal by array index before applying the change:
# Build initial proposals — DH1 at index 0, DH14 at index 1
$proposal1 = New-NetIPsecMainModeCryptoProposal -KeyExchange DH1
$proposal2 = New-NetIPsecMainModeCryptoProposal -KeyExchange DH14
# Create the crypto set and bind it to a main mode rule
$cryptoset1 = New-NetIPsecMainModeCryptoSet -DisplayName "MainModeCryptoSet" `
-Proposal $proposal1.Name, $proposal2.Name
$mainModeRule = New-NetIPsecMainModeRule -DisplayName "MainModeRule" `
-MainModeCryptoSet $cryptoset1
# Retrieve the set via the rule, replace index 1 with DH19, apply the change
$mainModeCryptoSet = $mainModeRule | Get-NetIPsecMainModeCryptoSet
$mainModeCryptoSet.Proposal[1] = "DH19"
$mainModeCryptoSet | Set-NetIPsecMainModeCryptoSet
# Result: index 0 stays DH1, index 1 is now DH19 — DH14 removedMethod 2 — Full Proposal Replacement via Pipeline
This replaces all proposals in a single pipeline call. Cleaner for scripts that need to enforce a specific known-good baseline without depending on what the existing list contains:
# Create rule with initial proposals inline
$mainModeRule = New-NetIPsecMainModeRule -DisplayName "MainModeRule" `
-MainModeCryptoSet (New-NetIPsecMainModeCryptoSet `
-DisplayName "MainModeCryptoSet" `
-Proposal (New-NetIPsecMainModeCryptoProposal -KeyExchange DH1),
(New-NetIPsecMainModeCryptoProposal -KeyExchange DH14)).Name
# Retrieve set, replace entire proposal list in one Set call
$mainModeCryptoSet = $mainModeRule | Get-NetIPsecMainModeCryptoSet
$mainModeCryptoSet | Set-NetIPsecMainModeCryptoSet `
-Proposal (New-NetIPsecMainModeCryptoProposal -KeyExchange DH1),
(New-NetIPsecMainModeCryptoProposal -KeyExchange DH19)
# Full list replaced — DH14 gone, DH19 in at index 1SA lifetime management does not require touching proposals at all:
# Set max SA lifetime to 240 minutes for all sets in the DA Client group
Set-NetIPsecMainModeCryptoSet -DisplayGroup "DA Client" -MaxMinutes 240To update encryption algorithms on an existing named set without rebuilding it:
$EncAES128 = New-NetIPsecMainModeCryptoProposal -Encryption AES128
$EncDES3 = New-NetIPsecMainModeCryptoProposal -Encryption DES3
Set-NetIPsecMainModeCryptoSet -DisplayName "(DA Client) - Phase 2 Crypto Set" `
-Proposals $EncAES128, $EncDES3When pushing these changes across multiple servers, the -CimSession parameter accepts an array of CimSession objects — pair this with the patterns in PowerShell CimSession: Remote Network Cmdlets at Scale for fleet-wide enforcement without touching each server individually.
My Position: DH14 Is the Fallback, Not the Target
Some engineers treat DH14 as the hardening goal. That position is wrong. DH14 is the floor below which no proposal should appear — it is not the target for any environment built in the last five years.
For organizations going through a digital transformation that includes network security uplift, the posture we enforce across managed environments is: DH19 as the primary proposal, DH14 as the compatibility fallback, and DH1 and DH2 absent from the list entirely. The counterargument — legacy devices or VPN concentrators that will not negotiate elliptic curve groups — is valid. That is why DH14 stays as a second proposal. But placing DH14 first means every negotiation that could reach DH19 is being actively downgraded. That is a deliberate policy decision with a measurable security cost, and most environments make it by accident, not intent.
This posture passes every CIS Level 2 benchmark and NIST-aligned audit we have run it through.
Limitations to Understand Before You Deploy
The -ForceDiffieHellman boolean forces a fresh DH exchange on every SA regardless of whether Perfect Forward Secrecy was negotiated. Valuable when key material reuse appears as an audit finding. It also adds CPU overhead on high-throughput paths — benchmark it against your throughput baseline before enabling it fleet-wide on anything handling significant east-west traffic.
The policy store constraint is the one that causes production incidents. Set-NetIPsecMainModeCryptoSet cannot relocate a set to a different policy store. If an existing set needs to move from the local store to a domain GPO store, the path is: copy it to the target store with Copy-NetIPsecMainModeCryptoSet, update the proposals there, then retire the original. Plan store placement at creation time — retrofitting it after a rule is bound and actively negotiating SAs is a change-window task, not a quick fix.
SA lifetime settings also interact with backup traffic running across IPsec-secured paths. If you are running WAN-accelerated backup over an IPsec tunnel, aggressive -MaxMinutes values will force SA renegotiation mid-transfer. Set the lifetime to accommodate your longest backup window before tightening it for hardening reasons.
Where to Start Today
Run Get-NetIPsecMainModeCryptoSet | Select-Object -ExpandProperty Proposal on any Windows Server with active IPsec policy. Review every DH group in the proposal list. If DH1 or DH2 appears anywhere, that is your first remediation item. Use Method 2 above to replace the full proposal list with a DH19-first, DH14-fallback baseline. Document the change against the hardening benchmark it satisfies, verify existing tunnels renegotiate cleanly after the update, and log the SA renegotiation events to confirm behavior matches intent.
If you need support auditing or enforcing IPsec cryptographic policy across a Windows Server environment, get in touch with us here.
