When Unencrypted East-West Traffic Becomes the Attacker’s Highway
We were brought in after a healthcare provider’s internal audit flagged something alarming: a credential-harvesting tool had been sitting quietly on a domain controller for eleven days. The initial compromise was a phishing email. The lateral movement that followed? Completely invisible — every hop between servers was plain, unencrypted SMB and LDAP traffic, indistinguishable from normal operations. No IPsec. No mutual authentication. MITRE ATT&CK T1557 (Adversary-in-the-Middle) executed in textbook form.
That engagement changed how we scope every Windows Server 2025 deployment. The PowerShell NetIPsec module — part of the built-in NetSecurity module — is now a first-class item on our hardening checklist.
IPsec’s Role in a Zero Trust Architecture
Network segmentation alone does not stop lateral movement. APT29 and Lazarus Group both have documented TTPs that abuse trusted internal channels post-compromise — channels that perimeter firewalls won’t block because the traffic looks legitimate. IPsec addresses this at the transport layer: mutual authentication between endpoints, optional encryption, and cryptographic proof that a packet came from who it claims to come from.
The NIST Zero Trust Architecture (SP 800-207) explicitly identifies encrypted workload communications as a core control requirement. IPsec enforces that at the OS level, independent of the application layer — which is exactly where you want it when you cannot trust every piece of software running in your environment.
Two deployment modes matter here. Transport mode encrypts only the payload between two hosts — the right choice for server-to-server communication within a datacenter. Tunnel mode wraps the entire IP packet and is typically reserved for site-to-site VPN scenarios. For East-West datacenter hardening, transport mode wins almost every time.
The NetSecurity Module: Command Surface That Actually Matters
The PowerShell NetIPsec module ships natively on Windows Server 2025 — no installation required. The cmdlet surface is broader than most administrators realize. Rules, authentication sets, and crypto sets are distinct object types that compose together, and confusing which does what will cost you hours of debugging.
Rule management cmdlets you’ll use regularly:
New-NetIPsecRule— Creates a new IPsec rule in a specified policy storeSet-NetIPsecRule— Modifies an existing rule; note it cannot move a rule between policy storesGet-NetIPsecRule— Retrieves rules matching your criteriaFind-NetIPsecRule— Queries rules against specific filter parametersEnable-NetIPsecRule/Disable-NetIPsecRule— Toggles rules without destroying configurationCopy-NetIPsecRule— Copies a rule into a different policy store, including GPO targetsRemove-NetIPsecRule— Permanently deletes rulesGet-DAPolicyChange— Detects IP address drift between an existing rule and current state, then generates a PS1 update script
Authentication and crypto objects are separate from the rules themselves. This separation is intentional — it lets you define reusable policy objects and reference them across multiple rules:
New-NetIPsecMainModeCryptoProposal— Defines the IKE main mode negotiation: encryption algorithm, hash algorithm, and Diffie-Hellman group for base keying materialNew-NetIPsecQuickModeCryptoProposal— Defines quick mode SA parameters that protect actual data in transitNew-NetIPsecPhase1AuthSet/New-NetIPsecPhase2AuthSet— Packages auth proposals into reusable sets referenced by rules
Building an IPsec Transport Mode Rule from Scratch
Phase 1: Main Mode Crypto and Authentication
Start with the main mode cryptographic proposal. This governs the IKE negotiation — how two endpoints agree on keys before any data flows. For production Server 2025 environments handling regulated data, AES-256 with SHA-256 and DH Group 14 is a defensible baseline for both PCI-DSS and HIPAA requirements:
# Define main mode crypto proposal
# AES-256 + SHA-256 + DH Group 14 — meets PCI-DSS and HIPAA minimums
$mmCrypto = New-NetIPsecMainModeCryptoProposal `
-Encryption AES256 `
-Hash SHA256 `
-KeyExchange DH14
# Package the proposal into a reusable crypto set, scoped to a specific GPO
New-NetIPsecMainModeCryptoSet `
-DisplayName "CorpServer-MainModeCrypto" `
-Proposal $mmCrypto `
-PolicyStore "domain.contoso.com\IPsec_Hardening_GPO"Then define Phase 1 authentication. Kerberos works cleanly for domain-joined machines. Certificate-based auth is the correct choice for anything crossing trust boundaries or living in a DMZ:
# Phase 1 auth — Kerberos for domain-joined server-to-server traffic
$p1Auth = New-NetIPsecAuthProposal -Machine -Kerberos
New-NetIPsecPhase1AuthSet `
-DisplayName "CorpServer-Phase1Auth" `
-Proposal $p1Auth `
-PolicyStore "domain.contoso.com\IPsec_Hardening_GPO"Phase 2: Quick Mode and the Actual IPsec Rule
Quick mode negotiates the child SAs that protect actual traffic flow. Define a quick mode proposal using ESP, then wire everything into a rule:
# Quick mode proposal — ESP with AES-256 and SHA-256
$qmCrypto = New-NetIPsecQuickModeCryptoProposal `
-Encapsulation ESP `
-Encryption AES256 `
-ESPHash SHA256
New-NetIPsecQuickModeCryptoSet `
-DisplayName "CorpServer-QuickModeCrypto" `
-Proposal $qmCrypto `
-PolicyStore "domain.contoso.com\IPsec_Hardening_GPO"
# Create the transport mode rule enforcing encryption between app and DB tiers
# -InboundSecurity Require + -OutboundSecurity Require drops unauthenticated traffic
New-NetIPsecRule `
-DisplayName "AppTier-to-DBTier-Encrypt" `
-InboundSecurity Require `
-OutboundSecurity Require `
-Mode Transport `
-Phase1AuthSet "CorpServer-Phase1Auth" `
-QuickModeCryptoSet "CorpServer-QuickModeCrypto" `
-LocalAddress "10.10.20.0/24" `
-RemoteAddress "10.10.30.0/24" `
-PolicyStore "domain.contoso.com\IPsec_Hardening_GPO"The Require setting on both inbound and outbound is the strict enforcement mode — traffic that cannot be authenticated and encrypted gets dropped. During staged rollouts, start with Request on both sides to audit without enforcing, then flip to Require after validating SA negotiation is working correctly across all targeted hosts.
GPO-Based Deployment: Copying Rules Across Policy Stores
For a financial services client managing 40+ Windows Server 2025 nodes, we needed consistent IPsec policy propagated to a new GPO without rebuilding every rule and its dependencies manually. The Copy-NetIPsecRule cmdlet — along with the associated copy commands for auth and crypto sets — handles this cleanly:
# Pull the existing rule and its metadata from the source GPO
$ipsecRule = Get-NetIPsecRule `
-DisplayName "AppTier-to-DBTier-Encrypt" `
-PolicyStore "domain.contoso.com\Source_GPO"
# Open target GPO for modification
$targetGPO = Open-NetGPO -PolicyStore "domain.contoso.com\Target_GPO"
# Copy dependent objects first — order matters or rule import fails
Copy-NetIPsecPhase1AuthSet -ImportObject $ipsecRule -GPOSession $targetGPO
Copy-NetIPsecPhase2AuthSet -ImportObject $ipsecRule -GPOSession $targetGPO
Copy-NetIPsecQuickModeCryptoSet -ImportObject $ipsecRule -GPOSession $targetGPO
Copy-NetIPsecRule -ImportObject $ipsecRule -GPOSession $targetGPO
# Commit all changes to the GPO
Save-NetGPO -GPOSession $targetGPOCopy the dependent auth and crypto sets before copying the rule itself — if the referenced objects don’t exist in the target policy store when the rule is imported, the operation fails with opaque error messages. This is a documented constraint of the module: Set-NetIPsecRule cannot add objects to a policy store. Objects only enter a store at creation time via New-NetIPsecRule or Copy-NetIPsecRule.
Keeping IP Address Policies Current with Get-DAPolicyChange
In dynamic hybrid environments, server IP ranges shift constantly with provisioning and decommissioning. Get-DAPolicyChange is the PowerShell NetIPsec module’s answer to policy drift: it compares an existing rule’s address definitions against a new input set and outputs a ready-to-run PS1 script containing exactly the add and remove operations required to synchronize them:
# Detect IP drift between existing rule and updated address range
# Outputs a .ps1 script — review before executing in production
Get-DAPolicyChange `
-IPsecRuleName "AppTier-to-DBTier-Encrypt" `
-PolicyStore "domain.contoso.com\IPsec_Hardening_GPO" `
-RemoteAddress "10.10.30.0/24","10.10.31.0/24"The generated script is a review artifact, not an auto-execute payload. In automated pipelines, route it through your change management process before application. Blind auto-apply of generated policy changes in production is how you create 2 AM incidents.
If you’re running bulk operations across large policy stores, the -ThrottleLimit and -AsJob parameters available on most NetIPsec cmdlets let you control concurrency and run operations in the background. We’ve covered -ThrottleLimit in depth in our post on optimizing concurrent network operations, and -AsJob for long-running tasks in our guide on background job execution.
Enabling and Disabling Rules Safely
During staged rollouts and maintenance windows, toggling rules without destroying configuration is essential. Both Enable-NetIPsecRule and Disable-NetIPsecRule support bulk operations via -All, by display name, or via pipeline:
# Enable a specific rule by display name
Enable-NetIPsecRule -DisplayName "AppTier-to-DBTier-Encrypt" `
-PolicyStore "domain.contoso.com\IPsec_Hardening_GPO"
# Disable ALL rules in a GPO — always dry-run with -WhatIf first
Disable-NetIPsecRule -All `
-PolicyStore "domain.contoso.com\IPsec_Hardening_GPO" `
-WhatIfTreat -WhatIf as mandatory on any bulk operation touching a production policy store. A misaimed -All that drops IPsec enforcement across a PCI-scoped segment mid-audit is not a recoverable situation quickly.
Trade-offs and Limitations Worth Knowing
IPsec transport mode adds processing overhead. In high-throughput environments — 25Gbps+ datacenter interconnects — ESP encryption at the OS level can create measurable latency compared to hardware-offloaded TLS. Benchmark before mandating encryption everywhere; the performance characteristics vary significantly based on workload patterns and whether your NICs support IPsec task offload.
Kerberos-based Phase 1 authentication breaks cleanly for domain-joined hosts but is unavailable in DMZ scenarios, workgroup machines, or cross-forest trust situations where Kerberos tokens don’t traverse cleanly. Certificate-based auth solves these cases but requires a functioning PKI. Plan your certificate infrastructure before your IPsec deployment — the reverse order creates delays and design compromises.
One hard constraint to internalize: Set-NetIPsecRule modifies existing rules but cannot relocate them between policy stores. If you need a rule in a different store, the workflow is copy-then-delete, not move. The Microsoft Learn documentation covers the policy store hierarchy clearly and is worth reading before you finalize your GPO structure.
IPsec does not replace your firewall or EDR. It handles mutual authentication and encryption between known endpoints — excellent T1557 mitigation. It does not perform deep packet inspection or detect C2 traffic. Layer it into a defense-in-depth stack accordingly. SANS publishes solid frameworks for how network encryption controls fit within a broader security program if you want external validation for your architecture decisions.
Instrument Your Rollout Before You Enforce
Start with a staging environment that mirrors your production tier topology. Define crypto proposals first, then auth sets, then rules — in that order. Use Request mode before flipping to Require. Capture network events during SA negotiation to confirm policies are working as intended; our article on automating network captures with NetEventSession walks through exactly how to instrument that process in PowerShell.
The PowerShell NetIPsec module gives you the precision to enforce Zero Trust network controls at the OS layer without buying additional tooling. That’s the opinion I’ll stand behind: native IPsec policy management via PowerShell is underused, underappreciated, and frequently more appropriate than third-party micro-segmentation solutions for Windows-centric environments.
If you’re scoping IPsec policy for a compliance requirement or working through a Zero Trust network architecture, get in touch with us. We’ve implemented this across healthcare, financial services, and critical infrastructure environments — and the design decisions are always environment-specific.
