Windows IKEv2 Custom Policy: Apply It as Its Own Step

A provisioned connection and a custom crypto suite are two outcomes. Match the policy fields, the profile scope and the owner that reapplies them.

A provisioning package creates an IKEv2 connection and the resulting profile negotiates something other than the suite you intended. The package did its job; it never had a field for the job you assumed. Treat the crypto suite as a separate, verifiable provisioning step.

Work through the five items below in order, and keep the acceptance results distinct.

Two Kinds of Policy Behind Similar Names

Windows separates the policy that protects the key exchange from the policy that protects the traffic. The IKE side is configured by an encryption method and an integrity method. The data side is configured by cipher and authentication transform constants, and those constants use their own names. A single AES label copied into the wrong field produces a connection that establishes under a policy nobody approved.

Key-exchange group and perfect forward secrecy belong to the same negotiation and have to be acceptable to the gateway. Setting them without checking the far end produces a failure at a later stage than the one you were editing, which is why these mistakes look like gateway problems.

Build a Complete Policy, Not Two Algorithm Names

Write every field explicitly, including the ones you believe are defaults. A partial policy applied with a force flag becomes the saved configuration, and the values you left out are whatever the platform had at that moment. Values starting with the same prefix are not interchangeable across fields, and one of the well-known transform names is valid only as an authentication transform.

$policy = @{
    ConnectionName = 'Corp IKEv2'
    AllUserConnection = $true
    EncryptionMethod = 'AES256'
    IntegrityCheckMethod = 'SHA384'
    CipherTransformConstants = 'AES256'
    AuthenticationTransformConstants = 'SHA384128'
    DHGroup = 'Group19'
    PfsGroup = 'PFS2048'
    Force = $true
}
Set-VpnConnectionIPsecConfiguration @policy

Treat that block as an illustrative suite your two peers must both support, not as a recommendation. The force switch suppresses a prompt; it does not approve a package you have not reviewed.

Create First, Then Apply, in One Scope

The connection must exist before its policy can be set, and the scope must match at every step. A machine-context step cannot find an arbitrary user's private profile just because the display name is the same. All-user connections, user connections and their state directories are separate objects with separate names.

Ordering matters more than it looks in a provisioning package, because two commands can run closer together than the connection takes to create. Package the post-configuration work as an approved provisioning command with a declared execution context, and let the provisioning engine sequence it rather than inserting a guessed delay. A sleep that is long enough on your test hardware is a race condition with a delay attached. Record the dependency instead of the duration.

The documented Configuration Designer fields describe a VPN setting, and they do not expose every native IPsec control. If the requirement is a managed delivery, the VPNv2 configuration service provider has a cryptography suite section for exactly this purpose.

Name a Single Owner for the Policy

A later management-profile update can recreate the connection and replace whatever a script applied, and the replacement will look like a regression. Decide whether the suite is owned by the profile, by a script or by the management channel, and make routine updates follow the same path as the first installation.

Two owners is the same as no owner when the two disagree. Write the owner's name into the profile's change record. The next update will follow whatever that record says.

Verify the Negotiated Result, Not the Package

Read the saved profile and its scope, then establish a fresh connection and compare the selected proposals at the gateway. Confirm the rekey behaviour too, because an initial handshake can succeed with a suite that a later phase refuses.

Get-VpnConnection -Name 'Corp IKEv2' -AllUserConnection | Format-List
Get-ChildItem 'C:\ProgramData\Microsoft\Network\Connections\Pbk' | Select-Object Name, LastWriteTime

Three acceptance results are not the same event: the package installed, the profile exists with the intended policy, and the peers negotiated it. Keep them separate, so a missing field is never repaired by weakening authentication or by enabling a fallback nobody chose.

Related articles