Why an OpenVPN profile works at home but fails in a hotel

Office Wi-Fi and a hotel room can hand the same laptop two very different networks, and the profile in between has no idea. What works at home assumes a permissive uplink, working name resolution, and a local subnet that does not collide with anything the tunnel carries. Each assumption can fail independently.

The useful way to debug this is to treat the network as four separate facts, then test them in order. Guessing at the profile first usually produces a change that fixes nothing and obscures the evidence.

Four network facts change between locations

The first fact is whether the local network lets you out at all. A captive portal admits a device to a login page and blocks everything else until that page is completed, which means the tunnel cannot start no matter how correct the profile is.

The second is name resolution. A portal that intercepts DNS answers every query with its own address, so the VPN hostname resolves to the portal and the client tries to build a tunnel to a web page.

The third is transport filtering. Networks that want to allow only browsing will pass TCP 443 to arbitrary destinations and drop almost everything else, including UDP.

The fourth is addressing. The local subnet may overlap a network behind the tunnel, or the uplink may provide no usable IPv4 path at all.

Resolution and the captive portal

Replace the hostname in the profile with the server's numeric address and try again. If the IP connects and the name does not, resolution is the fault, and the profile itself is fine.

Open a browser and attempt an ordinary HTTP page before touching the VPN. A redirect to a sign-in page means the portal is still pending; complete it, then reconnect. Many hotels also expire the session after a few hours, which looks like a mid-day disconnect rather than a login problem.

If the numeric address also fails, resolution is not the explanation, so move to the transport. Keep the address you tested, because it tells the next check whether packets left the machine at all.

Transport filtering: UDP first, TCP 443 as fallback

An OpenVPN flow over UDP 1194 looks like nothing a hotel firewall recognises, so it is dropped without an error. The client retries until its timeout expires, and the user sees a connection that never establishes rather than a refusal. Firewalls that behave this way rarely log the drop anywhere you can see it. The absence of a refusal is itself the clue.

TCP 443 is the reliable fallback because the network cannot distinguish it from ordinary HTTPS. Use the operator's TCP profile when one exists, since the server must also be listening on that transport and port; changing only the client produces a different kind of failure. If no TCP profile exists, ask the operator rather than inventing one by editing the port. The server side has to agree, and a mismatch looks like a firewall problem all over again.

Expect a performance cost. TCP inside TCP amplifies retransmissions on a lossy link, so a TCP tunnel that works may still feel slow on a congested hotel network. That is a trade for reachability, not a fault to chase.

Address collisions and IPv4-less uplinks

A tunnel can establish and still carry nothing. When the local LAN and a remote network share a prefix such as 192.168.1.0/24, the client considers the remote host directly connected and sends the packet to the local link instead of the tunnel. The symptom is a successful connection with one unreachable subnet, which is easy to misread as a server-side route problem.

The permanent fix is to move the remote LAN to an uncommon private range. Choosing a range nobody uses at home, such as 10.42.0.0/24, prevents the problem for every future location instead of one. The local workaround is to avoid that hotel, hotspot, or router, which is not a fix at all.

Mobile uplinks add two variations. Carrier-grade NAT means inbound connections do not arrive, which matters if you are hosting a server but not for an outbound client. An APN configured as IPv6-only with NAT64 translation can fail a client that insists on a real IPv4 path, and changing the APN protocol to IPv4 or dual stack is the usual remedy.

Symptoms after the tunnel is up

A tunnel that connects and then goes quiet is usually a keepalive or MTU problem, not a blocked port. A connection that drops after a fixed number of minutes points at a keepalive or renegotiation timer. Set the client to probe its peer and restart when replies stop, and test a smaller tunnel MTU if pings succeed while large transfers stall.

Before you ask for help, write down three things: the address you tried and whether it answered, the transport and port you used, and the local subnet of the network that failed. Together they separate name resolution from transport filtering from an address collision, which are the causes that survive contact with evidence.