VPN Connects at Home but Times Out on Hotel Wi-Fi

The laptop joins the home Wi-Fi, the client connects in three seconds, and the same profile fails at the hotel an hour later. Nothing was updated in between. Walking through this with a client in front of you is mostly about knowing which error belongs to which stage, because the useful information is in the code the client prints, not in the fact that it failed. Work the four steps below in order and you will know whether a name, a packet, a port or a policy refused you.

Read the error code as a stage, not a verdict

The client reaches three separate milestones before a tunnel exists. It resolves the server name, it gets an answer from something on the network, and it negotiates a security association. Each milestone has its own failure message, and Windows in particular is generous with distinct codes once you know which stage they belong to.

Two of those codes mean the network is innocent. A 789 means packets were flowing and the two ends disagreed about crypto, which is a configuration problem you can fix at home. A 868 means no packet ever needed to leave, so the tunnel design is irrelevant until the name resolves. Sorting the code into the right stage saves more time than any capture, because it tells you which of the next three steps to skip.

Hedge appropriately if the client is not Windows. Third-party clients collapse most of these into "connection failed", which is why the next two steps do not rely on the message at all.

Check the name before you blame the tunnel

Hotel and airport networks intercept DNS constantly, and a resolver that answers with a portal address produces a failure that looks exactly like a dead server. Compare what the local resolver says with what a public resolver says:

Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"

If the two answers differ, you are being steered and the rest of the diagnosis is wasted until that is resolved. A portal address in particular will happily accept the TCP connection and then stall, which is why it can look like a firewall drop when you test with a browser.

Now confirm the address you intend to reach is the one being used. Some clients cache the previous resolution for the life of the profile, so a reconnect after the DNS change still goes to the old address. Close the client completely before retesting, rather than pressing disconnect and connect in the same window.

Find out which outer packet disappears

The tunnel has an outer flow that belongs entirely to the path between you and the server, and it is that flow which middleboxes classify and drop. Capture it on the client, then compare a working network with the failing one. On Windows the built-in capture is enough for a first look:

pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl

What you want to see is whether your packets leave at all, and whether anything comes back. Packets out with nothing in return means the path or the far end is dropping them; nothing out at all means the client never got as far as sending, which points back at name resolution or at a local firewall policy.

Repeat the same test on a phone hotspot. This is the single most informative comparison available to you, because it removes every box in the hotel from the path while keeping the laptop, the client and the credentials identical. If the tunnel comes up on the hotspot, stop looking at the server. If it also fails there, you have a client or account problem that the network was never causing.

Change one transport and retest

Once you know the outer flow is being dropped, the practical question is which flow the network does permit. Most restricted networks permit outbound TCP 443 because they cannot function otherwise, so moving the listener there is the usual answer. On OpenVPN that is a client-side switch until the server is changed:

openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4

IPsec clients have an equivalent knob in their own settings panels, usually described as IPsec over TCP or NAT traversal. Changing it is a diagnostic too: if the tunnel comes up over TCP and dies over UDP, you have proved the network filters UDP, and you have also found the setting you will need every time you visit that site.

Resist the temptation to disable router features on the first attempt. Turning off stateful inspection or flood protection on a hotel network is not available to you anyway, and on your own equipment it trades a real protection for one laptop. Note which setting changed the outcome, then put it back and look for a transport the network already allows.

Verify the same profile on the second network

Before you close the ticket, prove the change survived leaving the building. Reconnect on the original network with the original settings, capture the first thirty seconds, and confirm the client reaches the same state it reached on the hotspot:

pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress

The distinction the last command exposes is worth keeping: the profile can report a connected tunnel while the routing inside it is wrong, and that produces "the VPN is up but nothing works", which is a different article. If the tunnel type changed after your edit, the profile is not the one you tested.

Then write the finding where the next person will look. "Corp profile needs TCP 443 at this site; UDP 500 is filtered by the hotel" is a sentence a colleague can act on. "VPN flaky at hotels" is not, and it guarantees that the same hour gets spent again next month.