OpenVPN over TCP vs. UDP

OpenVPN can run over either the TCP (Transmission Control Protocol) or UDP (User Datagram Protocol) transports. Choosing which one to use is a highly technical issue, and one that most VPN providers (quite understandably) keep hidden ‘behind the scenes’.

Some VPN providers, however, prefer to let customers choose which connection protocol they prefer. The reason for this is that while both offer distinct advantages and disadvantages in each other, choosing which is ‘best is’ difficult, as it depends what the internet is being used for, and what matters to individuals most – speed or reliability.

The Difference

TCP vs UDP, OpenVPN vs TCP, UDP vs OpenVPN... What is the difference, exactly?

TCP is, in general, the most commonly used connection protocol on the internet, as it offers error correction (and is therefore known as a ‘stateful protocol’). Whenever a computer sends a network packet using TCP, it waits for confirmation that the packet has arrived before resending the packet (if no confirmation is received), or sending the next packet (if confirmation is received). 

This means there is ‘guaranteed delivery’ of all data, making the protocol very reliable, but there is a considerable overhead as packets are sent, confirmed, re-sent etc., making it quite slow.

UDP is referred to as a ‘stateless protocol’ as it performs no such error correction, simply receiving packets with no or retries. This makes it much faster, but less reliable.

  • TCP = reliable
  • UDP = fast

Which one to use?

Which one you use, therefore, depends on whether reliability or speed is your primary concern, and, in general, UDP is better for streaming VoIP, and playing games online.

However, how much TCP actually slows a connection down in practice can be very dependent on other network factors, with distance being the most important. The further away you are from your VPN server geographically, the further TCP packets have to travel to and fro, and therefore the slower your connection will be. If the server is relatively close-by, then you may not see much of a speed loss, while benefiting from a more reliable connection.

That said, probably the best general advice is to use the faster UDP protocol unless you experience connection problems, which is the strategy adopted by most VPN providers by default.

Defeat censorship with OpenVPN on TCP Port 443

When you connect to a secure website your connection is protected by SSL encryption. You can tell that a website is secure because its URL (web address) begins with https: and a closed lock icon should appear to the left of your browser's URL bar. Traditionally it was mainly banks and online shops etc. that used SSL, but with growing public concern about internet security, it is increasingly common to see SSL encryption deployed on all kinds of websites.

SSL is the cornerstone of security on the internet, and any attempt to block it effectively breaks the internet (which hasn't stopped places such as Iran trying!). SSL runs over TCP port 443.

tcp vs udp

The interesting thing for OpenVPN (which is based on the OpenSSL libraries) is that configured to run on TCP port 443, OpenVPN traffic looks identical to regular SSL connections. This makes running OpenVPN over TCP port 443 ideal for evading censorship as:

  1. It is very difficult that OpenVPN is being used rather than regular SSL
  2. It is almost impossible to block without breaking the internet.

Some custom VPN clients allow you to select TCP port 443, or it can often be configured manually (ask your VPN provider for settings.)

Written by: Douglas Crawford

Has worked for almost six years as senior staff writer and resident tech and VPN industry expert at Widely quoted on issues relating cybersecurity and digital privacy in the UK national press (The Independent & Daily Mail Online) and international technology publications such as Ars Technica.


  1. Robert

    on November 9, 2019

    Hi Douglas. Thanks for this post. I wonder. UDP is fast, but TCP is more reliable. Do you know how this effects the VPN in practice? Could the next problem be caused by UDP? We are experiencing some problems with OpenVPN and RDP. When users scroll PDF's or have other high load screen-updates (like animated things of the Windows 10 user-interface), the VPN sometimes stalls for a moment. PING's time-out. RPD freezes and reconnects after a while. Sometimes the OpenVPN log shows "Authenticate/Decrypt packet error: bad packet ID (may be a replay)". People suggest to use TCP in stead of UDP. I can imagine that a heavy load is more likely to have problems with UDP packets coming over in the wrong order, causing the replay-error. TPC packets, I guess, are confirmed packet after packet, in the correct order. If I test with UDP or TCP and scroll through PDF's, it looks like TCP is always very slow. UDP seems fast until the moment it 'breaks' and I have to wait +/- 20 seconds to reconnect. Is this a known phenomenon? Do you think it's caused by UDP and a less-good internet (like WiFi)? Do you know of a way to automatically fallback to TCP when UDP 's performance is bad? Thanks for your help! Robert

    1. Douglas Crawford replied to Robert

      on November 11, 2019

      Hi Robert. I'm afraid I have not encountered this problem before. UDP is faster and is the "plain vanilla" way OpenVPN should work. In fact, if you talk to network engineers about OpenVPN over TCP they will screw up their faces and start using words like "ugly." OpenVPN over TCP is very inefficient. Its a cludge that can work when regular OpenVPN connections are blocked, but it is a cludge. So unless someone is actively blocking your OpenVPN connections (which doesn't sound like its what is happening, then I don't think UDP is the issue. I would blame other factors such as poor WFii or slow VPN servers (where distance is a big factor - don't connect to European servers from Australia and expect to get a fast connection!).

  2. David

    on July 15, 2019

    Hi dear Douglas Thank you very much for sharing this helpful article You mentioned Iran in this article unfortunately the dictatorship regime sometimes blocks vpn ports and only a few numbers of vpns work correctly!!! for me, I configured openvpn on the DD - WRT router and use vpn providers such IPVANISH and NORDVPN to bypass censorship because when I use a vpn app on my phone specially on iOS the battery would die faster than normal Thanks again

    1. Douglas Crawford replied to David

      on July 22, 2019

      Hi David. We are working on a report which measures popular VPN app metrics, including their effect on device battery life.

    2. Marc replied to David

      on August 22, 2019

      Fastest VPN does not offer OpenVPN within its Windows app. Has to be configured manually. They do offer military AES encryption across all protocols That being said, if one chooses just UDP with AES encryption within their app, would one still be secure without using OpenVPN?

      1. Douglas Crawford replied to Marc

        on August 23, 2019

        Hi Marc. An increasing number of VPN services are using IKEv2 in their apps thanks to its increased performance over OpenVPN. I'm guessing this is what your VPN service is doing since IKEv2 can be routed over UDP but not TCP (the same is also true of L2TP/IPsec, but the use of this protocol has been heavily depreciated in recent years as it is known to have been cracked by the NSA). IKEv2 (which is almost always paired with an AES cipher to secure the data itself) is widely believed to be very secure, although it has not been "battle-tested" in the way that OpenVPN has. Note that OpenVPN should only really be considered secure if strong settings are used (most particularly Perfect Forward Secrecy). Please see our Ultimate Guide to VPN Encryption ( for more details.

  3. Khilwat

    on November 30, 2016

    Hi Greetings I Have IPVanish which I use regularly with UDP. But I need some websites whose addresses do not have https or http or any other sign of that kind but they are started with things like My question to you is can I think that because of these addresses I am not safe even though I am using IPvanish. I thank you in advance for your responses and help. Thanks Khilwat

    1. Douglas Crawford replied to Khilwat

      on November 30, 2016

      Hi Khilwat, All websites (except dark web sites) start with either http or https. If one just says www.something dot com, then it really starts with http (as in your example above). Your VPN will protect you whichever websites you visit.

  4. Squibt

    on November 15, 2016

    I have an Asus RT-AC56R.....Openvpn server factory installed.... Server settings UDP/1194 works fine with my client on iPad2 Switching to TCP/443 I get this message on the router server.... .......OpenVPN server daemon failed to start. Please check your device environment or contents on the Advanced Setting page..... Your site and every where I look says TCP/443 can be used....doesn't work for me. UDP/443 does not generate this message. Any Advice?

    1. Douglas Crawford replied to Squibt

      on November 15, 2016

      Hi Squibt, It sounds as if your router's OpenVPN server client is not configured to accept TCP/443 connections. Whether it can be, I'm afraid I don't know.

    2. Carl Vancil replied to Squibt

      on December 9, 2016

      @Squibt I have the Asus RT-AC66U, which uses the same exact OpenVPN server implementation as the RT-AC56R, and I also depend upon OpenVPN for remote access to my lab & LAN. When I initially received the RT-AC66U, naturally, it was running on Asus' own oem firmware, and I found that any attempts to change the OpenVPN settings tended to cause OpenVPN server to fail altogether. I went round-and-round with that firmware for a good part of an afternoon before I determined that it was most definitely a poor implementation of OpenVPN. At first, I tried upgrading my RT-AC66U with AsusWRT-Merlin firmware, and attempted to use it's implementation of OpenVPN server. Merlin works a lot better, but I still found issues with my custom network configuration --which is absolutely necessary with the way I have my network constructed: Primary Subnet: OpenVPN Subnet: multicast Subnet: (configured as a static-route on all routing devices and systems) With the Merlin firmware, OpenVPN worked, but it still had trouble with custom port implementations. But, unlike the OEM firmware, you *can* disable OpenVPN altogether within the firmware so that it can be replaced by an OpenVPN service running on another more advanced implementation. So, here's what I did: 1. After configuring the RT-AC66U, and disabling the OpenVPN server, I created a 20GB Virtual Machine (hosted on a VMWare ESXi system in my lab), and used that to host an instance of 'pfsense', which is a FreeBSD 10.x based firewall platform that has OpenVPN built-in. 1b. The pfsense VM was configured with 1 NIC, rather than 2, purposely. The reason for this is because when pfsense is fired up for the first time and only sees 1 NIC, it doesn't engage it's WAN-side firewall (this is a good thing in this instance). Once the system image was installed and I had configured the 1 NIC to a private static address on my LAN, I was able to pull up it's web-management panel and configure OpenVPN. 2. On the RT-AC66U, I had disabled OpenVPN server, so at this point, I created a port-forwarding rule for 1194/tcp to point to the pfsense VM. 2b. I finished configuring the OpenVPN instance on the pfsense VM, and then published it's configuration to an exportable .opvn file and placed that in a directory that's integrated into my Pydio-based personal cloud services, where I could easily retrieve a copy of the client-configuration over a direct HTTPS connection from anywhere. Basically, the OpenVPN version that comes stock with Asus' own firmware leaves *much* to be desired and is lucky to work at all. The build that comes with AsusWRT-Merlin isn't much better because it's based on the same source-code, but unlike the OEM firmware, the Merlin release will allow you to entirely disable OpenVPN and re-use it's default ports to map to another OpenVPN server --while the stock firmware will not allow the port to be remapped and will always claim that the port is already in use. Also note: pfsense has quite a few very useful services built-in already, and has a built-in package-manager for adding more. If you don't have an already very complex LAN, you can use the pfsense system to not only provide OpenVPN services, but also to provide NTP, DNS, and if you prefer, DHCP, Snort, and several other very useful services. In my case, I use it for OpenVPN & NTP, but I use a separate group of VMs for Active Directory with integrated AD-DNS, WINS, and DHCP. Lastly: The reason why I don't use pfsense as my primary router anymore is because I'm an avid gamer, and pfsense uses a NAT implementation that doesn't work well with game console NAT clients (PS4 or Xbox360). I've found that the NAT implementation used by Asus is excellent for my needs, while pfsense's NAT is more appropriate for a small/medium office or enterprise setting, where corporate LAN policy is shaped for business networking needs. I would still absolutely recommend pfsense to anyone wanting a strong and inexpensive router/IPS solution for their business, especially if they don't want to learn Cisco, because it's the next best thing I've found that has a comparable level of security while being *much* easier to manage. Anyway, I hope this helps.

      1. Carl Vancil replied to Carl Vancil

        on December 9, 2016

        One thing I forgot to add: the reason that I recommend using pfSense for it's OpenVPN implementation over other solutions is because it's the best solution I've found with absolutely no associated licensing fees. Prior to creating my VM implementation of pfSense, I had used it on my prior router, just prior to replacing that system with my Asus RT-AC66U. When I went looking for a replacement, I took the time to vet a few open-source solutions, and also created an instance using OpenVPN's own management system... but I quickly found that their implementation would not suit my needs because its limited to 2 simultaneous users at once. I wasn't in the mood to pay for something that I can confidently build myself, so I went on looking for other solutions and by the time all was said and done, I realized that pfSense had the best free implementation of OpenVPN that I had found that also had enough of an administration panel to be considered enterprise grade, which I needed because my home network is structured more like a corporate LAN --I've worked as a systems-engineer in state gov. for 12 years, and recently moved to a new position of Network Security Analyst; during my time in my former role, I overhauled my state's core authentication systems and created a personal model that was similar for use at home so that every day I would be using the same level of networking at home as what I use at work; it's certainly paid off in the long run, because I'm able to integrate pfSense and its implementation of OpenVPN with Active Directory for user-authentication, which totally rocks since that means that I only had to configure pfSense to communicate with AD, and configure an access group to allow pfSense/OpenVPN to determine which AD users are allowed to connect via VPN. The end results are solid. I'm able to cleanly use OpenVPN from my phone, tablets, PCs, and RPi3 systems with zero problems at this point --because, since I included the multicast subnet as a static-route entry on both my primary router and on the OpenVPN server, all local and VPN clients see the same multicast subnet, which allows me to connect Kodi over OpenVPN to my fileserver at home to stream music and video remotely. I still need to tweak my throughput a bit, but the connection itself is very stable, and the speed is overall quite acceptable (I have 100Mbit-down/20Mbit-up via Comcast, using purely my own cable modem that I purchased separately to get away from the router-modem combos given out by my ISP).

        1. Douglas Crawford replied to Carl Vancil

          on December 12, 2016

          Hi carl, Thanks for all that great advice, and for confirming that poor OpenVPN implementation in Asus firmware is the root of Squib's problems. Running pfSense in a VM is an ingenious solution, although it is probably more complex than many will be happy with!

Write Your Own Comment

Your comment has been sent to the queue. It will appear shortly.

Your comment has been sent to the queue. It will appear shortly.

Your comment has been sent to the queue. It will appear shortly.

  Your comment has been sent to the queue. It will appear shortly.

We recommend you check out one of these alternatives:

Large brand with very good value, and a budget price

The fastest VPN we test, unblocks everything, with amazing service all round

Longtime top ranked VPN, with great price and speeds

One of the cheapest VPNs out there, but still a good service