OpenVPN Explained: TCP, UDP and Security

OpenVPN is one of the oldest names that you will still see in a VPN app's settings. It first appeared in the early 2000s, it is open source, and it has been reviewed, deployed and stress-tested for far longer than most of the newer options. If you have ever seen a file ending in .ovpn or a switch labelled TCP and UDP, you have met it.

This article explains how OpenVPN works in practice: the two channels hiding inside a single tunnel, why the TCP or UDP choice changes how the connection feels, what "secure" really means for an OpenVPN setup, and how to read a configuration and troubleshoot a connection that will not start. It explains the protocol in general and does not say which protocols any specific service supports. For the wider landscape, start with what a VPN protocol is.

What OpenVPN actually is

OpenVPN is both a protocol and a piece of software. The software runs on Windows, macOS, Linux, Android, iOS and many routers. The protocol is the set of rules those programs follow to build and use an encrypted tunnel. Three traits explain most of its behaviour.

• It runs in user space. OpenVPN is an ordinary program rather than part of the operating system's networking core. That makes it portable and easy to update, but every packet has to travel between the kernel and the program, which costs some speed.
• It reuses TLS. Rather than invent a new handshake, OpenVPN borrows the TLS machinery that already secures web browsing. TLS 1.3 is described in RFC 8446, and the same ideas of certificates, key agreement and session keys apply.
• It is highly configurable. Ports, transport, ciphers, authentication methods and routing rules can all be tuned. That flexibility is a strength for administrators and a source of mistakes for everyone else.

Because it is built on standard parts, OpenVPN is not magic. It does the same job as other tunnelling protocols: it wraps your packets in encryption, sends them to a server, and the server forwards them onward. Its distinguishing features are how it does the wrapping and how many knobs it exposes.

Two channels inside one tunnel

The most useful mental model is that an OpenVPN connection is really two conversations running at the same time.

The control channel

The control channel sets things up. When you press connect, the client and server run a TLS handshake. Each side proves who it is, usually by presenting a certificate, and they agree on fresh keys. This is also where your username and password are checked, if the setup uses them. The control channel keeps running in the background and renews the keys periodically, so a stolen key has a limited useful life.

Many configurations add an extra shared secret on top of this channel, often called a TLS wrapping or TLS-crypt key. It makes the handshake packets look like noise to anyone who does not know the secret and lets the server discard unauthorised connection attempts cheaply. It is a hardening measure, not a replacement for good certificates.

The data channel

The data channel carries your actual traffic. It takes each IP packet, encrypts it with the keys negotiated on the control channel, adds an authentication tag so that tampering is detected, and sends it. Modern setups use authenticated ciphers such as AES in GCM mode or ChaCha20-Poly1305, which combine encryption and integrity checking in one step.

Separating the two channels has a practical benefit. The slow, careful work of authentication happens rarely, while the fast per-packet work runs continuously with keys that change regularly. If you want more on the encryption side, what VPN encryption is covers the building blocks.

TUN and TAP: routing or bridging

OpenVPN creates a virtual network adapter on your device, and it comes in two flavours.

Mode	What it carries	Typical use	Cost
TUN	IP packets (layer 3)	Nearly all consumer VPNs, remote access, site links	Lean, simple routing
TAP	Ethernet frames (layer 2)	Making remote machines appear on the same local network, legacy broadcast-based software	Extra overhead, more traffic, harder to scale

If your goal is to protect traffic on public Wi-Fi, you want TUN. TAP exists for cases such as old software that relies on broadcast discovery or setups where two sites must behave like one switch. You will rarely choose it as a home user, and if a guide tells you to switch to TAP to "speed up" a connection, treat that with suspicion.

TCP or UDP: the choice that changes how it feels

This is the decision that people notice. Both modes carry the same encrypted data. What differs is the transport that carries it between you and the server.

UDP sends packets without guaranteeing delivery or order. If a packet is lost, the tunnel itself does not retransmit it. That is fine, because the traffic inside the tunnel, such as a web page loading over TCP, already has its own recovery. One layer takes care of reliability, and the tunnel adds little delay.

TCP guarantees ordered delivery, so the tunnel retransmits lost packets. When your own traffic is also TCP, you end up with two layers each trying to recover the same loss. When the connection is poor, the timers of the two layers fight each other, the inner layer sends data that the outer layer is still retrying, and throughput can collapse. This is often called TCP meltdown, and it is why TCP mode feels sluggish on a weak signal.

Aspect	OpenVPN over UDP	OpenVPN over TCP
Speed on a healthy network	Usually better	Usually a bit lower
Behaviour with packet loss	Degrades gently	Can stall or lurch
Latency for calls and games	Usually better	Usually worse
Works when UDP is not allowed	No	Yes
Typical role	Default	Fallback

A practical rule

Start with UDP. If the connection never completes, or drops again and again on one specific network, try TCP. Stay with TCP only for as long as that network requires it, and return to UDP elsewhere. Some networks, such as certain offices, schools and hotels, only let through a narrow set of traffic by policy. TCP mode can sometimes connect there, but this article does not cover ways around restrictions that a network owner has set deliberately. If a network does not allow VPN traffic, the straightforward options are to ask the operator or to use a different connection such as mobile data.

A short scenario

Ana works from a coworking space with good Wi-Fi. With UDP, her video calls sit smoothly inside the tunnel. One day she travels and stays in a guest house whose network lets UDP through unreliably, so her VPN will not connect. She switches to TCP, it connects, pages load, and a video call is choppy. The choppiness is the double-recovery effect, so she uses TCP only for email and light browsing there and goes back to UDP at the next place. She has used the right tool for each situation rather than treating one setting as universally better.

What "secure" means for an OpenVPN setup

People ask whether OpenVPN is secure as if it were a yes or no property of the protocol. The honest answer is that the protocol design is sound and widely reviewed, and that security in practice depends on how a particular connection is set up. These are the places where things go right or wrong.

1. Cipher choice. Modern authenticated ciphers such as AES-GCM and ChaCha20-Poly1305 are the sensible ones. Old ciphers kept for compatibility, particularly 64-bit block ciphers, are weaker and have been phased out in current versions. If a configuration still names an ancient cipher, that is a red flag about how well it is maintained.
2. Certificate verification. The client must verify the server's certificate and name. Without that check, a person on the network could pretend to be the server. Good configurations make the client check this by default.
3. Key lifetime. Data keys are renewed regularly so a compromise of one key exposes only a slice of traffic.
4. Control channel hardening. A TLS wrapping key reduces exposure to scanning and unauthorised handshake attempts.
5. Software updates. Both the client and the server need to be kept up to date, because security fixes only help once installed.
6. Compression. Compressing data before encrypting has been linked to attacks in other protocols, and current guidance is to leave it off. A configuration that enables it deserves a second look.
7. Credential handling. Username and password are checked over the protected control channel, but the account itself is only as safe as the password and any second factor behind it.

None of this means that a connection using OpenVPN is invulnerable. The tunnel protects traffic between your device and the server. It does not stop malware on your device, phishing sites or a weak password. For the wider picture see what a VPN cannot protect you from.

Reading a client configuration

OpenVPN clients are often driven by a text file ending in .ovpn. You do not need to write one, but being able to read the main lines tells you a lot. This is a deliberately generic example with invented values.

client
dev tun
proto udp
remote vpn.example.net 1194
resolv-retry infinite
nobind
remote-cert-tls server
cipher AES-256-GCM
auth SHA256
verb 3

What the lines mean, in plain terms:

• client says this machine connects out to a server rather than waiting for connections.
• dev tun chooses the routed virtual adapter described above.
• proto udp chooses the transport. Changing it to tcp is the TCP fallback.
• remote gives the server name and port. The port is a label; it does not change how the encryption works.
• resolv-retry infinite means keep retrying to resolve the server name if the network is unavailable.
• nobind lets the client use any local port.
• remote-cert-tls server makes the client insist that the other end presents a certificate meant for a server, a basic guard against impersonation.
• cipher and auth name the data-channel algorithms.
• verb sets how much the log says, which helps when troubleshooting.

Real files also include certificates and keys, either inline or in separate files. Treat a .ovpn file that contains credentials or keys like a password: do not post it in a support forum, and delete copies you no longer need. When a service gives you a ready-made app instead of a file, the app builds these settings for you and you normally should not change them. If the app offers a protocol setting, leave the default unless support advises otherwise.

Performance: MTU, MSS and a single busy core

OpenVPN is often described as slower than newer protocols. There are real reasons, and a couple of them you can influence.

• User-space processing. Each packet crosses between the kernel and the program. On a fast fibre line with a modest CPU, this can become the bottleneck, and OpenVPN may use only one core for a single tunnel.
• Overhead. The tunnel adds headers, which shrink the room for data in each packet. If the final packet is larger than the path can carry, it is fragmented or dropped. The method for discovering the largest packet a path will carry is described in RFC 1191.
• Mismatched MTU. Symptoms are strange: small pages load while large downloads hang, or some sites work and others never finish loading. Reducing the tunnel's packet size, or clamping the TCP segment size, often cures it. Support teams know the setting; as a user, you can mention these symptoms when you ask for help.
• Distance and latency. A server far away adds delay no matter which protocol you choose. The Cloudflare article on latency explains the idea, and why internet speed changes with a VPN covers the other factors.
• Encryption cost. Hardware acceleration for AES makes GCM cheap on many phones and computers. Devices without it can do better with ChaCha20-Poly1305. You normally do not have to pick; defaults are chosen for compatibility.

If speed is your main concern and your app allows another option, trying a different protocol is a fair experiment, and how WireGuard and OpenVPN compare sets out the trade-offs.

Troubleshooting an OpenVPN connection

Work from simple to specific. Change one thing at a time so that you know what helped.

1. Check the network first. Open a web page without the VPN. If it does not load, the VPN is not the problem.
2. Confirm your sign-in details. A typo in the username or password is the most common cause of a failed start. Copy them from your account page rather than retyping.
3. Check the date and time. Certificates are only valid within a date range. A device with a badly wrong clock can reject a perfectly good certificate.
4. Restart the app and the device. It clears stuck virtual adapters, a frequent cause on Windows and macOS.
5. Try another network. If it works on mobile data but not on one Wi-Fi network, that Wi-Fi is probably filtering the traffic.
6. Switch transport only if the app lets you. If UDP fails on one network, try TCP there, and switch back afterwards.
7. Look at the log. A line about TLS handshake failure points to blocked traffic or a bad certificate. A line about authentication failure points to credentials. A line about a certificate being invalid or expired points to the clock or an outdated configuration.
8. Update the app. Old clients can fail against servers that dropped obsolete settings.
9. Contact support with specifics. Say which device, which network, what the log says and what you already tried.

The help article on VPN not connecting goes through app-level fixes in more detail.

Limits and what to watch for

• OpenVPN is a way of building a tunnel. It is not a privacy guarantee. What the provider does with traffic once it leaves the tunnel is a separate question about trust, not about protocol.
• Its flexibility means a poor configuration is possible. Prefer a ready-made app with sensible defaults over hand-edited files unless you know what each line does.
• A port number is not a security feature. Changing the port does not strengthen the encryption.
• TCP mode is a compatibility tool, not an upgrade.
• Speed depends on the server, distance, your device and your network at least as much as on the protocol.
• This article is general education. It is not legal advice and does not claim that any protocol works on every network.

Summary

OpenVPN builds an encrypted tunnel from two cooperating channels: a control channel that uses TLS to authenticate and agree on keys, and a data channel that encrypts each packet. UDP is the better default and TCP is a fallback for networks where UDP does not connect. A secure setup depends on modern ciphers, proper certificate checks, regular key renewal and up-to-date software. When a connection fails, work through the network, credentials, clock, transport and logs in that order.

If you would like a pass that you set up in a minute and that ends by itself, you can look at the pricing page and the download page.