OpenVPN

The word VPN now means a subscription service that hides your address. OpenVPN is not that. It is a protocol and the reference implementation of it, which means you get the machinery for building an encrypted tunnel and you supply the other end yourself, either a server you run or one your employer runs for you.

That distinction disappoints people who install it expecting somewhere to click connect. It also explains why it underpins a large share of the commercial services and nearly every corporate remote access arrangement, because everything on top of it is somebody else’s configuration of the same software.

A connection is described by a profile, a plain text file listing the server address, the transport, the port and the credentials. Hand somebody that file and they can connect. That portability is the quiet reason the protocol spread everywhere.

Two crypto modes, and why one of them is the answer

There are two ways to secure an OpenVPN tunnel. A pre-shared static key encrypts a simple point-to-point link between two machines you control, and it is straightforward and limited. The other mode uses certificates and a proper handshake, and the manual describes it as the most powerful option in both security and flexibility, which is unusually direct language for reference documentation.

The mechanism repays understanding. A control channel and a data channel are multiplexed over a single port. The handshake happens on the control channel, and its job is to agree the keys that protect the data channel. Those data keys are temporary and rotate at intervals, so compromising one does not expose the whole session.

Server mode listens on one port and routes every client through a single virtual interface, an arrangement designed to carry hundreds or thousands of connections on adequate hardware rather than a handful.

Managing several profiles across different destinations gets tedious quickly, and a wrapper that keeps them in one list beats launching configuration files by hand each time.

Routed or bridged, a decision made once

The OpenVPN virtual interface comes in two forms, and choosing wrongly causes weeks of confusion.

The routed form operates at the network layer, giving the client an address on its own small subnet with routes pushed to it. This is correct for almost everybody. It scales, it is efficient, and it keeps broadcast traffic where it belongs.

The bridged form operates one layer lower, placing the client on the same segment as the remote network as though it were physically plugged in. That is occasionally necessary for older protocols that depend on broadcast discovery, and it carries all that broadcast traffic across the tunnel, which on a slow link is exactly as unpleasant as it sounds.

Pick routed unless something specific forces the other choice, and be suspicious of anything that claims it needs the alternative.

Getting through networks that do not want you to

OpenVPN runs over either of the two main transport protocols, and the default preference is the connectionless one because carrying a reliable protocol inside another reliable protocol produces the well-known meltdown where both layers retransmit at once.

The exception is deliberate. Running over the connection-oriented protocol on the standard secure web port makes the traffic resemble ordinary encrypted browsing, which is how OpenVPN gets out of hotels, conference networks and countries that filter aggressively. The performance is worse and the connection works, which is the correct trade when the alternative is nothing.

For a server designed around traversing hostile networks with several protocols including this one, SoftEther VPN approaches the same problem from the server side.

Compression is gone, and removing it was right

Anyone migrating an old configuration meets this and deserves an explanation rather than an error message.

Compressing data before encrypting it leaks information about the data, because the compressed size varies with the content. A documented attack exploits exactly that against tunnels using compression, in the same family as the attacks that hit encrypted web traffic years earlier. The response was to deprecate every compression option and advise removing them from all configurations.

The symptom, if you have not, is a connection that fails with the server pushing compression settings the client refuses to accept. The fix is removing those options at both ends rather than forcing the client to tolerate them. An asymmetric arrangement exists as a transitional measure, where the server may compress and the client never does, since only the upstream direction is exposed to the attack.

The kernel offload mode, and its four conditions

Historically the data path crossed constantly between kernel and user space, and that crossing was where a great deal of the performance went. The offload mode moves packet processing into the kernel, so data no longer makes the round trip, and the throughput improvement is substantial.

It comes with four conditions to check before enabling it. It works only over the connectionless transport, so anything using the web-port fallback cannot use it. It requires modern authenticated ciphers, so older block ciphers rule it out. Compression is incompatible and, by explicit design decision, will never be implemented. And certain routing arrangements between multiple sites are not yet supported.

Those constraints are not accidents. Each one drops something the project considers legacy, which is a coherent position and does mean an older configuration may have to choose between compatibility and speed.

When it will not connect

Diagnosing an OpenVPN failure follows a short list. Check whether the handshake completes at all, since a failure there points at certificates, the wrong port or a firewall between you and the server. A handshake that succeeds followed by no traffic points at routing rather than at the tunnel.

Confirming whether packets are leaving the machine settles the question quickly, and Wireshark shows exactly what is being sent and whether anything comes back.

The other frequent cause is the profile itself. Certificates expire, and a configuration that worked for a year stops on the day one does, with an error that describes the symptom rather than the cause.

What it does not give you

Three things sit outside its scope and catch people out.

There is no leak protection. If the tunnel drops, traffic reverts to the ordinary connection without announcement, and OpenVPN neither notices nor cares. Blocking that properly means a firewall rule preventing the applications you care about from reaching the network at all except through the tunnel, and a firewall that filters by program is how most people implement it.

There is no certificate authority for you. Issuing, distributing and revoking certificates is a task you own, and it is the part small deployments underestimate most consistently.

And there is no server. If two machines simply need to see each other and none of the above appeals, a zero-configuration virtual network does that in two minutes with none of the control and none of the work.

Conclusion

OpenVPN remains the sensible choice when you need a tunnel you control rather than a subscription you trust. The certificate mode is well designed, profiles make distribution trivial, the server side scales properly, and the fallback over the standard web port gets a connection out of places where nothing else will.

Understand what it asks of you. There is no server until you build one, certificate management is yours, nothing protects you when the tunnel drops, and modernising an old configuration means removing compression and possibly choosing between the web-port fallback and the faster kernel path. That is a fair amount of work, and in exchange nobody else decides how your tunnel behaves.