OpenVPN TCP 443 to bypass a firewall

Restrictive networks tend to block by category rather than by target. They permit a small set of outbound ports and drop everything else, which catches most VPN defaults on the way past. An OpenVPN TCP 443 profile is the standard answer when a firewall drops UDP, because TCP 443 is the one port such a network almost cannot close.

This page covers the mechanism, the cost, and the point at which the technique stops working. It assumes you have already established that UDP is not getting out.

A network that filters aggressively still has to let people work. That obligation is what you are exploiting, and it is worth being precise about what it actually guarantees.

• TCP 443 carries HTTPS, so closing it breaks every website and every business tool
• TCP 80 carries plain HTTP and captive portal redirects, so it usually stays open
• Mail submission ports are commonly permitted on hotel and campus networks
• Almost everything else, including most UDP, is dropped by default

Note what that list does not include. UDP 443 carries QUIC and HTTP/3, and it is frequently dropped even where TCP 443 is open, because dropping it makes browsers fall back to TCP rather than fail. A network can block UDP 443 without breaking anything visible, so it often does.

OpenVPN's own documentation sets out the same order of preference. Access Server "works best over UDP", and "TCP 443 is the preferred fallback option when firewalls block UDP" (blog.openvpn.net/vpn-server-behind-firewall). Fallback is the correct word. This is not the configuration you want by default.

Two directives carry the change, and both live in the .ovpn profile.

Set the transport with proto. The OpenVPN 2.6 manual documents three values for the option itself, udp, tcp-client and tcp-server, plus address-family forms such as udp4, tcp4-client and tcp6-client (openvpn.8, 2.6). The default is udp when --proto is not specified. A client profile therefore wants tcp-client, which is why older profiles write it that way.

Set the destination with remote <host> 443. The manual gives --remote three arguments, a host, a port and a protocol, and states that "the proto argument indicates the protocol to use when connecting with the remote, and may be tcp or udp". That is where the bare tcp you see in most profiles comes from. It also documents 4 and 6 suffixes here, giving udp4, udp6, tcp4 and tcp6. A per-remote protocol means one profile can hold several endpoints with different transports.

Both ends have to agree. The server must be listening for TCP on port 443, and a client-side edit alone achieves nothing if it is not. Providers that support this ship a separate profile rather than expecting you to edit one. Import a different file rather than changing a line.

In profile terms the difference between the two transports is two lines.

proto udp
remote server.example.net 1194

proto tcp
remote server.example.net 443

Everything else in the file usually stays the same. The <ca>, <cert>, <key> and <tls-crypt> blocks are unchanged, because the credential does not depend on the transport. That is why a provider supporting both can issue two profiles that differ only in those two directives.

Verify the result rather than trusting the connection status. Watch the client log for the line reporting a completed initialisation, then confirm that traffic actually routes by requesting something over the tunnel. A TCP connection that establishes and then closes after a few seconds is a different diagnosis from one that never establishes, and the log distinguishes them.

One server-side option is worth knowing about, because it explains why some deployments look like ordinary web servers. The manual documents --port-share host port [dir] as a way to "share OpenVPN TCP with another service". It proxies non-OpenVPN connections on the same port to a real web server behind it. You cannot enable it as a client, but its presence changes what an observer sees.

Whichever form your provider ships, read those two lines before you import the file. They decide where the client dials and how, and everything else in the profile follows them.

The cost is real and it is structural rather than incidental.

OpenVPN over TCP puts a reliable, retransmitting, congestion-controlled transport inside another one. When the outer connection stalls, the inner connection cannot tell the difference between congestion and delay, so it retransmits data the outer layer is already retransmitting. Both timers then back off against each other. The failure mode has a name worth searching for, TCP meltdown, and the mechanism above is what that name describes.

Be careful with what follows from that. The effect is worst on lossy or heavily congested paths, and on a clean network the difference is often modest. No figure appears on this page, because no figure was measured here. The numbers circulated for this effect vary widely depending on the test conditions, and a percentage copied from someone else's path tells you nothing about yours.

Two smaller costs are more predictable. Latency increases because acknowledgement handling is duplicated at two layers. And a stalled outer connection blocks everything behind it, so one lost segment can hold up traffic that UDP would have delivered out of order and moved past.

Read the last row carefully. A long-lived session on TCP 443 blends into ordinary traffic by port, and that is the entire benefit. It does not make the traffic indistinguishable from a browser session to anything that inspects the flow properly.

For the deeper protocol differences behind this table, see how the two protocols differ.

Be honest about where the technique stops, because the failure is silent and you will otherwise keep trying.

Deep packet inspection. A network can classify a flow by its handshake and its packet timing rather than by its port. OpenVPN's own guidance names the obstacle plainly: some firewalls perform deep packet inspection, which can interfere with encrypted VPN traffic. If a TCP 443 profile connects and is then torn down after a few seconds, inspection is a candidate worth taking seriously.

Protocol classification. Port 443 hides you from a port filter. It does not hide you from anything that reads the flow rather than the port number, and an OpenVPN control channel is not a browser session. Treat the port as camouflage against a rule, not against an analyst.

Captive portals. No transport helps before the portal has been satisfied. The network drops everything until a browser session authenticates, and a VPN profile of any kind fails until that is done. Complete the portal login first, then connect.

Server-side absence. If your provider does not run a TCP 443 listener, no client configuration reaches one. This is the most common reason the technique appears not to work, and it is not a network problem at all.

Checking whether anything is listening

TCP is testable in a way UDP is not, and that is the one diagnostic advantage of this transport. A TCP port either completes a three-way handshake or it does not, so you get an answer in a second rather than a 60-second timeout.

nc -vz vpn.example.net 443
Test-NetConnection vpn.example.net -Port 443

The first form is macOS and Linux, the second is Windows PowerShell. Read three outcomes differently.

A successful connection means something is listening and the network let you reach it. Any failure after that point is a profile or key problem rather than a filter. A connection refused means you reached the host and nothing answered on that port, which is the server-side absence above. A timeout means you never reached the host at all, so the filter sits between you and it.

Run it from a permissive network as well as from the one that is failing. A connection at home and a timeout in the hotel is the cleanest evidence you can gather that the network is at fault.

Treat the fallback as a second tunnel rather than as an edit to the first.

1. Import the TCP 443 profile as a separate entry, keeping the UDP profile intact. See importing the fallback profile.
2. Bring the UDP tunnel down fully before starting the TCP one, so two clients do not compete for the same routes.
3. Update any firewall rules that allow traffic to a specific server IP address and port, because those rules were written for the other endpoint.
4. Confirm the new tunnel passes traffic before assuming the switch worked.

Step three is where people lose an afternoon. A kill switch built around a default-deny outbound policy usually contains one allow rule naming the VPN server address and port. Point that rule at the UDP endpoint and it will silently block the TCP 443 handshake, producing a failure that looks exactly like network filtering. Check the rule before you blame the hotel.

Keep the client-side transport flags in mind too. resolv-retry infinite, float and the keepalive settings all behave differently on a TCP connection than on a UDP one, and they are documented in OpenVPN transport options. For the import path on each platform, see using an OpenVPN profile.

The worst time to discover that you do not have a TCP 443 profile is on a network that will not let you download one. That is not a hypothetical constraint. If the network blocks your tunnel and you have no second profile, you are downloading a credential over the same untrusted link you were trying to protect.

Prepare four things before you leave, and test each one on a network you control.

• Download the UDP profile and confirm it connects
• Download the TCP fallback profile and confirm it connects independently
• Write down the firewall allow rules for both endpoints
• Store both profiles somewhere reachable without the tunnel

This is the preparation argument in the travel VPN checklist, applied to one specific failure. The diagnosis side, including how to tell a blocked port from a blocked protocol before you switch at all, is covered in hotel wifi blocking WireGuard.

One product question decides whether this option exists for you at all. Ask any provider which of its endpoints listen on TCP 443 before you travel, because no client-side edit can invent a listener that is not there.

Where PulseVPN sits on this

PulseVPN supports both WireGuard and OpenVPN, and both are delivered as config files rather than through an app. The OpenVPN answer here is specific, so it is worth stating rather than leaving you to look.

Every PulseVPN profile connects on port 80. Each per-server download is a ZIP holding two files, one on UDP and one on TCP, and both name port 80. There is no TCP 443 profile, so do not spend time hunting for one in the dashboard. The file you want on a network that drops UDP is the TCP profile already sitting in that ZIP.

Port 80 earns its place on the same argument as port 443. It carries plain HTTP and captive portal redirects, so a network that closes it breaks the first page every guest tries to load. That is why it appears alongside TCP 443 in the list at the top of this page, and it is why a TCP profile pointed there usually gets out.

Be clear about what differs. Port 443 is expected to carry encrypted traffic and port 80 is not. An encrypted flow on port 80 therefore stands out to anything reading the traffic rather than the port number. Against a port filter the two are close to equivalent. Against inspection, neither one hides you, which is the point made in the section above.