Bridged OpenVPN Clients Have No Internet? Check the NAT Rule

The bridged server is up, the masquerade rule is present, and the browser on the client still spins. Everything looks like it should work, which is why the first hour goes into checking the tunnel and the credentials. Then you read the counter on the NAT rule and find a zero that has not moved. A rule that never counted a packet never matched one, and on a bridged server the reason is structural: client traffic exits through the virtual tap device, while the rule names the physical card you copied from an older guide.

The counter is the evidence, not the table entry

Rules that exist and rules that match are different things, and the counter is what separates them. List the NAT table with verbose counters and read the numbers beside each rule before you change anything. A counter parked at zero while traffic flows means the rule was skipped, however sensible its addresses appear. A counter that climbs while the connection still fails sends you elsewhere: forwarding, the return path, or the far end.

iptables -t nat -L POSTROUTING -v -n

Read the counter beside the interface match first. If the source range is right and the output side is wrong, the fix is one word in the rule rather than a new rule entirely.

Find the name the kernel actually records

Identify the tunnel device by name before writing the rule, using the interface list rather than memory. On a bridged OpenVPN setup the device is usually a tap interface created by the server, and its name is part of your local configuration, not a universal constant. Confirm it exists while the tunnel is up, because a device that appears only after a client connects will make an earlier test look like a rule problem.

ip -brief link

Write the name down. Every later command in this diagnosis refers to it, and a typo here produces exactly the same zero counter as the original mistake.

Rewrite the rule against the tunnel device

Point the rule at the tunnel device and keep the client range as its match condition, so it covers tunnel traffic and leaves the host's own connections alone. Substitute your own range and device name, because both below are examples and neither is portable between installations.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tap0 -j MASQUERADE

Then check the two other conditions that the same symptom hides. Check whether forwarding is enabled, and if it is not, enable it in the distribution's own configuration rather than with an echo that disappears on reboot. Read the forward chain counters too, and if it drops the tunnel traffic, permit that interface specifically and leave the chain policy alone.

Reading the forward chain with counters takes one command and rules out half the remaining possibilities before you touch another rule.

Why the physical card never matches

A bridge is a software switch assembled from the tap device and one physical interface. The client frame enters that switch and exits toward the physical network as a member of the bridge rather than as a packet on the card. The kernel therefore attributes the packet to the bridge and its port, which is why the card you were thinking of never shows up in the match. Nothing is broken about the physical interface; it simply is not the device the kernel attributes to that packet.

The follow-up problem people hit next comes from the same structure: frame filtering on a bridge is a separate facility from IP filtering. If the requirement is frame-level restriction, it belongs to bridge filtering, not to an IP table rule.

Prove it end to end, then persist it

Bring up a single client and ping something on the server's LAN; that path exercises forwarding with no translation involved. After that, request something public so the masquerade rule has to be used, and read the counter once more: it should move for this test and not for the previous one. A capture taken on the tunnel device shows both where the frame appears and which address it is carrying.

Last step: put the rules that work into the configuration a restart reads, and note the device name this host's bridge actually uses. Anything typed by hand is gone after a reboot, and the same failure comes back with nothing left to explain it.

If the counter still does not move after the rewrite, compare the source range in the rule against the address the client actually received, because a bridged server can hand out addresses from a range you did not intend.