One thing I can’t decide with OpenVPN is whether to use UDP or TCP for the tunnel. The online guides for this are nonsense, babbling about how “TCP is more reliable so use it if you don’t want corrupted file transfers”. That’s not how it works.

My own impression is UDP is clearly a better choice for low level IP tunneling, in the abstract. The OpenVPN community seems to prefer UDP as well. OTOH it may not always work. Some networks don’t really route UDP correctly and I have a suspicion random UDP ports are more likely to be blocked than random TCP ports. (Best idea; run your VPN endpoint on TCP port 80. Ugh.)

In practice, from my Grass Valley client with the weirdo fixed wireless network, UDP isn’t working. Well it sort of works but the link is limited to 60kbps instead of the burst max of 2000kbps, and it’s flaky. Online docs suggest this is an MTU problem, in particular if you don’t have MTU path negotiation working. I could well believe I don’t. This FAQ suggests setting “mssfix 1200” as a workaround but it didn’t help. I tried the “tun-mtu 1500 fragment 1300 mssfix” config the docs suggest as a workaround but that broke the connection entirely. No idea why, but the log had some warning about “FRAG_TEST not implemented”. Maybe it’s because I only set it on one side of the tunnel (see this FAQ). Whatever, TCP is working, I’ll stick with that.

My Mac has another problem where the network doesn’t work for the first ~30 seconds after the VPN link establishes. It feels like some sort of timeout problem, maybe it’s using the wrong route or DNS is messed up or something. It may be specifically a Chrome problem.

Update: months later I realize this was a router QoS problem.

3 thoughts on “OpenVPN: UDP vs TCP

  1. From what I’ve read, OpenVPN performance over TCP will drop dramatically if the connection is unreliable primarily because TCP will retry failed packets. Here’s the open ticket on the OpenVPN tracker.

    I currently forward UDP Port 53, i.e. DNS from my router for OpenVPN traffic but like you I find UDP traffic is often blocked in places like hotels or coffee shops. I’m planning to run OpenVPN on TCP 443 as well as an alternative but I wonder if the performance penalty will make it unusable.

    1. Hey Balaji! Thanks for the reply. Yeah I was worried about TCP-over-TCP having problems like that. I’m surprised that in basic testing it works well. In particular, TCP’s rate limiting algorithm seems to be working through it. I’m running my tunnel server on a 100 Mbit connection and am using it on a (max) 2.5 Mbit connection, and I’m getting an honest 2.5 Mbit. I don’t quite understand why that works but it seems to.

      Running the tunnel server on port 443 is clever. HTTPS is unlikely to be blocked and unlike port 80, I’m not actually using that one at the moment. Thanks for the suggestion!

      1. Follow-up on using Port 443/TCP for OpenVPN. I typically want to use my VPN connection when connecting from public WiFi or Hotel hotspots. In those circumstances, using Port 443 makes a lot of sense because in TCP mode the OpenVPN client initially issues a TCP connect command. Most popular Web proxies/Hotspot proxies will explicitly block TCP connect commands on ports other than HTTPS, so this is a good way to get around that limitation.

Comments are closed.