Black Friday

OpenVPN over TCP vs. UDP: what is the difference, and which should I choose?

Douglas Crawford

Douglas Crawford

agosto 23, 2013

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.)

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.

27 respuestas a “OpenVPN over TCP vs. UDP: what is the difference, and which should I choose?

  1. 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 http://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. Hi Khilwat,

      All websites (except dark web sites) start with either http or https. If one just says http://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. 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. 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. @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: 172.18.0.0/22
      OpenVPN Subnet: 172.18.4.0/28
      multicast Subnet: 224.0.0.0/8 (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. 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. 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. 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 10.8.0.1:8080
    and I will connect from TCP from host 10.8.0.2 to 10.8.0.1:8080. Will it be reliable ?

    1. 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. 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. 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.

  5. About Port 25 support!

    Please, I would like to confirm, if port 25 is opened in your VPN for Desktop client or Bulk email senders?. Thanks for your kind answer.

    1. Hi Prince Coleman,

      I can’t speak for every VPN provider, but yes, Port 25 is usually open when using a VPN client, allowing you to send email as normal.

  6. I experience a lot of idle traffic using UDP – about 1 KByte/s per Client which sums up to about 500 MB a day for 8 clients. That’s way to much for a limited LTE/HSDPA connection.

    I read some links ago that OpenVPN via TCP produces nearly no traffic on idle. Is there someone that confirms to that?

    1. Hi Boandlgramer,

      By “idle traffic” do you mean lost/undelivered network packets? If so then switching to TCP will fix the problem because it uses error correction (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). In any case, why not just switch to TCP and run tests to see if this fixes the issue you are experiencing?

  7. Awesome post on the difference between these 2. Though I was wondering if I Use tcp will I not disconnect from a game randomly since the packets are guaranteed to reach? Since I’m playing an online game that requires a vpn. The UDP speed is kinda drawing me to it more though.

    1. Hi Anonymous,

      Thanks. Using TCP may not stop you disconnecting (depending on the cause of disconnection,) but assuming that you have some connection, it will guarantee that all packets get through. If you are experiencing regular disconnections you can certainly try using TCP to see if it helps, or else contact your provider (although this may be an issue relating to your ISP or local internet environment, rather than anything to do with the VPN per se.).

  8. Keep in mind that if your internet connection is not reliable itself, UDP data wont reach the destination properly and that causes more data loss in overall while a TCP connection at least helps the reliability of communications.

  9. Thanks, this is what I needed: a concise explanation.

    I just set up my first VPN connection and am using it now.
    Based on this article I chose the UDP file.

    Already changing clients from Tunnelblick to SoftEther, hoping it’s faster.

  10. hey,

    we experience high paket loss when using brigded network with TCPoverTCP via a 10Mbit link instead of 2Mbit. Over the 2Mbit link everything is fine but the latencies – but that is a thing we can live with because we have lots of GSM/UMTS road warriors. We want to change to briged network via TCPoverUDP to improve performance.

  11. Take UDP:
    Using TCP holds the risk of variable delay e.g. because of packet loss at the VPN tcp layer. This delay can be interpretted as packetloss by the tcp stack for the traffic in the tunnel. As a result it can lead to multiple retransmits on multiple layers. E.g. a single packet loss at the VPN layer could trigger a retransmit for multiple packets within the tunnel, for packets that are not lost to begin with as these packets are guaranteed to be delivered by the TCP stack of the tunnel.

    1. Hi Ruud,

      That is exactly right, and is why UDP is faster than TCP (I was trying to keep the article as simple and layman friendly as possible). Basically, unless you are experiencing problems (packet loss), you should stick with UDP.

    2. Seriously, take UDP:
      Using TCP even makes no sense as your protocols INSIDE the tunnel will again use TCP for reliable data transfers.
      And as Ruud S says, TCP over TCP is a bad idea.

      The only reason to use TCP (e.g. on Port 443) is for traversing restrictive Firewalls.

    1. That is not entirely correct, there is one right way, and its UDP over VPN, all of the posts (and article) above are partial knowledge.

      TCP protocol is reliable delivery to IP an address, that’s why TCP/IP is used, receive windows and packet ordering is what slows it down.

      UDP is unreliable on its on, but VPN guaranties point to point delivery, that’s why using UDP over VPN guaranties packet delivery to the end point (just like TCP/IP), with less overhead/conjection.

      Thats why UDP/VPN is better, faster, and is the right way.

      Cheers!

      1. TCP over port 443 disguises VPN traffic as regular HTTP which is a way of concealing VPN use. It is a valid method that (as you say) can slow your traffic down a little. That is why it isn’t recommended for streaming etc. However, it does have its uses!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Your Information will never be shared with any third party.
Enter your email address to receive your Beginner's Guide to Online Security for Free
You'll also receive great privacy news and exclusive software deals!
Enter your email to get the ebook:
Your Information will never be shared with any third party.
Enter your email address to receive your Ultimate Online Privacy Guide eBook!
You'll also receive great privacy news and exclusive software deals!
Enter your email to get the eBook:
Special VPN Deal
SAVE 49% TODAY
WITH OUR
Exclusive Offer
Get a Special Deal - 72% OFF!
With a biannual subscription
Exclusive Offer for BestVPN.com Visitors!
50% Off Annual Plan
Limited Time Only
Exclusive price of
$3.25/mo
Exclusive Offer
SAVE 72% TODAY
LIMITED TIME OFFER
Get NordVPN for only
$3.29/month