Build an IKEv2 VPN in PowerShell With a Machine Cert

Windows ships an IKEv2 client that PowerShell controls end to end, so a working tunnel needs no GUI and no third-party software. Nearly every failure comes from three places: where the certificate ended up, how the route prefixes were written, and what the chosen EAP method expects. Handle them in that order, because each one is checkable before the next begins and a later error will mask an earlier one.

Machine-certificate tunnels exist to start before anyone logs in, which is why the identity normally has to live in the computer's store rather than a user's.

Certificate First, Tunnel Second

Two imports matter. The client identity goes into Cert:\LocalMachine\My via Import-PfxCertificate, and the issuing CA goes into Cert:\LocalMachine\Root via Import-Certificate. A leaf on its own proves no chain, so skipping the second import leaves verification with nothing to build on. Beyond presence, the private key must be attached and the computer account must be allowed to read it. Get-ChildItem Cert:\LocalMachine\My lists what arrived; compare thumbprints rather than subjects, since near-identical subjects are common.

Check the extended key usage before you deploy. Client authentication is the usual requirement for an IKEv2 machine identity, and the far side must trust the CA that signed it. An identity sitting in a user's store does not exist as far as a computer-context connection is concerned.

Create the Profile and Its Routes

Add-VpnConnection -Name "Office IKEv2" -ServerAddress vpn.example.com -TunnelType Ikev2 -EncryptionLevel Required -AuthenticationMethod MachineCertificate -AllUserConnection writes the profile. The -AllUserConnection switch publishes it in the global phone book, appropriate for a shared or service-managed box; drop it for a single user. Whatever address you pass has to match the DNS name in the server's certificate, otherwise the failure appears after the tunnel is already up. Prefixes are then added one at a time with Add-VpnConnectionRoute, and only the ones the design actually needs.

IPv6 carries a quirk: Windows refuses ::/0 as a VPN route, so ::/1 and 8000::/1 together cover the same address space. Routing a prefix also grants nothing at the remote firewall, so the prefix list and the firewall policy stay separate documents.

Credentials Belong to the Authentication Method

A machine-certificate profile needs no user secret at all, while an EAP-MSCHAPv2 profile does. For the second case the VPNCredentialsHelper module provides Set-VpnConnectionUsernamePassword, and it wants plain text: $cred.Password is a SecureString, so unwrap it with GetNetworkCredential().Password first. Install the module wherever the command runs, not just on the workstation where it was drafted. EAP-TLS or a custom method does not use this cmdlet at all; it takes an EAP configuration XML instead.

rasdial "Office IKEv2" raises the connection from a shell, which is the fastest way to see the result in the foreground rather than in an event log.

What a Connected Tunnel Does Not Prove

Connected status covers the IKE exchange and the authentication step, and nothing beyond them. DNS behaviour, the path to a private host and the remote firewall are all still unproven. Work outward: the tunnel adapter, then a route lookup for a private address, then one service you are authorized to use. The first observation that fails identifies the layer to investigate.

When you change a profile, delete the previous one with Remove-VpnConnection -Name "Office IKEv2" -Force before recreating it; otherwise stale settings and routes persist through the edit. If it still will not connect, compare the thumbprint recorded in the profile against the one present in the store, because Windows can hold a reference to an identity that has since been replaced under an unchanged subject.

Keep the thumbprint, the EAP method and the route list beside the profile. Together they explain most of what goes wrong later.