OpenVPN iroute vs Kernel Route: Which One Is Missing?

A packet for 10.77.20.0/24 takes two separate decisions on an OpenVPN server: the operating system must hand it to the VPN interface, and OpenVPN must know which connected client owns that prefix. A missing kernel route drops it before the tunnel, a missing peer route drops it afterwards. The two failures look identical from the far LAN, and diagnosing which one you have takes one command on each side.

In the classic userspace data path, the kernel route gets the packet into the tunnel process and iroute tells that process which peer should receive it. Neither one substitutes for the other, and a configuration carrying only one of them will look reasonable right up to the first ping.

Two Decisions, Not One Route

Picture a site-to-site link where 10.77.20.0/24 sits behind a single client. The server's kernel route, for example ip route add 10.77.20.0/24 dev tun0, sends matching packets to the tunnel device. OpenVPN then consults its own internal table, built from iroute entries in the client configuration directory, to decide which peer connection receives them. Without the kernel route the packet never reaches the process, and without the peer route it reaches the process and goes nowhere.

That split is easy to forget, because a single route line in a client profile can look like it does both jobs. It does not: pushing a route tells clients what to send through the tunnel, while iroute tells the server who owns an address range behind a client. They live in different files, are read by different sides, and fail in opposite directions.

Where iroute Belongs and What It Says

The entry goes in a per-client file named after the client's common_name, under client-config-dir, as iroute 10.77.20.0/24. The filename match is not cosmetic: OpenVPN looks up the authenticated identity and reads the file with exactly that name, so a file called site-a only takes effect for a client whose common name is site-a. Add ccd-exclusive if clients without such a file should be refused outright, which is the right setting when every client is a site gateway. Keep one file per gateway and name it after the certificate subject you actually issue.

Test the entry from the server before blaming the far LAN. The status file lists connected clients with their common names, and a server running at --verb 4 logs the iroute being installed as the peer connects. If nothing appears at connect time, the file is in the wrong directory or names the wrong identity.

The Trap: File Present, Wrong Identity

A correct-looking iroute attached to the wrong peer wastes more time than a missing file, because everything on disk looks right. Certificate renaming, duplicate common names, and username-as-common-name changing the effective identity all produce it. Check which identity the server authenticated instead of which one you expected: the status output is authoritative, while the filename is only a lookup key.

A route can also outlive its owner. Static routes and iroute entries describe a prefix rather than an availability guarantee, so traffic can keep being routed toward a peer that is currently disconnected.

Finish the Path Beyond the Peer

Peer ownership is the middle of the path, not the end. The client must forward packets from the tunnel into its LAN, which means IP forwarding enabled on that host and a firewall rule permitting the transit. Hosts on the far LAN need a return path for the tunnel address, either a route pointing back at the gateway or a deliberate NAT design on the client side. Confirm the forward setting on the client with sysctl net.ipv4.ip_forward instead of assuming a distribution default.

If other VPN clients must reach that subnet, the arrangement grows again: the server needs client-to-client, and those clients need to route the prefix through the tunnel. None of that is implied by the server's own route table.

Verify one destination from a real source instead of from the server itself. A ping from an unrelated LAN host to a host behind the client exercises the return path, the forwarding rule and the peer ownership in a single move, whereas a successful handshake proves only identity. Then disconnect the owning peer and record what the route does, because that answer is your failure mode.