nftables: insert the VPN allow rule before the drop handle

Place an allow rule in the wrong position and it behaves like no allow rule at all. In nftables the choice between insert and add decides which side of a referenced rule the new statement lands on, and a handle names the rule in the live ruleset rather than its row number. Get the placement wrong and the packet reaches the drop first.

The comparison below uses one fixed peer and one outer listener exchange. It is deliberately narrow; replacing a whole chain is a different change with a different risk profile.

Two placements, two different outcomes

insert places a rule before the referenced rule. add places it after. If the referenced rule is the terminal drop for the flow, those two commands produce opposite results even though the rule text is identical.

Omitting a location has its own default behavior, which is another reason not to copy a command from a forum without reading what it is anchored to. The anchor is the whole decision. Write the intended side down before you type the command. Insert and add are one word apart in the file.

The placement is relative to a rule in a specific chain. Moving the same statement to another chain or another hook priority changes which packets it sees, even when the rule syntax looks correct.

A handle identifies a rule, not a line number

A handle such as 42 is an identifier in the current ruleset state. It is not the forty-second rule, and it is not stable across hosts, rebuilds or a manager that reloads its configuration.

Locate the chain and the actual terminal drop before choosing the anchor. Then confirm the handle on that rule in the same listing that shows the drop, so the number and the rule are read together. A handle read from an old listing may already belong to another rule. Re-read it in the session that will apply the change.

iptables --version
nft -a list ruleset

The iptables version reports which backend is in use. An iptables-nft ruleset and an independently managed native table can coexist, so a list from one frontend is not automatically the complete filtering picture. Check both views before choosing a chain.

Find the chain and the rule that actually drops

Read the input hook, the chain priority and the rule that rejects this listener flow. An inet table may carry both address families, but an individual rule can still match only IPv4.

Take one approved peer, using 198.51.100.25 from the documentation range as an example. A reviewed native file could place an outer allow before handle 42:

insert rule inet filter input handle 42 iifname "eth0" ip saddr 198.51.100.25 udp dport { 500, 4500 } counter accept

Replace the family, table, chain, handle, ingress interface and peer after inspection. The example uses the handle-location form documented for nft 1.0.9, and it belongs in an input file; brace quoting is a separate concern when the command is typed interactively.

Keep the configuration owner clear. A manager that rebuilds its rules can overwrite a runtime edit, and a boot script that hardcodes a stale handle will either fail or attach to the wrong rule.

Accept is scoped, a drop is terminal

An accept verdict ends evaluation in its current path, but a later applicable base chain can still drop the packet. A drop verdict is terminal. That is why a rising accept counter is not proof that the flow succeeded.

Inspect all relevant hook priorities rather than one chain in isolation. A packet can pass an input filter and still be rejected by another table's hook at a different priority. List every base chain that can see the flow.

That rule covers just the outer listener exchange. Transport-encapsulated ESP, native ESP, IPv6 peers and the decrypted traffic inside the tunnel all need policies of their own. It is not a complete site VPN firewall.

Check the file, then verify the live result

Run a syntax and transaction check on the reviewed file before applying it. Check mode reports whether nft can parse and stage the change; it does not apply it and does not prove that another hook will permit the packet. The file stays a proposal until the owner applies it:

nft -c -f reviewed-vpn-rule.nft

Apply through the owner's controlled process and preserve recovery access. If the rule is wrong, the drop you were trying to precede can also cut the path you use to fix it.

After the change, observe a fresh permitted peer attempt and check that sources outside the approved peer are still refused. Move the durable rule into whichever manager owns the ruleset, because runtime handles locate current objects rather than identify them across boots.