Rule order
Rules are checked in number order, and the first matching accept or drop wins. A jump to a chain counts as a match only if that chain decides something; return carries on with the next rule.
So placement matters. In the lab, the blocklist check was moved from rule 5 to rule 40, below the rule that lets the internet reach the LAN web server. The scanner, which is still on the blocklist, could immediately load the page: rule 30 accepted it before rule 40 was ever checked. The counters show it, with rule 30 matching and rule 40 never reached.
Two habits avoid this:
- Drops for "never" go first: blocklists, invalid traffic, anti-spoofing. Then the accepts. Then the default action.
- Number rules in steps of 10, so there's room to insert one later without renumbering everything.
The counters also show a quirk worth knowing: they were all back at zero. Every commit rebuilds the whole ruleset, so any firewall commit resets every counter, even for rules you didn't touch. Note the numbers you need before you change anything.
delete firewall ipv4 forward filter rule 5
set firewall ipv4 forward filter rule 40 action 'jump'
set firewall ipv4 forward filter rule 40 jump-target 'BLOCKLIST-CHECK'root@scanner:~# curl -s -m 3 http://198.51.100.10/ || echo "no answer"
hello from lanhost- Lines 1–2: The scanner loads the LAN web page.
vyos@R1:~$ show firewall ipv4 forward filter
Ruleset Information
---------------------------------
ipv4 Firewall "forward filter"
Rule Action Protocol Packets Bytes Conditions
------- -------- ---------- --------- ------- ------------------------------------------------------------------------
10 accept tcp 0 0 tcp dport @P_WEB-PORTS iifname @I_LAN-IFS accept
20 accept icmp 0 0 meta l4proto icmp accept
30 accept tcp 1 60 ip daddr 198.51.100.10 tcp dport @P_WEB-PORTS oifname @I_LAN-IFS accept
40 jump all 0 0 jump NAME_BLOCKLIST-CHECK
default drop all 0 0 comment "FWD-filter default-action "- Line 11: Rule 30 accepted the scanner's connection.
- Line 12: Rule 40 was never reached. Every counter was reset by the commit.
Check your understanding
You add rule 25 with action drop for a misbehaving address. It still reaches the LAN web server. What's the likeliest reason?
- A rule numbered below 25 already accepts that traffic.
- Drops only take effect after a reboot.
- Rule 25 needs
logto work. - The state policy accepts it.