VPN deals Advertisement

OpenVPN over TCP vs. UDP: Which should I choose?

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 relation  to 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 acknowledgments 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 media , 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, is increasingly common to see SSL encryption deployed on all kinds of websites.

tcp vs udpSSL 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.

The interesting thing for OpenVPN (which is based on the OpenSSL libraries) is that if 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 detect 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

I am a freelance writer, technology enthusiast, and lover of life who enjoys spinning words and sharing knowledge for a living. You can now follow me on Twitter - @douglasjcrawf.


  1. 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 www.address.com. 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.

  2. 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!

  3. van
    on May 21, 2016

    Thanks for post! I have one important question: Does TCP in applications will be reliable if I will use it through UDP VPN? For example I have VPN server with some application listen TCP on and I will connect from TCP from host to Will it be reliable ?

    1. Douglas Crawford replied to van
      on May 23, 2016

      Hi van, TCP requires packet authentication, so yes, it should be reliable. If any packets are lost due to routing via a UDP VPN connection, your TCP connections may slow down, however, because they are waiting for any lost TCP packets to be resent. In practice I doubt that you will notice this unless your VPN connection is very unstable..

  4. Ioanna Andreeva
    on May 2, 2016

    Does SSL only run on TCP? I am using UDP, does that mean i have the normal OpenVPN, which is not being protected by SSL layer?

    1. Douglas Crawford replied to Ioanna Andreeva
      on May 3, 2016

      Hi Ioanna, OpenVPN use the OpenSSL library and SSLv3/TLSv1 protocols, along with an amalgam of other technologies, to provide a strong and reliable VPN solution. So yes, your OpenVPN connection is always protected by an SSL layer (in both TCP and UDP configurations). TCP port 443 is the port used for regular HTTPS connections (HTTP over SSL), so running OpenVPN on TCP port 443 hides the fact that you are using OpenVPN (as it now looks exactly like regular HTTPS traffic). This also makes it very difficult to block OpenVPN without blocking access to all SSL-secured (HTTPS) websites.

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.