Scope the OpenVPN SNAT Rule Before It Breaks nginx

Two failures keep arriving from the same kind of host. In the first, clients authenticate and then reach nothing beyond the tunnel. In the second, the VPN comes up and the server's own website stops answering, which is the more alarming one because it looks like collateral damage. On a container-based VPS both usually trace back to the same short list of checks, and the order matters: device first, translation second, scope third.

Confirm the container can create a tun device

Nothing else matters if the tunnel interface cannot exist. Check that /dev/net/tun is present and that creating a test device succeeds, because many providers disable tun inside containers by default. No amount of firewall work compensates for a device that was never created.

If the device is missing, only the host or the provider can enable it. A different plan is often cheaper than an open support thread that lasts a week. Confirm this before you read a single OpenVPN log line. Otherwise you spend the evening tuning rules that will never see a packet.

Decide what MASQUERADE does on this interface

On an ordinary virtual machine the usual egress rule is a POSTROUTING MASQUERADE out of the main interface. In an OpenVZ container the visible device is often venet0, a host-managed virtual interface rather than a routed NIC, and MASQUERADE does not always behave there the way tutorials assume.

The workable form is explicit translation to the address clients already reach, with forwarding permitted in both directions. Substituting the pool from the server configuration matters as much as substituting the address. Read each line before pasting it.

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Without the forwarding rules the translation still happens and the kernel still refuses to forward. That combination produces the confusing state where counters on the NAT rule climb while the client receives nothing. The two FORWARD lines also need to sit before any broad drop rule in the same chain. Order is part of the configuration, not an implementation detail.

Scope the rule to one pool and one interface

The second symptom has a different cause: a POSTROUTING rule with neither a source nor an output restriction. Such a rule rewrites every packet leaving the host.

Services that depend on the original source then misbehave. A web server behind a local proxy can stop answering, and restarting it changes nothing because the rule is still in the path. Traffic the host sends to its own public address is affected too, which is why the failure can look like a DNS or certificate problem rather than a firewall one. The rule was almost certainly added to fix the first symptom.

The fix is to narrow the match to the tunnel pool and the egress interface, then add one rule per pool instead of widening a single rule to cover several.

Persist the rules and find out who else owns them

Hand-added rules disappear at reboot, so save them with iptables-save or manage them through netfilter-persistent where it is installed. Confirm the restore runs before OpenVPN starts. Then reboot once on purpose rather than discovering the gap during an incident.

On a container host, also confirm the persistence file lives in writable container storage and that the provider does not replace filtering at boot. Some platforms manage policy outside the container, where local rules are either ignored or fight the host's own.

Verify with counters and one captured flow

From a connected client, check the public address an external service reports. If it matches the server's address, translation works; if it does not, the packet is leaving by another path or not leaving at all. Then exercise both a service hosted on the server and one on the public internet, since those take different paths through the same rule set.

On the server, read the packet counters on the NAT and FORWARD rules with iptables -t nat -L -v -n and watch one flow in a capture. If the client's address appears in the capture and no reply follows, the gap is on the return path or in provider filtering rather than in the client profile. Compare the captured source against the address the rule translates to, since a mismatch means another rule matched first. One observed flow settles more than a page of configuration reading.

Keep the pool, the translated address and the interface name together in the change record. A rule that is correct for one pool mistranslates the next one.