A VPN That Worked Yesterday and Fails Today: Separating Protocol Faults From Network Blocks

A VPN that connected last week and refuses today is almost never one fault. Three separate things produce the same terse failure box: the profile stored on the device, the transport the tunnel rides on, and a policy on the network in between. Each has a different fix, and a test that rules out the other two in about a minute.

The cheapest of those tests costs nothing. Connect the same account over a phone hotspot. If the tunnel comes up on cellular and fails on the Wi-Fi that was fine yesterday, nothing on the device is broken and reinstalling the client will not help. If it fails on both, the network is innocent.

Do this first: move the tunnel to a different transport

Most VPN protocols run over UDP, and most shared networks — hotel Wi-Fi, guest SSIDs, conference venues, some corporate LANs — treat UDP differently from TCP. That mismatch explains a large share of tunnels that die on one network and work everywhere else.

RFC 8229, which standardizes TCP encapsulation of IKE and IPsec, states the reason plainly: "Many network middleboxes that filter traffic on public hotspots block all UDP traffic, including IKE and IPsec, but allow TCP connections through because they appear to be web traffic." The same document tells implementations when to use the TCP path: "Most implementations should use TCP encapsulation only on networks where negotiation over UDP has been attempted without receiving responses from the peer or if a network is known to not support UDP."

That is a troubleshooting rule as much as an engineering one. If a client offers a TCP mode, a port 443 option, or an OpenVPN profile marked tcp, switch to it and try once. A connection that succeeds on TCP after failing on UDP has told you where the fault lives, and it is not on the device.

RFC 8229 also warns against leaving it there: "Direct use of ESP or UDP encapsulation should be preferred by IKE implementations due to performance concerns when using TCP encapsulation." TCP is a diagnosis, not a destination. Once it identifies the network as the blocker, the durable fix is a different network or a server-side port change.

Layer one: read the profile before touching it

On Windows 11, the built-in client lives at Settings > Network & internet > VPN > Add VPN. Microsoft's support documentation lists the fields in that dialog: VPN provider (choose Windows (built-in)), Connection name, Server name or address, VPN type, and Type of sign-in info. Existing profiles connect from the same page, or from the network icon on the taskbar under VPN. A live connection shows the word Connected beside the profile name and a blue shield icon on the taskbar.

The VPN type field is the one worth reading carefully, because the built-in client does not support every protocol in circulation. Microsoft documents the supported tunneling protocols as IKEv2, L2TP, PPTP, SSTP, and an Automatic option. Automatic is described as follows: the device "tries each of the built-in tunneling protocols until one succeeds. It attempts from most secure to least secure." That is convenient until it is not — a profile left on Automatic can succeed on a protocol nobody intended, and the failure that shows up months later is a server finally refusing that fallback.

One documented quirk saves wasted searching. Microsoft notes that "when a VPN plug-in is used, the adapter will be listed as an SSTP adapter, even though the VPN protocol used is the plug-in's protocol." An adapter labeled SSTP is therefore not proof that SSTP is in use.

On macOS, Apple's path is Apple menu > System Settings > Network, then the Action pop-up menu, then Add VPN Configuration, then the connection type. Apple documents three native types: L2TP over IPSec, Cisco IPSec, and IKEv2. A configuration supplied by an administrator can be double-clicked instead: "If you received a VPN settings file from your network administrator or VPN service provider, you can just double-click it to set up your connection." Anything outside those three protocols — WireGuard and OpenVPN included — arrives as a separate application, and the operating system's VPN pane will not show its state or its errors.

Layer two: what each tunnel actually rides on

Knowing which port and transport a protocol uses turns a vague "it won't connect" into a testable claim. The numbers below are those registered with IANA, or used in the protocol's own documentation.

A few of those rows carry real consequences.

• IKEv2 has a documented escape route. RFC 7296 states that "IKE normally listens and sends on UDP port 500, though IKE messages may also be received on UDP port 4500 with a slightly different format." Port 4500 is registered with IANA as ipsec-nat-t for both UDP and TCP, and RFC 8229 defines the TCP form.
• WireGuard has none. The protocol documentation is unambiguous: "All packets are sent over UDP." There is no TCP mode to fall back to. WireGuard's own quick-start example uses port 51820, but the protocol does not reserve a fixed port. On a network that filters UDP, the remedies are a different port, network, or protocol.
• OpenVPN can go either way, and the profile decides. IANA registers port 1194 for both TCP and UDP, and OpenVPN's reference manual documents a --proto option taking udp or tcp. Which is in force is written in the profile — open the .ovpn file and read its proto and remote lines.
• SSTP is already TCP 443. Microsoft's protocol specification describes it as "a mechanism to encapsulate Point-to-Point Protocol (PPP) traffic over an HTTPS protocol" and states that the client "first establishes a TCP connection to the SSTP server over TCP port 443." A UDP block cannot touch it. If SSTP also fails on the same network, the cause is somewhere other than UDP filtering.
• PPTP needs something a port list will not show. IANA registers 1723 for PPTP, but the data channel uses GRE, which is IP protocol 47 rather than a port at all. Firewalls and NAT devices that pass every TCP and UDP port can still drop the tunnel because they never handle protocol 47.

When "connected" still means nothing loads

A tunnel that reports success while the browser sits empty is a different problem class. Two documented mechanisms account for most of it.

The first is a kill switch. Vendors name it differently, but Windows documents the underlying behavior precisely under the name LockDown VPN. A LockDown profile "secures the device to only allow network traffic over the VPN interface", the system "attempts to always keep the VPN connected", the user "can't disconnect the VPN connection" and "can't delete or modify the VPN profile", and — the line that explains the symptom — "if the VPN connection isn't available, outbound network traffic is blocked." Only one LockDown profile is permitted per device, and for the built-in client the feature is available for IKEv2 connections only.

That is the mechanism behind a common report: the Wi-Fi is fine, other devices work, and one machine insists the internet is down. It is not down. A policy is refusing to let traffic leave until a tunnel that cannot be established is established.

The second mechanism is a captive portal. RFC 8910 describes what these do: temporary-access networks "start new connections in a captive portal mode" which "highly restricts what the user can do until the user has satisfied the captive portal conditions", and the enforcement device "has to intercept the user's connections and redirect the user to a captive portal server, using methods that are very similar to man-in-the-middle (MITM) attacks." A VPN handshake attempted before sign-in is intercepted like everything else.

Windows detects this state with its own probe. Microsoft documents that Windows "runs a series of network tests" against msftncsi.com, "a reserved domain for connectivity testing", and when a portal is detected it "repeats these tests until the captive portal lets the user connect", opening a browser to the portal page. One limit matters on managed laptops: "captive portal functionality is not supported at the Windows login screen." A device set to connect its VPN before sign-in will fail on hotel Wi-Fi every time, with no portal offered.

What a DNS leak is, stated precisely

"DNS leak" is not a term defined in any protocol standard, which is part of why the phrase attracts so much invented explanation. What it describes is nonetheless concrete and measurable: a name lookup that leaves the machine over an interface other than the tunnel, so the resolver that answers it — typically the one handed out by the local network — learns which host was requested even though the traffic itself is encrypted.

Windows documents the resolution order that makes this possible. The Name Resolution Policy Table is "a table of namespaces that determines the DNS client's behavior when issuing name resolution queries and processing responses" and is "the first place that the stack will look after the DNSCache." Microsoft then describes what happens when nothing matches: the DNS suffix on the most preferred interface, chosen by interface metric, is appended and a query is sent on that interface — and if that query times out, the DNS suffix search list is used in order and queries are sent on all interfaces.

That last clause is the whole mechanism. A tunnel that is up but slow to answer, or a profile with no matching namespace rule, produces queries on every adapter the machine has, including the one facing the café. The related setting is documented too: the DNS suffix "is used to configure the primary DNS suffix for the VPN interface and the suffix search list after the VPN connection is established." Before establishment, it is not in force.

Two consequences follow. Internal hostnames that resolve at the office and fail at home usually indicate a missing or unmatched namespace rule rather than a broken tunnel. And a claim that a specific product "prevents DNS leaks" describes a client-side policy, not a protocol guarantee — the operating system behavior above is what any such policy has to override.

Error codes worth reading literally

Windows returns numbers more specific than the message beside them. Microsoft's troubleshooting documentation defines these:

Code	Documented meaning
800	The remote connection couldn't connect. The attempted VPN tunnels failed, often because the VPN server isn't reachable.
809	Can't establish a connection between the local machine and the VPN server; the remote server doesn't respond.
812	The authentication method the server used didn't match the authentication method configured in the connection profile.
13801	The IKE authentication credentials are invalid — either side can refuse them.
13806	IKE can't find a valid machine certificate.
0x80070040	The server certificate doesn't have Server Authentication among its usage entries.
0x800B0109	A certificate chain processed but terminated in a root certificate the trust provider doesn't trust.

The split is useful. Codes 800 and 809 point outward, at reachability and at whatever sits between client and server. The rest point inward, at credentials and certificates, and no amount of switching ports will move them.

The NAT-T registry value, and its documented scope

One fix circulates constantly for L2TP/IPsec connections failing behind a NAT router. Microsoft documents a DWORD value named AssumeUDPEncapsulationContextOnSendRule under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent, with three states: 0 (default) means Windows cannot establish security associations with servers behind NAT devices; 1 allows associations with servers behind NAT; 2 allows them when both server and client are behind NAT.

The caveat matters more than the value. The article documenting it scopes it to Windows Vista and Windows Server 2008, with a different path for Windows XP SP2. It does not list Windows 11. "Widely reported to still apply" is not the same as documented, so this belongs at the end of a troubleshooting list, after the profile, transport and portal checks.

When This Doesn't Apply

This frame splits a VPN failure into profile, transport and path policy. Several situations do not fit it.

• The account, not the connection, is the problem. An expired subscription, a device limit reached, or a password changed on the provider side produces a connection failure that looks identical to a network block. The hotspot test separates these: a failure on every network including cellular points here, and no port change will help.
• The server is down or the endpoint was retired. A profile pointing at a hostname that no longer resolves fails everywhere, permanently, and error 800 or 809 is the expected result rather than a clue about local filtering.
• Managed devices where the profile is not yours to edit. A LockDown profile explicitly prevents the user from disconnecting, deleting or modifying it. Report the symptom and the error code instead; the settings that would fix it are administrator-controlled by design.
• Protocols outside the built-in clients. The Windows and macOS paths above describe native VPN configurations. A WireGuard or OpenVPN application keeps its own log and its own settings, and the operating system's VPN pane will show nothing useful about either.
• Older operating system versions. Every menu path here comes from current Microsoft and Apple documentation for Windows 11 and recent macOS releases. Earlier versions place the same settings elsewhere.

A working order of operations

1. Test on a phone hotspot. Success on cellular and failure on Wi-Fi isolates the fault to the network. Failure on both isolates it to the profile or account.
2. Read the error number, not the sentence. 800 and 809 mean reachability. 812, 13801, 13806 and the 0x8... codes mean credentials or certificates, and end the network investigation.
3. On an unfamiliar network, clear the captive portal first. Disconnect the VPN, load a plain page, sign in, then reconnect. Remember that this cannot be done from the Windows login screen.
4. Switch transport once. TCP mode, port 443 mode, or an OpenVPN profile using tcp. If that connects, the network is filtering UDP and you have your answer.
5. Check the VPN type field. Confirm whether the profile is pinned to a protocol or left on Automatic, and remember that an adapter labeled SSTP may belong to a plug-in using something else.
6. If the tunnel connects but nothing loads, suspect policy before software. A kill switch blocking outbound traffic and an unsatisfied captive portal both present as "no internet" on a link that is working normally.
7. If internal names fail while public ones work, look at name resolution. Queries falling through to the suffix search list go out on all interfaces by design, not by defect.
8. Leave registry edits last. The NAT-T value is documented for far older Windows versions than the one on most desks.

A VPN failure is a layered question, and the layers separate with tests that take about a minute each. Two of them — a hotspot and a transport switch — settle most cases without a support ticket or a setting that cannot easily be changed back.