NEW-Only Firewall Rules Do Not Close Every WAN Path

Rejecting new outbound connections on the WAN looks like a fail-closed policy, and it is a narrower promise than the one it appears to make. Packets belonging to flows that already exist do not match it, and neither do many replies. The gap is easy to miss because the rule reads as though it covers the interface rather than one connection state on it. Reading the state match as a verdict is what produces a false sense of closure.

State Is a Match Condition, Not a Verdict

Connection tracking classifies packets by what the firewall has already seen, not by what the application believes. A flow observed in both directions is established, and its later packets stay established even when the route underneath changes from a tunnel to the ordinary uplink. A reply to an inbound connection can also be established traffic. Those packets never become new again.

That is why a rule scoped to new connections cannot establish that every protected packet is blocked. It leaves the other states to whatever else the ruleset does with them, which may be an accept placed earlier in the chain.

Read the Rule in Its Surroundings

A broad accept for established and related traffic placed before the block admits a packet before the block is ever evaluated. Removing the state condition from a later rule will not change that, because evaluation never reaches it. Order decides the outcome, and the state match decides which packets reach the order in question.

Inspect the effective ruleset rather than the file you edited, including jumps into other chains and anything the platform generates. On an iptables-managed router, listing the chain shows the rule definitions, and the chains it references have to be followed as well. A native nftables system needs its own ruleset and hook priorities examined, since firmware rarely generates identical chains.

Counters tell you which rule actually matched, and they are usually more informative than a packet capture taken after the decision. A rule with a zero counter has not been reached, whatever its position suggests.

Express the Prohibition Independently of State

If a group of clients must never reach the internet outside the tunnel, say that directly instead of approximating it with one state. The rule has to select on source, egress and destination without depending on connection state, and it has to sit where no earlier accept can bypass it. Management access and local-network exceptions then get their own explicit rules, so the intent is visible in the policy.

Choosing reject over drop changes how the matched traffic fails, and it does not enlarge the set of packets the rule selects. A connection refused and a silent timeout are different symptoms pointing at the same selection.

A policy that deliberately permits replies to remote-initiated access over the WAN is defensible. It simply has to be described that way rather than presented as total tunnel-only isolation.

Check Who Is Actually Inside the Group

The example covers forwarded IPv4 traffic from one prefix out of one interface. It says nothing about IPv6, a second uplink, or traffic the router itself originates. A router acting as a DNS resolver sends its own upstream queries, and those never pass through the forward chain at all.

Confirm that the protected clients still hold addresses inside the selected prefix, because a device that moved outside it is direct by accident rather than by policy. Widening the block to the whole LAN without reviewing the exception design also tends to remove your own administrative path.

iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED

Then exercise an old flow next to a new one. A fresh connection attempt and an already active bidirectional transfer behave differently under this rule, and only testing both shows which policy you actually have.