A Linux Distribution Firewall Can Block Your VPN Traffic

The tunnel comes up, the log says connected, and one application still cannot reach anything. On a Linux client that usually means a distribution firewall is filtering a path the VPN client never managed. Two managers can be active at once, each with its own ideas about the interface, the zone and the direction of traffic. Identifying the owner before editing anything is faster than trying rules until something works.

Find the Manager and the Backend

Start with what is actually loaded rather than with what is installed. A distribution may ship firewalld, ufw and a plain nftables service, and only one of them owns the running ruleset. The packages coexist happily, and a rule entered through the wrong front end never reaches the kernel. Read the active service, then read the ruleset it produced.

The backend matters as much as the front end. A firewalld installation can drive nftables or the legacy iptables backend depending on version and configuration, and the two produce different inspection output. Write the distribution, the version and the backend into the ticket before comparing your system with any guide.

Match the Direction and the Interface

An outgoing client request, an incoming listener and a forwarded packet traverse different hooks, and a rule for one does not cover the others. A zone that permits the local LAN often does not include the tunnel interface or the VPN address pool. A tunnel interface usually lands in the default zone, which is frequently stricter than the zone the physical adapter sits in. That mismatch explains why browsing works on the LAN and stops the moment the tunnel comes up.

Ask which direction failed before choosing a rule. An application that cannot connect outward needs the output path, while an inbound service needs the input path on the tunnel interface. Adding a rule to the wrong chain produces a change that looks applied and does nothing at all.

Keep the Rule Owners in Agreement

A VPN client's hook, a container runtime and the distribution service can all modify networking, and they do not coordinate with each other. Hand-entered rules disappear at the next reload, and rules spliced into a manager's chain can be evaluated in an order you did not intend. Use the manager's persistent configuration and inspect the resulting ruleset rather than the file you wrote. Disabling the whole firewall because one service is unreachable trades a small problem for a large one.

Narrow counters are the cheap way to find the rejected flow. A logging rule limited to one destination and one port shows whether the drop happens locally without capturing anybody else's traffic. Remove the logging rule when the investigation ends, since it is a diagnostic rather than a policy, and firewalld's zone documentation explains how interfaces and services combine.

Check the Fix Without Losing Lockdown

Inspect the applied state with the manager that owns it, using commands that match the backend you recorded. The listing below assumes firewalld is in charge; substitute the equivalent for nftables or ufw instead of running all of them. Mixing tools in one session is how a machine ends up with two conflicting rule sets.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=trusted --list-all
sudo nft list ruleset | head -40

The first command names the zones and the interfaces assigned to them, which shows where the tunnel actually landed. The second prints the rules and services of a zone, so you can see whether the VPN interface is covered at all. The nftables listing is the ground truth for the backend in use, and a rule that exists only in a configuration file does not appear there. Compare the three outputs with the rule you added, and the mismatch usually names itself.

Then repeat the original request and the failure behaviour you require. A newly working site is not enough if the same change removed the client's lockdown, so test an unprotected path as well. Record the manager, backend, interface and purpose of the rule, because a package update that revives a second manager will otherwise rebuild the entire mess.