Firewall Rule Change Not Working: Rule Order and Connection State

You edited the rule, reloaded the ruleset, and the tunnel behaves exactly as it did before. That outcome has two common causes, and they need different tests. Either the new rule sits after an earlier rule that already accepted the packet, or the exchange you are watching is a tracked connection that the change never re-evaluates. A rule in a file states intent; what decides the packet is the active path it meets. Work through the checks below in order, and keep a way back in while you do it.

Rule order and connection state are different faults

Ordered chains are evaluated top to bottom, and the first rule that reaches a terminating verdict ends the walk through that chain. Insert a broad accept above a carefully written lockdown rule and the lockdown rule becomes documentation: it is in the ruleset, it has a counter of zero, and no packet will ever reach it. The same text applied to a different chain proves nothing either. In nftables, base chains attach to hooks at priorities, so an accept in one chain does not stop another chain on a different hook or priority from seeing the same packet.

Connection tracking produces the second symptom, and it looks identical from the outside. Once a flow is in the state table, an established-or-related accept near the top of the chain returns before your new rule is consulted. NAT mappings have the same property: the translation was fixed when the flow began, so an edited postrouting rule does not rewrite a session that is already running. This is why a change appears to work at 09:00 for a new connection and appears to do nothing for the session someone opened at 08:55.

Cloud security groups add a third model that catches people who learned on iptables. Their inbound rules are an allow list evaluated as a set rather than a first-match walk, they are stateful, and removing an allow rule does not terminate flows that are already tracked. Assuming first-match semantics on a platform that does not have them leads to confident, wrong conclusions.

Read the active ruleset, not the file you edited

Start with what the kernel is enforcing right now. A saved configuration that was never applied explains a surprising number of unchanged behaviours, and it costs one command to rule out:

nft list ruleset
iptables-save

Then ask whether your rule is being reached at all. Packet counters answer that directly, and they answer it better than any reasoning about intent:

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

A lockdown rule with zero packets after a real test attempt is not a policy problem, it is a position problem. Moving it is a one-line change, and the syntax is exactly what caused the original bug. With iptables, -I inserts and -A appends; with nftables, insert places a rule at the start of the chain while add appends. When a rule must win, say so explicitly instead of trusting the order that happened to be loaded.

Prove whether the flow is tracked

Before blaming the rule, check whether the traffic is a tracked connection at all. Ask the state table for the specific flow rather than dumping all of it:

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

The listing shows the state and the remaining timeout, which is how you tell an established session apart from a fresh attempt; the event mode prints updates as they happen, which is useful while you reconnect a client. If the flow is present with an established state before you touched anything, no edit to the filter rules will change its fate. That is not a bug in the firewall, it is the contract of stateful filtering.

Resist the shortcut of flushing the whole table on a production gateway. conntrack -F is available, and it also destroys every tracked flow on the box, including the management session you are working from and the tunnel that carries your shell. Individual entries can be deleted when you truly need to, but a fresh flow from a new source port is usually a cleaner experiment.

Some paths are not tracked, and they behave the opposite way. Traffic marked notrack in the raw table, some tunnels that bypass the normal hooks, and asymmetric routing that splits a flow across two gateways all produce packets evaluated one at a time, or state that never gets created on both ends. If the counters move for every packet, suspect that kind of path before you suspect ordering.

Test from a fresh flow with a way back in

Before you test a rule that could cut remote access, establish a recovery path: the provider console, a serial console, an out-of-band management address, or a second interface that the rule cannot match. A rollback timer is a reasonable companion, since it will restore the previous ruleset even if your session dies mid-test.

Then test with an exchange that could not already be covered by state. Disconnect and reconnect the client so a new five-tuple is created, and watch both ends while it happens:

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

Run the test in both directions. A rule that blocks the new inbound handshake can still allow the reply path, or the reverse, and a one-way result is the usual reason a lockdown half works. Reconnect once more after the test to confirm the steady state, and check that legitimate management access survived; a rule written to match one port has a habit of matching a broader range than intended.

Record purpose and position with the rule

A rule without a recorded purpose is a rule nobody dares remove. Alongside every lockdown entry, keep the flow it protects, the chain and hook it lives in, the position it must hold relative to broader accepts, and the test that proved it. When someone edits the surrounding ruleset six months later, that note is the only warning that the position was deliberate.

Before you close the change, confirm four things: the running ruleset matches the file, the new rule has non-zero counters after a fresh attempt, the reverse direction and management access still work, and you have reconnected once to prove the steady state rather than the state of a session that predates the edit. If any of those is unverified, the change is not finished, whatever the tunnel is doing.