Why Android connects to the home IPsec VPN and Windows will not

The phone joins the router's VPN without complaint while the laptop on the same Wi-Fi cannot. Same credentials, same server, same minute. The difference is protocol support rather than the password: the router exposes a profile that one operating system implements and another never did.

Identify the profile first, then compare it with what each client actually speaks.

One menu, three protocols

Under a single IPsec heading, consumer firmware can hide three quite different tunnels. The first is IKEv1 with XAUTH: a shared group secret, then a user name and password on top. The second is L2TP/IPsec, where PPP runs inside an IPsec transport protected by a shared key. The third is IKEv2, authenticated with certificates or EAP.

Read the fields rather than the label. A group secret plus a user list means IKEv1 XAUTH. A pre-shared key plus a PPP account means L2TP/IPsec. A server certificate with no group secret means IKEv2.

The support gap between phone and laptop

Android carries an IKEv1 XAUTH PSK client in the box, which is exactly why the phone succeeds against a router that offers nothing else. Windows does not: its native client handles L2TP/IPsec and IKEv2, and there is no IKEv1 XAUTH option to enable. Re-entering the secret cannot help, because the missing piece is the protocol and not the credential.

Apple's side is a moving target. Newer macOS and iOS releases steer toward IKEv2, older Cisco-style profiles survive in some builds, and an upgrade can remove or tighten what worked last month. A Mac that connected yesterday and does not today, with no router change, is usually this.

Two settings that break otherwise correct profiles

Synology's L2TP/IPsec page offers a checkbox labelled Enable SHA2-256 compatible mode (96 bit). Apple's clients from iOS 14 and macOS Big Sur onward reject that truncated mode, so the box has to be unticked for them. With it left on, the tunnel authenticates and then drops, which reads like bad credentials and is not. The vendor documents the toggle, and an operating system upgrade is the usual moment it starts to matter.

Windows keeps certificates in two separate stores, and IKEv2 reads only the machine one. Import the client certificate with its private key into the computer account; a certificate filed under your own user account appears in the management console and never reaches the IKEv2 service. EAP-TLS is the one case where a user certificate is usable, and the signing CA still has to be trusted by the machine. Getting this wrong shows up as an authentication failure, not as a missing-certificate prompt.

When the router stays as it is

A router that only speaks XAUTH PSK leaves three ways forward: the vendor's client, a third-party client that still implements the profile, or moving the tunnel endpoint to something that speaks IKEv2. AVM, for example, publishes Windows client software and an exported configuration file for its routers. That route is supported, and it does mean installing a vendor tool on every laptop.

Support matters more than elegance when the laptops are not yours to rebuild.

Weigh the security cost as well. One group secret covers every user, so whoever holds it can stand in for the server and capture the user name and password that the client offers. Where IKEv2 with certificates is available, that migration is worth more than any client workaround.

Diagnose from the outside in

Get one working session from the phone first, so the server side is proven before the laptop enters the picture. Then import the router's exported profile unchanged and read the client log instead of the router's status page. If the log shows no proposal leaving, the laptop never reached the responder. If proposals are exchanged and then fail, the disagreement is about algorithms, identity or credentials.

Keep the working phone profile as the control. When only the laptop breaks after a firmware update, the server side is behaving as before. When both break, look at the certificate or the listener before touching either client.