Learn OpenVPN - Routing & IP Forwarding

#Introduction

Episode 5 finished the authentication layer. Now packets can enter the tunnel, and the next question is: where do those packets get sent? The answer lies in routing. OpenVPN is essentially a virtual router: it receives packets from clients, looks up the destination route, then forwards them to the network behind the server.

Episode 6 dissects three things. First, how the server distributes routes to clients via the push directive. Second, the fundamental difference between routed tun mode and bridged tap mode. Third, how the server can become a gateway so clients reach the internet, namely through IP forwarding and NAT.

Why is this episode important? Because almost every real-world VPN problem — a client connects but can't access the internet, or pings to a backend subnet fail — is rooted in wrong routing and NAT. After this episode, you'll know exactly what to check when traffic doesn't flow.

#tun Mode: The Routed Network

#Understanding Subnet Topology

tun mode works at layer 3: packets are routed based on IP addresses, not layer 2 frames. This is the most common mode for remote access because it's efficient and requires no broadcast configuration. Each client gets an address from the virtual subnet managed by the server.

The most basic server configuration for tun mode:

port 1194
proto udp
dev tun
server 10.8.0.0 255.255.255.0
topology subnet
push "route 10.10.0.0 255.255.255.0"

The directive server 10.8.0.0 255.255.255.0 creates the virtual subnet 10.8.0.0/24. The server takes 10.8.0.1 as its gateway, then allocates addresses to clients. The topology subnet line places all clients in the same subnet so they can ping each other.

#Distributing Routes with push

Routes on the client side can be written manually, but the correct way is to push them from the server. The push "route ..." directive makes the client add a route to its local routing table as soon as the tunnel comes up.

push "route 10.10.0.0 255.255.255.0" tells the client: to reach the 10.10.0.0/24 LAN behind the server, use the tunnel. Without this line, the client can only reach addresses inside the 10.8.0.0/24 VPN subnet.

#Topology Differences: subnet, net30, p2p

Before OpenVPN 2.5, tun mode used topology net30 as the default — each client got separated address points, mimicking a classic point-to-point link. This scheme wastes addresses and is annoying in audits. topology subnet is far more practical because all clients share the same subnet.

In topology p2p, the server and client only see a pair of addresses with no subnet concept. This mode is used for simple site-to-site connections and will be discussed again in episode 15.

#Per-Client Routing and iroute

#Assigning Subnets per Client

When a client must represent a local network behind it, push "route ..." alone is not enough. The server also needs to know that the subnet belonging to a particular client can be reached through that client's tunnel. That's the job of iroute.

iroute is declared inside a per-client file mapped via client-config-dir. Example for a client named site-b:

iroute 192.168.10.0 255.255.255.0
ifconfig-push 10.8.0.10 10.8.0.9

The line iroute 192.168.10.0 255.255.255.0 tells the server: the 192.168.10.0/24 subnet can only be reached through client site-b. Meanwhile ifconfig-push gives the client a fixed address inside the VPN subnet. Full details of client-config-dir are in episode 9.

#The Relationship Between iroute and push

A common pattern for site-to-site connections: iroute on the server side tells it how to reach the client's subnet, while push "route ..." on the server side tells the client how to reach the server's subnet. Both directions must be defined for traffic to flow both ways.

#tap Mode: The Bridged Network

#Layer 2 Bridging Concept

tap mode works at layer 2: clients join the same network as the server, as if they were connected to the same switch. Broadcasts and layer 2-dependent protocols, such as ARP and DHCP, work normally inside the tunnel.

This advantage is also a weakness: broadcast traffic enters the tunnel too, lowering performance. tap mode is only recommended when the application genuinely needs layer 2, such as broadcast-based games or production machines relying on non-IP protocols.

#server-bridge Configuration with brctl

Bridging in OpenVPN is done with server-bridge. The server first creates a bridge with brctl:

brctl addbr br0
brctl addif br0 eth0
ip addr add 192.168.1.10/24 dev br0
ip link set br0 up

Then in server.conf:

dev tap
server-bridge 192.168.1.10 255.255.255.0 192.168.1.100 192.168.1.200

server-bridge takes four arguments: bridge IP, netmask, pool start address, and pool end address. Clients in this pool look like ordinary hosts on the 192.168.1.0/24 network.

#When to Choose tun or tap

• tun for remote access, site-to-site, and almost all modern VPN needs.
• tap for connections that require broadcast and layer 2 protocols.
• tun is faster, more secure, and far easier to troubleshoot.

#IP Forwarding and NAT

#Enabling net.ipv4.ip_forward

For the server to forward packets from the tunnel to other networks, the Linux kernel must be allowed to do forwarding. Without this, packets coming in from a client just stop at the server and never reach their destination.

echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -p

sysctl -p applies the configuration without requiring a reboot. This value must be 1 on the server, because the server acts as a router between the tunnel and the outside network.

#iptables Rules for Masquerade

Enabling forwarding alone isn't enough. For clients to reach the internet, the server must also masquerade — disguising client addresses as the server's address when packets leave to the public network:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT

The first rule rewrites the source address of client packets to the server's public address. The next two rules allow packets back and forth between tun0 and eth0. To make the rules survive a reboot, save them with iptables-persistent or roll them out via systemd.

#Split Tunneling

#Choosing Which Routes Enter the Tunnel

Not all client traffic must go through the tunnel. With split tunneling, you choose which routes enter the tunnel and which go straight to the internet. The server defines the boundary via the push directive:

push "route 10.10.0.0 255.255.255.0"
push "route 192.168.50.0 255.255.255.0"

With this configuration, traffic to 10.10.0.0/24 and 192.168.50.0/24 goes through the tunnel, while everything else stays on the local internet. The opposite — all traffic through the tunnel — uses push "redirect-gateway def1", whose details will be compared in episode 16.

#Conclusion

Key takeaways:

• tun mode routes packets at layer 3; topology subnet is the modern standard.
• push "route ..." distributes routes from server to client.
• iroute tells the server how to reach a subnet behind a client.
• tap mode uses server-bridge and brctl for layer 2 bridging.
• IP forwarding is enabled via net.ipv4.ip_forward=1.
• NAT masquerade with iptables lets clients reach the internet.

In the next episode, episode 7, we will discuss control channel and data channel — how TLS handshake and renegotiation work, the tls-version-min, tls-cipher, and remote-cert-tls directives for the control channel, and choosing cipher options like AES-256-GCM and ChaCha20-Poly1305 for the data channel. After this episode, you'll understand why VPN traffic is secure and how its negotiation happens.