Whole-LAN OpenVPN client on OpenWrt: a working order

Four independent jobs put a router's entire LAN behind one tunnel. The tunnel device needs an owner, a firewall zone, a translation target toward the uplink, and, if some clients must stay off the VPN, routing by source address. A tunnel that connects while nothing passes usually has one of those four missing. Working in dependency order means a failure at the end belongs to the step you just changed. Each step below ends with something you can observe, which keeps the next one from being a guess.

Decide what shares the tunnel

The router that hands out Wi-Fi and DHCP can run the client itself. That puts every attached device behind the tunnel with no per-device setup, and it is the arrangement most small sites want. It is also the one with the widest blast radius when the tunnel drops, because every device loses its path at once. Nothing on the LAN keeps a working route out.

A second router behind the first, running the client with its own subnet, scopes the tunnel to its own devices. It is easier to remove and easier to explain to whoever inherits it. The cost is reachability between the two sides without a route or a port forward.

Either way, make the LAN subnets distinct. Identical ranges make one side look directly connected, and the resulting black hole reads like a VPN fault for hours.

Give the tunnel an owner

Declare the tunnel as a network interface with a name, a device, and no protocol of its own. The network system then creates and manages the device, and everything downstream refers to the interface by name rather than by device. That is what lets the zone find it.

Do not create the same device in two places. A hand-made tunnel next to a declared interface produces a device that exists but is not zoned, or one that vanishes on reload. Both look like the client failed, and neither produces an error that names the real cause. Pick the declarative path and delete the manual one.

Keep the name identical in the network, firewall, and VPN configuration. The zone lists networks by name, so a typo leaves the tunnel outside every zone while the interface itself looks healthy. A healthy interface with no policy is the hardest state to spot.

Zone it, then forward into it

A firewall zone is where policy lives: input, output, forward, and masquerade. A tunnel in no zone is governed by defaults you did not choose, which is rarely what a router client needs. The stanzas below declare the interface, place it in a zone, and permit LAN traffic into that zone.

config interface 'vpn'
    option device 'tun0'
    option proto 'none'

config zone
    option name 'vpn'
    list network 'vpn'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'

config forwarding
    option src 'lan'
    option dest 'vpn'

On releases older than 21.02 the same interface line is spelled option ifname, so check which form the installed firmware parses before pasting. The forwarding stanza is the permission that lets LAN traffic use the tunnel at all. Without it the device is up, the client is connected, and no LAN host reaches the tunnel. That is the most common connected-but-no-internet report on router clients.

Masquerade on the VPN zone collapses every LAN address into the router's tunnel address before the packet leaves. That removes the need for a return route to your subnet on the far side.

If the far side already routes your LAN, turning masquerade off keeps source addresses visible and makes per-client logs meaningful. Pick one and write down which, because the two choices produce different support questions later. Removing the default LAN-to-WAN forwarding is a separate decision with its own consequence. Take it away and the router's own internet access goes with it.

Name the real uplink in NAT

On firmware where the translation rule is hand-written, the outgoing interface is the field that goes wrong. A rule naming vlan2 does nothing when the session terminates on ppp0. A rule with no interface at all can translate traffic that should have stayed private. Neither mistake announces itself, because the tunnel keeps working.

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Replace ppp0 in that rule with the interface from ip route or the running interface list, then watch the counter while a LAN host loads a page. On a single-provider router, one masquerade rule for the uplink is normally enough. A second rule for the tunnel interface is not a substitute for the first.

Then add the client options that decide what enters the tunnel. A redirect-gateway directive sends client internet traffic through the VPN, and without it the tunnel carries only the routes the server pushes. Check the resulting route table before you touch DNS.

Split the Wi-Fi with a second table

One routing table cannot hold two defaults. A second SSID that must bypass the tunnel therefore needs its own subnet and its own table. Assign the tunnelled SSID its own range, then route only that range into the tunnel with a rule that selects the table.

Policy-routing packages on OpenWrt express exactly that combination. Doing it by hand works too, with a source rule and a table whose default points at the tunnel device.

Check the split from both networks. A client on the tunnelled SSID should present the VPN's exit address, and a client on the ordinary SSID should present the provider's. When both look the same, the rule matches the wrong source or the table is never consulted. Test after a reconnect as well, because a rule that depends on the interface name breaks when the device is renumbered.

Suspect the clock and the device flag

The persist-tun flag leaves the tunnel device in place across restarts. That suits a server and confuses a client whose state should be rebuilt from scratch. Remove it while troubleshooting a router client, because a device that survives a failed negotiation hides which step actually broke. Put it back once the client connects reliably, and not before.

The clock is the other quiet failure. A router with no battery-backed clock starts at the epoch, which means certificate checks fail until NTP catches up. Compare the log timestamps against real time before you touch a certificate, because a client that connects a minute after boot is usually waiting on time synchronisation.