Fix ERROR_IPSEC_IKE_UNSUPPORTED_ID (0x362D) on Windows

Cause 1: Local ID on the VPN profile doesn't match what the server expects

This is the one I see most. You set up an IKEv2 VPN, hit Connect, and Outlook stays disconnected. The connectoid spins for 20-30 seconds and then throws a generic "The remote connection was not made" dialog. Dig into the event log and you find 0x362D — the server looked at the ID payload in your IKE_SA_INIT and said "I don't know who this is."
Real-world trigger: you're connecting to a FortiGate, Palo Alto, or Cisco ASA that has the peer ID locked down to an FQDN like vpn.contoso.com, but your Windows profile is still sending the default, which is your machine's IP address or hostname.

Fix

1. Open Settings → Network & Internet → VPN (or ncpa.cpl if you prefer the old panel).
2. Select your VPN profile and click Advanced options.
3. Click Edit next to "Authentication" or open the profile's properties and go to the Security tab.
4. Under Authentication, make sure it's set to Microsoft: Secured password (EAP-MSCHAP v2) or your cert-based method, then click Properties.
5. Find the field labeled Use the following ID (sometimes "Local ID" or "Send the following identity").
6. Pick the type your VPN admin gave you — usually Fully Qualified Domain Name (FQDN) — and type the exact string. Case matters on some gateways. vpn.contoso.com is not the same as VPN.Contoso.com to a strict Cisco config.
7. Click OK all the way out, then reconnect.

After you click Apply and reconnect, the IKE negotiation should reach the AUTH phase. If you're still getting 0x362D, the ID type is wrong — try E-mail address or DNS instead of FQDN.

You can verify what Windows is actually sending with:

netsh trace start scenario=VPN capture=yes report=yes
:: reproduce the failure, then
netsh trace stop

Open the .etl in Network Monitor or Message Analyzer and filter on ISAKMP. Look at the ID payload in the first responder packet. Whatever's in there has to match the server's config exactly.

Cause 2: Certificate subject/SAN doesn't contain the ID the server is matching against

If you're using machine certificates instead of a preshared key, this one bites hard. Your cert is valid, chains fine, hasn't expired — Windows shows it as usable in the VPN profile. The gateway still rejects the ID payload because the SAN doesn't include the value it's configured to look for.
Real-world trigger: someone re-issued the cert template and dropped the UPN from the SAN, or your template was built with only the CN and the firewall's peer-ID rule is keyed to the SAN DNS entry. Everything looks green on your side. It isn't.

Fix

1. Open certlm.msc (not certmgr.msc — machine certs live in the machine store).
2. Expand Personal → Certificates and find your machine cert.
3. Double-click it, go to the Details tab, and scroll to Subject Alternative Name.
4. Compare the listed DNS names, IPs, and UPN against what the VPN admin says the gateway expects.
5. If SAN entries are missing, re-enroll using a template that includes them. On the CA side, this typically means adding dNSName and userPrincipalName to the SAN list in the template's Subject Name tab.
6. If the cert is fine but Windows is sending the wrong ID, add a Local ID override on the VPN profile (same field as Cause 1) and set it to DNS with the exact SAN value.

Test with this from an elevated prompt to see what Windows picks when you don't force a Local ID:

Get-ChildItem Cert:\LocalMachine\My |
  Where-Object { $_.HasPrivateKey -and $_.NotAfter -gt (Get-Date) } |
  Select Subject, Thumbprint, NotAfter

After re-enrolling and rebinding the profile to the new thumbprint, you should see the IKE_SA_AUTH complete and the tunnel come up in Get-VpnConnection -Name "YourVPN" with ConnectionStatus: Connected.

Cause 3: Peer is on aggressive mode or an ID type Windows doesn't send by default

Older gateways — think WatchGuard XTM, some SonicWall firmware, and certain Cisco setups using aggressive mode — expect the ID payload in the first packet to be a specific type like KEY_ID (a string, not an FQDN or IP). Windows' native IKEv2 client only supports a limited set of ID types and won't send KEY_ID at all in main mode. Result: 0x362D before authentication even starts.
Real-world trigger: you inherited a VPN config from a vendor that was using the Shrew Soft or GreenBow client because it needed aggressive mode. You tried to swap to the built-in Windows client. It won't work without changing the gateway.

Fix

The clean fix is to reconfigure the peer to use main mode with an ID type Windows supports (FQDN, email, or IPv4). If you can't touch the gateway, options are:

1. Switch the Windows client to L2TP/IPsec with a pre-shared key. It's weaker and I'd only use it as a stopgap, but it sidesteps the IKE ID negotiation entirely for many setups.
2. Use a third-party IKEv2 client that supports aggressive mode and KEY_ID. The official strongSwan Windows port does; the built-in client doesn't.
3. Ask the firewall admin to add a peer-ID rule that accepts the FQDN Windows is sending. Ten minutes of work on their end versus hours of client wrangling on yours.

To confirm aggressive mode is the culprit, look at the first two packets captured in your netsh trace. Main mode starts with SA + proposal. Aggressive mode crams SA, KE, Nonce, and ID into packet one. If you see ID payload that early, that's your answer.

Quick reference

If you've ruled out all three and it still fails, grab the full netsh trace and the gateway's IKE debug at the same time. The mismatch is always visible in the ID payload — somebody's sending something the other side isn't configured to accept. That's the whole error, nothing more.