Why Native Windows IKEv2 Has No PSK Field at All

The gateway documentation says the pre-shared key goes in the client, and the Windows profile has no field for it. That gap is not a bug to work around by typing the key into the password box. It is the difference between what a protocol can do and what a particular implementation offers.

Protocol Capability Is Not Client Support

The IKEv2 specification includes shared-key authentication, so a gateway can legitimately be configured for it. The native Windows remote-access profile documents certificate and EAP arrangements instead, and protocol capability does not create a field, a parameter or a registry value that the client never had.

The PowerShell reference for adding a VPN connection is where people usually end up, and it exposes L2tpPsk for the L2TP arrangement. That parameter belongs to L2TP and is not a general IKEv2 secret. Algorithm-selection settings choose protection parameters, which is a third unrelated thing. A Windows Server routing role is not the same object either. A server interface can have configuration controls that a desktop client profile does not, and copying a server setting into a workstation profile does not reproduce the capability.

Choose Between Certificate, EAP or L2TP

If the gateway operator will accept certificate authentication, that is usually the cleanest destination: the client presents a certificate, the gateway validates it against a trusted issuer, and no shared secret sits in a profile for someone to copy. It requires enrollment, a trusted chain and a gateway configuration that maps the certificate to an authorisation decision.

EAP with a user credential is the other supported path on this client, and it moves the decision to an identity provider. It also introduces its own dependencies, since the EAP method, the server certificate and the client's trust in that certificate all have to line up. Switching to L2TP/IPsec purely to obtain a familiar field changes the protocol stack. That is acceptable when it is a supported choice with a documented reason, and it is a bad outcome when it happens because someone was looking for a box to type a key into.

Check What the Gateway Will Accept

Ask the operator which authentication methods the remote-access service offers today, rather than which ones the product supports in general. A service configured for PSK-only IKEv2 will not accept a certificate because the client prefers one.

Get-VpnConnection -Name "Corp IKEv2" | Format-List AuthenticationMethod, TunnelType, EncryptionLevel, ServerValidation
Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, NotAfter

Read the profile's authentication method and the certificate store together. A profile set to EAP with no usable certificate behind it fails in a way that looks like a server problem.

If the answer is that only PSK is available, the honest options are an approved client that supports it or a change to the gateway's authentication design. Neither is a local workaround, and pretending otherwise produces a connection that only the person who configured it can reproduce.

Record the Decision and the Secrets

Write down the chosen method, the trust anchor, the identity that maps to it and the person who approved the change. That record is what an incident review needs, and it is also what stops the next engineer from re-deriving the same dead end.

Keep the secrets distinct in your notes: an account password, a private-key passphrase and a gateway pre-shared key are three different things, even when a settings screen labels all of them password. Confusing them is how a key ends up in a ticket. Test the resulting profile with a fresh connection and one application request to a private resource. A successful tunnel with no reachable service is a partial result, and the profile should not be described as finished until the resource works too.