VPN on Windows: Match the Client to the Profile

Windows reports the tunnel as connected while the intranet page still times out, and the profile came from someone who has since left. Two separate mistakes sit behind that state: the wrong client for the file, and the wrong expectation about what the tunnel covers. Telling them apart takes a few commands and saves a reinstall. Neither of them is fixed by rebooting.

The Built-In Client Imports Only Its Own Types

Windows ships a VPN client that understands specific connection types, and it will not import an OpenVPN file or a WireGuard configuration no matter how the file is named. Those need their own software, installed from the vendor's verified download page. A familiar entry in the network menu is not evidence that the server supports it, and a profile renamed with a familiar extension is still the wrong file. The connection type has to match what the operator supplied rather than what the menu happens to offer.

For a native connection, add it through the network settings and type exactly the values you were given. Certificate-based IKEv2 and a username-and-password entry point are different configurations even when both end up under the same heading. If a managed device already supplies a connection, use that one instead of building a second beside it.

Sign-In Steps Are Not Interchangeable

A connection can require a username and password, a client certificate, an interactive prompt or several of those in sequence. A private-key passphrase unlocks a key and is not the service password, even when both are typed into the same dialog. A certificate warning is about identity or trust, not about whether the account name was spelled correctly. Reading which of the three failed decides the next step.

Read the rejection rather than retrying it. An authentication failure and a trust failure look similar in a status window and have nothing in common underneath: the first needs a credential, the second a chain the client accepts.

Keep credentials and certificate material out of screenshots. A photo of a settings page can expose a server address and a saved username at once, and a support thread is a public document more often than people expect. Redact before posting rather than after somebody has already quoted it.

In PowerShell, Get-VpnConnection lists what Windows believes is configured, including entries the settings window keeps out of sight. From a cmd prompt, rasdial connects by connection name and ipconfig /all shows what the adapter actually received. The two shells do not share a parser, so paste each line into the right one.

Get-VpnConnection
Get-VpnConnection -Name "Office" | Format-List Name,ServerAddress,AuthenticationMethod

rasdial "Office"
ipconfig /all

The Routing Table Decides, Not the Adapter Icon

A corporate tunnel may route only office destinations, leaving ordinary browsing on the local connection, while a full-tunnel profile does the opposite. Open the actual resource before deciding that either behaviour is wrong. The icon reports adapter state, and the routing table is where the answer lives. Those two disagree more often than a status window admits.

More-specific entries can send a subnet into the tunnel while the default route stays outside it, which is exactly how a split tunnel is supposed to look. A missing entry is the other common outcome, and from the browser it looks identical to a tunnel that is down. Compare the prefix you cannot reach against the table rather than against the icon. That is why the icon and the table can disagree while both are telling the truth about different things.

Do not delete routes because the table contains adapters you do not recognise. A virtual machine, a filter driver or a second client can each add one, and removing it breaks something that used to work.

route print -4
nslookup intranet.corp.internal

Private Names Need the Organisation Resolver

Private names need the organisation's resolver, and a browser with its own secure DNS can bypass the system setting entirely. That produces the confusing case where a command-line lookup returns an address and the same name still fails in the browser.

Check which adapter supplied the current DNS configuration before changing anything. Keep the organisational resolver for private names instead of replacing it with a public service. Substituting a public resolver usually repairs a public name and breaks every internal one, which is a worse failure than the one you started with. If the connection reports success and nothing works, work through forwarding and DNS before resetting the network stack.

Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName intranet.corp.internal

Microsoft's documentation on Windows VPN connection types and plug-ins is the reference for which client handles which type, and no menu label tells you that. Reconnect after any change and retry the real application rather than the status icon. Save the working profile where you can find it again, and note the resolver and the route that made it work, because the next machine will need both.