OpenVPN Won't Connect on Hotel Wi-Fi? Try TCP 443

Open the client, press Connect, and read the status line instead of the dialog that follows it. A profile that stalls on Connecting or Waiting for server after a hotel, campus or mobile network has usually lost its transport somewhere on the path, not its credentials. The useful next step is to learn what that network carries before you touch the server. Change nothing until the same profile has worked somewhere else.

Test from a phone hotspot first. If the tunnel comes up there, the server, the certificate and the account are all fine, and the only variable left is the network in front of you.

Start at the Client: Read the Status Line

The status line tells you which stage failed. A client stuck at Connecting is still resolving the host or opening the outer socket; one that reaches Waiting for server has a path but no reply; one that authenticates and then drops has a different problem entirely. The client log and the profile's own remote and proto fields show what the client is trying to do, and --verb 4 on a command-line client prints the same detail. Comparing that with the network in front of you is what turns the VPN is blocked into a specific claim.

Then probe the network with tools you already have. nc -vzu 203.0.113.10 1194 sends a UDP datagram, curl -v telnet://203.0.113.10:443 reports whether a TCP handshake completes, and a browser that loads an HTTPS page proves only that outbound 443 reaches that one host. Small probes answer what the VPN client cannot: which port and protocol leave this network at all.

Three network behaviours look alike from the client and need different answers. Outbound 443 may be open, only a proxy may be allowed, or 443 may be forwarded transparently to an inspection box that cannot read what it carries. The first is fixed by the profile change below, the second by proxy settings, and the third may complete a handshake and then stall when the inspector decides it dislikes the stream. Knowing which one you face is the difference between a ten-minute change and an afternoon of reinstalling clients.

Move the Listener and the Profile Together

Server side, set the listener to what the network permits: port 443 and proto tcp in the server configuration, then restart the service and confirm the socket with ss -lntp. Client side, the profile has to agree, because transport and port sit outside the tunnel: proto tcp and port 443 in the .ovpn, or the matching fields in the app's settings screen. A profile still aimed at UDP 1194 fails exactly as before, and the temptation is to blame a firewall that is already fixed. If the same host also answers HTTPS on 443, the two listeners cannot share that address and protocol; give the VPN a second address or put a demultiplexer in front.

Watch the first connection through with tcpdump -ni any port 443 on both ends. Packets that leave the client and never arrive mean the network filters after all, or the address in the profile is not the one you assume. Packets that arrive with no reply send you back to the server log, where a protocol mismatch shows up immediately as a dropped packet.

When Only a Proxy Leaves the Network

Some guest networks allow nothing but an HTTP proxy, which is a different constraint from a closed port and rules out more than OpenVPN. Clients that speak only PPTP, L2TP/IPsec or bare IPsec have no way through one, because those designs expect their outer protocol to reach the server directly. OpenVPN can, with http-proxy proxy.example.net 8080 in the client profile, provided the proxy permits the CONNECT method to your port. A SOCKS proxy is easier still, because it forwards the stream without caring what is inside it.

Where the client has no proxy support, an SSH tunnel over 443 is usually what remains. It adds a second layer, and the operator of the network may have an opinion about it, so treat it as a bridge for one trip rather than an architecture.

Price the Fallback Before You Keep It

TCP inside TCP has a known cost. When the outer connection is TCP and the payload is TCP too, a lost segment triggers retransmission at both layers, and the inner connection backs off from a loss it cannot see. Browsing survives that; interactive sessions and calls feel it. Keep the TCP 443 listener as a fallback for networks that demand it, and leave UDP as the default for everything that still passes it.

Record the choice in the profile name and in the support notes: which port, which protocol, and which network prompted it. Then ask the network's administrator whether that port stays open after the next equipment refresh, because a fallback that silently disappears is worse than no fallback at all.