Learn OpenVPN - Core Concepts & Main Architecture

#Introduction

After understanding the history, it's time to dissect the anatomy of an OpenVPN connection. When you connect a client to a server, a lot happens within seconds: parameter negotiation, certificate exchange, establishment of encryption keys, creation of the virtual interface, and routing setup.

Episode 2 is the bridge between theory and practice. We will cover protocols and encapsulation, the fundamental difference between tun and tap modes, and the architectural components you will configure in episode 3. After this episode, terms like control channel, data channel, and cipher suite will no longer be a black box.

#Protocols and Encapsulation

OpenVPN is essentially an encapsulation engine: ordinary IP packets are wrapped, encrypted, and then sent over another network. Let's break it down layer by layer.

#SSL/TLS for Key Exchange

The first step of every connection is the TLS handshake. Server and client exchange certificates, verify trust through the CA, and negotiate session keys that will be used to encrypt data.

The key thing to understand: TLS only handles the negotiation and key management phase. Once the session keys are established, day-to-day data traffic no longer goes through the TLS machinery, but through the lighter-weight data channel.

#The Encrypted Data Channel

After the handshake completes, OpenVPN creates a data channel: a fast symmetric encryption session for each packet. Every data packet is encrypted and given an authentication code, so its contents can neither be read nor modified by third parties.

Data channel parameters such as cipher AES-256-GCM and auth SHA256 are controlled via directives that we will cover thoroughly in episode 7.

#UDP 1194 or TCP 443

The OpenVPN tunnel can run over two transports:

• UDP port 1194 (default): faster, no TCP-in-TCP overhead, the most recommended.
• TCP port 443: resembles HTTPS, useful for passing through firewalls that block UDP.

This transport choice is written in the proto directive on the server and must match the client. Servers running both protocols at once are discussed in episode 17.

#tun vs tap Modes

One of the first decisions in designing a VPN is choosing the virtual device to use.

#tun: Routed Layer 3

tun mode works at layer 3: OpenVPN creates a virtual interface like tun0 that accepts IP packets, then routes them to other clients. This is the routed mode most commonly used.

3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500
    inet 10.8.0.1  netmask 255.255.255.0  scope global tun0

Notice the output above: tun0 has an IP address in the virtual subnet 10.8.0.0/24. Because it works at layer 3, tun does not carry broadcast traffic — but that is actually efficient and suitable for almost all needs.

#tap: Bridged Layer 2

tap mode works at layer 2: a virtual interface like tap0 carries complete Ethernet frames, including ARP and broadcast. This allows the VPN to behave like a network switch.

tap mode is useful for running protocols that require broadcast, such as legacy network protocols or certain LAN games. The consequences: more overhead and more complex tuning, so it is not recommended for general use.

#When to Choose tun or tap

Use dev tun for almost every scenario: remote access, site-to-site, and traffic protection. Use dev tap only if you genuinely need layer 2 bridging, for example so that all clients share a subnet with the server LAN.

In episodes 6 and 15 we will see this difference in practice, including the routing and bridging implications.

#Main OpenVPN Components

Architecturally, an OpenVPN deployment consists of several components working together.

#Server Daemon and Client Daemon

The server daemon is the openvpn process that waits for connections on a specific port and manages all clients. The client daemon is the process that initiates outbound connections to the server. They are the same program — the only difference is the configuration file.

On Linux, the daemon is usually run as a systemd service with a name like openvpn-server@server, following the convention we will discuss in episode 3.

#Key Material and Certificates

Each node needs a set of key material: the CA certificate, its own certificate, its own private key, and Diffie-Hellman parameters on the server side. This combination enables mutual TLS authentication.

/etc/openvpn/
├── ca.crt
├── server.crt
├── server.key
├── dh.pem
├── ta.key
└── server.conf

The structure above is the classic server layout. Securely managing these files — including protecting the key with chmod 600 — will be covered in episodes 4 and 13.

#Configuration Files

A configuration file is plain text containing directives, one per line, with comments starting with a hash mark. The server and client directives at the beginning determine the role, followed by port, device, certificate, and policy parameters.

A minimal example of a server configuration file:

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem

This file will grow into a full configuration in episode 3. Notice that the port and proto directives above define the first entry point of a connection.

#Plugins and Scripts

OpenVPN supports extensibility through scripts and plugins: --up, --down, --client-connect, --client-disconnect, as well as plugins for external authentication such as LDAP and RADIUS. These features are what allow OpenVPN to integrate into complex corporate systems.

In episodes 9, 10, and 12 we will write scripts and configurations that make use of these hook points.

#The Architecture in a Single Flow

To clarify, here is the flow of a connection from client to active tunnel:

client --(TCP/UDP)--> server : port 1194
  TLS handshake + mutual auth (control channel)
  cipher negotiation + session keys
  tun0 creation on both sides
  packet encapsulation & encryption (data channel)
  tunnel active, traffic flows

The flow above will serve as our guide when troubleshooting in episode 8. Each stage has its own characteristic error, and understanding its position in this flow will speed up diagnosis.

#Conclusion

Key takeaways:

• OpenVPN encapsulates IP packets then encrypts them over UDP or TCP.
• TLS is used for key exchange; the data channel uses fast symmetric encryption.
• UDP 1194 is the recommended default; TCP 443 for strict firewalls.
• tun mode (routed, layer 3) for almost every scenario; tap (bridged, layer 2) for special cases.
• Main components: daemon, key material, configuration files, and scripts/plugins.
• Server and client use the same program, differentiated only by configuration file.

In the next episode, episode 3, we will install OpenVPN and create the first configuration — from installation on various platforms, writing server.conf and client.ovpn that can communicate, to verifying the first tunnel coming alive. Get your lab ready because this episode involves a lot of hands-on practice.