How reliable is Firewall:Diagnostics:States for troubleshooting

[DaElephant]

I ask this question because I am seeing odd behaviour there.

I have 2 IP addresses in the same subnet, .5 and .50
The .5 address is matching on the firewall rule that has .50 in it, not .5.  The .5 IP should match a rule further down the rules list for that subnet.

I cleared the state table but the exact same issue came back.


Side note
Another odd thing in Firewall:Diagnostics:Aliases it is listing Aliases that no longer exist.  They did exist at one point but have been deleted or renamed, but still show.

[Patrick M. Hausen]

Show the rules, please. Educated guess: you have the netmasks/prefix-lengths wrong so the rule matches more than intended. To match a single IP address use /32.

[pfry]

[...]The .5 address is matching on the firewall rule that has .50 in it, not .5.  The .5 IP should match a rule further down the rules list for that subnet.

I cleared the state table but the exact same issue came back.

It's possible you've encountered a bug (either in rule evaluation or state display), but chances are you've got a rule logic error. We'd need to see the relevant information (rules, aliases, state display, etc.) to be sure. Putting the data together might reveal the issue (or not).

[...]Another odd thing in Firewall:Dianostics:Aliases it is listing Aliases that no longer exist.  They did exist at one point but have been deleted or renamed, but still show.

I'd assume that's because pfctl will show the (now-) empty tables, but I'd have to test it to be sure.

[DaElephant]

Is this what you are looking for?

These are the 3 rules on the interface
You cannot view this attachment.

These are the aliases
You cannot view this attachment.
You cannot view this attachment.

This what shows in states table
You cannot view this attachment.

[DaElephant]

It does follow the correct rules some times.
You cannot view this attachment.

[pfry]

Huh. What does the inbound state look like? I'd expect a pair like this...You cannot view this attachment.

Edit: Also, check "Firewall: Diagnostics: Statistics" -> "rules".

[DaElephant]

Huh. What does the inbound state look like? I'd expect a pair like this...You cannot view this attachment.

I have not seen this again, after reporting it yesterday.  The other part of the pair was the IPs reversed, with the rule being let out anything from the firewall.  If this happens again I'll be sure to grab a screenshot of the whole pair.

[pfry]

I have a dim recollection of scrambled displays after applying rule changes (for sessions created prior to the change). Might be worth a search. I think that if you look up one of your odd sessions in the log, it'll read correctly.

[hharry]

OPNsense for several major versions, has suffered from showing incorrect rules in firewall sessions and states.

https://forum.opnsense.org/index.php?topic=46029.msg236282#msg236282

To this day, i still see the same set of issues in 26.x

For me i always see these issues when either

1. F/W rules are changed, then sessions and states are listed with incorrect F/W rules
2. immediately after OPNsense reboot ( no F/W rule change is involved ), then sessions and states are listed with incorrect F/W rules


In both cases, i need to reset F/W states to clear out the issue...after resetting F/W states, then all F/W sessions and states then list correct / expected rules, until either of above cases are executed again, then the cycle repeats...

[franco]

So here is the deal on collecting meaningful data:

/tmp/cache_rule_labels.json -- the cache file for the states, remove the file to see if that helps

# pfctl -vvPsr | grep -A4 @112

list a rule from the loaded ruleset from the kernel

# filterlog -l | grep ^112:

lists the label association from the kernel

# pfctl -vvs states | grep -C2 rule.112

lists all states associated

I tested 112 on my end and it works as expected.

Bonus questions: are the mismatches somehow relevant to aliases? The bootup does not load aliases unless connectivity with the Internet has been reached (in the common case) so states may be stuck on other rules.

Looking forward to examples.


Cheers,
Franco

[hharry]

here is just one example, where after OPsense reboot (no F/W rule change made). For me, aliases i don't believe are the issue. And the issue is not specific to the anti-lockout rule either, many other examples of sessions and states listed against incorrect rule ( other than anti-lock out rule ).

OPNsense 26.1.11_6-amd64, The below sessions, as shown in gfx image attached, are;

1. self initiated outbound BGP session, the source IP address is the PPPoE interface address
2. self initiated outbound ICMP gateway monitor, the source IP address is the PPPoE interface address

Neither of these sessions, meet the anti-lockout rule logic, yet that's how they are listed in the UI etc...

Code Select Expand

root@OPNsense_LAB:~ # pfctl -vvPsr | grep -A4 @32
No ALTQ support in kernel
ALTQ related functions disabled
@32 pass in quick on vmx2 proto tcp from any to (self:8) port = 22 flags S/SA keep state label "36d299b849ebe9b05a0f6345a51a906b"
  [ Evaluations: 7300      Packets: 988       Bytes: 120437      States: 1     ]
  [ Inserted: uid 0 pid 54268 State Creations: 1     ]
  [ Last Active Time: Tue Jul 14 19:41:27 2026 ]
@33 pass in quick on vmx2 proto tcp from any to (self:8) port = 80 flags S/SA keep state label "fef898ed65e45e8c227a870f82b2b68d"
root@OPNsense_LAB:~ #


root@OPNsense_LAB:~ #  pfctl -vvs states | grep -C2 rule.32
No ALTQ support in kernel
ALTQ related functions disabled
all tcp 10.0.0.163:22 <- 10.0.0.237:59484       ESTABLISHED:ESTABLISHED
   [3533813239 + 3489464576] wscale 10  [4123816029 + 262400] wscale 8
   age 00:05:40, expires in 24:00:00, 388:640 pkts, 32784:91349 bytes, rule 32
   id: a401496a00000000 creatorid: cfe531b8
   origif: vmx2
--
   origif: vmx3
all icmp 192.168.40.1:10406 -> 192.168.40.254:8       0:0
   age 267:15:10, expires in 00:00:10, 944926:944926 pkts, 27402854:27402854 bytes, rule 32, allow-opts, max-mss 1452
   id: 5256476a00000000 creatorid: cfe531b8 route-to: 192.168.40.254@pppoe1
   origif: pppoe1
all tcp 192.168.40.1:29603 -> 192.168.40.254:179       ESTABLISHED:ESTABLISHED
   [2763199284 + 4294836480] wscale 10  [498719610 + 524544] wscale 8
   age 267:15:01, expires in 23:59:59, 384846:381950 pkts, 23668079:23520397 bytes, rule 32, allow-opts, max-mss 1452
   id: 5356476a00000000 creatorid: cfe531b8 route-to: 192.168.40.254@pppoe1
   origif: pppoe1
root@OPNsense_LAB:~ #