OpenVPN works at home but not on one network: UDP or TCP?

The same profile connects from home and stalls on a hotel, campus or branch network. Credentials did not change, so the interesting variable is the path: what happens to the packets before OpenVPN reads them. Comparing four candidate causes in the order they can be tested beats guessing at certificates. Each one leaves a different trace, and the trace is what separates them.

Which stage failed tells you which comparison matters

The client log already records how far you got. A line saying TLS key negotiation failed to occur within the timeout means a first packet left and nothing usable came back, which points at the path. A certificate rejection looks nothing like it: a response arrives, then a specific verification error names the reason. Note the last line before the retry loop, because that is the value you compare across networks.

Capture while retrying rather than afterwards. On the client, tcpdump -ni any udp port 1194 shows whether any reply comes back at all. Repeat it on the WAN interface of a server you control, which reveals whether those packets reach the far end at all.

One-sided traffic is the most useful result available here, because it turns an intermittent complaint into a direction to investigate. Keep the capture files, because the next report of the same problem is easier to close with evidence than with a description.

UDP filtering versus a closed port

Many access networks treat sustained UDP as suspicious, and some ISPs agree with them. A closed port produces the same silence from the client's side. The difference is selectivity: a filter tends to be picky about which destinations or ports it drops, while a closed port refuses everything aimed at that one port.

A TCP profile on port 443 is the usual workaround, because it resembles an ordinary HTTPS flow and passes most captive portals and egress filters. Two conditions have to hold. The server must listen with proto tcp-server and the client must match with proto tcp-client, and the operator has to publish that alternative endpoint. Rewriting a working UDP profile to claim TCP 443 gets nowhere when nothing is listening at the other end.

A closed port is a configuration problem rather than a censorship problem. A server sitting behind a home router needs its UDP port forwarded, and the router firewall has to permit it. When the port was never allowed, every client fails at negotiation regardless of credentials, and the failure follows the server instead of the network.

Older protocols compare badly on this axis. PPTP needs TCP 1723 plus GRE, and GRE is IP protocol 47 rather than a port, so no ordinary port forward expresses it.

When the switch is the one dropping packets

A managed switch can drop the tunnel on purpose. Some HPE and Aruba models expose a UDP flood protection control, occasionally labelled Prevent UDP Blat Attack, in their advanced security section. Once that control is active, a server sitting behind the switch answers nothing and every client times out in the same way. Clearing it and saving the running configuration is the whole repair, but only after you establish that the switch is actually in the path.

Counter evidence is what separates a switch drop from a provider block. Read the interface counters and the flood-protection log before opening a ticket with the ISP. Consumer routers with DoS or flood protection fail in the same shape, and so does any middlebox with a short UDP idle timeout. A handshake that never completes suggests a drop, while a tunnel that dies after minutes of quiet suggests the timeout.

Write down every device between the client and the server before changing a profile. A fix applied at the wrong layer looks correct until the next network. That list also tells the next engineer where to look without repeating the whole investigation.

An address overlap that looks like a DNS failure

An access network numbered inside 10.0.0.0/8 can overlap the tunnel pool, and the resolver usually lives inside that pool. When a laptop receives an address such as 10.184.178.50 with a /8 mask on Wi-Fi, every 10.x destination is local by definition. Packets for 10.4.0.1 then go to the LAN, the tunnel stays up, and name resolution fails.

ip addr exposes the overlap at a glance, and ip route get 10.4.0.1 shows where the packet would really be delivered. Because the visible symptom is a resolver failure, this one often survives several rounds of DNS changes.

Renumber the pool or keep that access network out of scope. No client-side setting recovers from an overlap.

Deciding between a TCP fallback and a path fix

Choose the TCP fallback when you do not control the path and users need to work today, and accept its costs: TCP inside TCP behaves badly on lossy links, and the fallback needs a listener you operate. Choose the path fix when the block sits on infrastructure you own, because a firewall rule is cheaper than a second listener. Either way, work through the layers in order: link, outer transport, negotiation, inner routing. The stage that failed on that network is the only fact that matters.

Record the result per network rather than per user. The next report of the same failure then starts from a known stage instead of from a certificate theory. That record is also what justifies a permanent second listener, if one is ever needed.