OpenVPN Config Generator

A working OpenVPN client file can be 13 lines long. The sample client configuration that ships with OpenVPN 2.6 has exactly that many active lines, and not one of them names a cipher.

That is worth sitting with. The manual, the man page kept in the project’s source tree, explains that any option may be given on the command line or placed in a configuration file, where the leading double dash is dropped, so a configuration is simply a list of options, one per line, with a hash or a semicolon opening a comment. What those thirteen lines settle is who the other end is, how to reach it, what kind of virtual network device to create and whose signature to believe. The encryption people expect a VPN file to be about is mostly agreed when the connection starts. The parts that go wrong are the parts about routes and names.

Two files that mirror each other

A client file opens with the word client. It is a helper, and the manual spells out what it stands for: pull, which tells OpenVPN to accept options pushed by the server, and tls-client, which takes the client role in the handshake. Then comes a remote line with a host and a port. The port is usually 1194, which the IANA registry lists for OpenVPN over both UDP and TCP, registered in November 2004. The manual adds that OpenVPN is designed to operate optimally over UDP and that TCP exists for situations where UDP cannot be used.

The server file has a helper of its own. A single line, server 10.8.0.0 255.255.255.0, expands into server mode, the server role in the handshake, an address for the server, a pool of addresses for clients and a set of options to push to them. A server file is therefore largely a list of instructions that clients will receive. The manual is blunt about what that implies: do not use pull or client where you do not trust the server to have control over the client’s routing table.

The client holds the door open. The server decides what walks through it.

The numbers in that one server line are worth checking by hand, and the tool on this page shows them. RFC 1918 reserves 10.0.0.0 through 10.255.255.255 for private networks, so 10.8.0.0 is safe to use. RFC 4632 defines the /24 notation as a mask whose most significant 24 bits are ones, which is 255.255.255.0 and covers 256 addresses. Choose the server role, enter 10.8.0.0/24 and keep the subnet topology: the server takes 10.8.0.1 and the pool runs from 10.8.0.2 to 10.8.0.254, room for 253 clients.

Now switch the topology to net30, still the default when a file names no topology, which gives every client a /30 of four addresses. The pool becomes 10.8.0.4 to 10.8.0.251 and holds 62 clients. The sample server file calls net30 not recommended, and this is why. One wrinkle: the manual’s worked expansion ends the subnet pool at 10.8.0.253, while the 2.6 source code ends it one address higher. The tool follows the code, because the code is what runs.

Timers hide a similar trick. The sample server file sets keepalive 10 120. The manual says a server doubles its own timeout and pushes the plain values, so the server waits 240 seconds for a silent client while each client waits 120.

The tunnel carries two conversations

OpenVPN in TLS mode runs two channels over one port. In the manual’s words, it establishes control and data channels which are multiplexed over a single TCP or UDP port, and the TLS session on the control channel is used to exchange the keys that protect the data channel. The project’s draft of its wire protocol puts it more plainly still: the TLS handshakes are the control channel, the tunnel data is the data channel, and every packet carries an opcode that says which one it belongs to. The same draft notes that TLS was written for TCP, so OpenVPN encapsulates its TLS packets and adds a reliability layer to carry them over UDP.

Authentication happens on the control channel, with certificates. Each side must present its own. A client should also insist that the certificate it is shown was issued for server use, which is what remote-cert-tls server does. RFC 5280 defines the extended key usage in question as TLS WWW server authentication. The manual explains the danger it removes: an authorized client connecting to another client by impersonating the server.

Two optional directives wrap that handshake in a shared key. With tls-auth, every control packet carries an HMAC signature, and packets without a correct one are dropped without a response; the manual calls it a kind of HMAC firewall and stresses that the key gives a peer nothing more than the power to start a handshake. With tls-crypt the control channel is encrypted as well as authenticated, which hides the certificate and makes the traffic harder to identify as OpenVPN. Every peer holds the same tls-crypt key, so the manual points larger or less trusted deployments to tls-crypt-v2 and its per-client keys.

The data channel is where version 2.6 changed the rules. OpenVPN has negotiated its data cipher since 2.4. In 2.6 the default list is AES-256-GCM, AES-128-GCM and ChaCha20-Poly1305 where the library offers it, the server’s order decides, and a client with no cipher in common is refused with an AUTH_FAILED message. A question mark before a name marks a cipher as optional. The old cipher directive is ignored in TLS mode from 2.6.0. All three defaults are what RFC 5116 calls authenticated encryption with associated data, one algorithm providing both confidentiality and authenticity, which is why the manual says the auth digest is ignored on the data channel with such ciphers.

The control channel got stricter too. Since 2.6.0 the lowest version accepted by default is TLS 1.2. TLS 1.3, published as RFC 8446 in August 2018, went further and kept only authenticated encryption algorithms. Compression went the other way. The manual marks compress as deprecated and points to VORACLE, an attack on VPNs that compress. Wikipedia’s article on the LZO compressor records the project’s own security advisory on that attack, dated 29 September 2018. The change log for version 2.5 calls compress risky, and 2.6 refuses compression unless a file asks for it.

Where the packets go, and where the names go

Encryption protects only what enters the tunnel, and the routing table decides that. A tun device carries IP packets, a tap device carries Ethernet frames, and both ends must use the same kind. The directive redirect-gateway takes three steps, as the manual lists them: add a route to the server through the existing gateway, delete the default route, and install a new default through the VPN. The def1 flag is gentler. It leaves the default route alone and adds 0.0.0.0/1 and 128.0.0.0/1, two halves that between them override it. A server pushes this to clients, and the sample file warns that the server may then need to perform address translation for it to work.

Leave it out and you have a split tunnel. NIST’s telework guide defines split tunneling as tunneling the communications that involve the organization’s internal resources and excluding all others. It grants that this increases efficiency and reduces load. It also warns that the remaining traffic is unprotected, and suggests that organizations consider disabling it for people on untrusted networks.

Names are the quiet leak. RFC 9076 notes that almost every activity on the Internet starts with a DNS query and that the recursive resolver sees all of that traffic. If the question travels outside the tunnel, whoever runs the resolver learns the name even though the visit itself is encrypted. OpenVPN can hand out resolver addresses with dhcp-option DNS, but the manual is candid about what happens next. On Windows the adapter driver or OpenVPN applies them. On most other platforms they are only placed in the environment for a script or plugin to act on. Windows alone has block-outside-dns, which the manual says exists to prevent DNS leaks.

IPv6 is the other gap. The def1 routes are IPv4 routes, and redirecting IPv6 needs its own flag. The manual describes the result of forgetting as connections leaking around an IPv4-only VPN. It is not a rare mistake. A 2025 paper on IPv6 in VPNs counts up the earlier laboratory studies: all 14 commercial services examined in 2015 leaked IPv6 traffic, and so did 56 of 67 a year later, against 5 of 80 in 2022.

Certificates travel, keys stay

A file names three pieces of identity: the authority’s certificate, your certificate, and your private key. Only one is a secret. Easy-RSA’s introduction to PKI says that requests and certificates are not security-sensitive and can be sent by any convenient means, while a private key should never leave the system it was made on, because whoever holds it can make connections appearing as the certificate holder. The sample files say the same in fewer words: one authority file for everyone, a separate certificate and key for each client, and beside the server key the comment that this file should be kept secret.

Inline blocks change the stakes. OpenVPN accepts the contents of those files between tags such as ca, cert, key and tls-crypt inside the configuration itself, which is how a whole profile becomes a single file. That file is now the key. The tool here keeps pasted material in the page’s memory, never writes it to storage, and hides key lines on screen until asked.

What a generator cannot do

It writes a file. It does not create an authority, sign a certificate or generate a key; it cannot start a server, open a firewall port or turn on forwarding. It cannot see what a server will push, so the DNS path it draws for a split-tunnel client is an estimate and is labeled as one. The OpenVPN Connect apps are built on OpenVPN 3, a client-only library, and announce a cipher list of their own. And it cannot test the result against your network.

Read every line as an answer to one of three questions. Who do I trust? What goes in the tunnel? Where do my names go? If a configuration answers those on purpose, the ciphers will usually take care of themselves.