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.
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.
Quote from: DaElephant on July 11, 2026, 03:22:51 PM[...]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).
Quote[...]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.
Is this what you are looking for?
These are the 3 rules on the interface
Screenshot 2026-07-11 152511.png
These are the aliases
Screenshot 2026-07-11 152741.png
Screenshot 2026-07-11 152801.png
This what shows in states table
Screenshot 2026-07-11 153125.png
It does follow the correct rules some times.
Screenshot 2026-07-11 153337.png
Huh. What does the inbound state look like? I'd expect a pair like this...states.jpg
Edit: Also, check "Firewall: Diagnostics: Statistics" -> "rules".
Quote from: pfry on July 12, 2026, 02:31:51 AMHuh. What does the inbound state look like? I'd expect a pair like this...states.jpg
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.
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.
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...
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
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 match criteria logic, yet that's how they are listed in the UI etc...
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:~ #
Thanks for the details... I see. Unfortunately the kernel says it's rule 32. I'm unsure how it came to this conclusion. The userspace does not assign rule numbers.
Perhaps it's related to anchors not restoring rule numbers which we investigated for 26.7:
https://github.com/opnsense/src/issues/295
Cheers,
Franco
One other thing to check is the rule optimisation setting under firewall: settings: advanced. nope, we don't actually expose this setting
If I read this correctly the state dump only gives us the rule number "nr" but since there is a rule pointer which can be dereferenced we could try to push something more clever to userland if it is actually there.
https://github.com/opnsense/src/blob/stable/26.1/sys/netpfil/pf/pf_ioctl.c#L5870-5873
But you see the point here is as long as pfctl/pf insists the rule nr is the same (which it isn't across reloads in a dynamic network as rules can be added and removed as networks/gateways are up and down) there is little to do from the core side.
Cheers,
Franco
https://github.com/opnsense/src/commit/e4f197683
> all udp x.x.x.x:443 <- y.y.y.y:62035 MULTIPLE:MULTIPLE
> age 00:00:07, expires in 00:14:53, 9:13 pkts, 3469:4730 bytes, rule 111, rlabel 191ffc6095ac1e6b8cce545a84ea8207
> id: 2ba7576a00000000 creatorid: 55fdcfca
> origif: igc0
;)
so what are the next steps @franco ?
discuss internally how to proceed
https://github.com/opnsense/core/issues/10552
Any testers?
# opnsense-update -zbr 26.7.2-label
# opnsense-patch https://github.com/opnsense/core/commit/a698c1d94a
(does not need a reboot)
The base should have been fixed in 26.7.2 already but there was a little mistake with the final cherry-pick if anyone is wondering: https://github.com/opnsense/src/commit/49721cdf35a
Cheers,
Franco
i tried and still replicated the issue on 26.7.2_2-amd64 yesterday, but i can apply the patch later today and do some testing...
as my OPNsense is already running 26.7.2_2-amd64, i only need to apply the patch, yes ?
# opnsense-patch https://github.com/opnsense/core/commit/a698c1d94a
i successfully applied the patch as below, then rebooted, however the issue still persists, some sample screenshots as below. None of the below sessions match the anti-lockout rule, yet that's how they appear in the UI...and none of the sessions match the 'Block IPC8 rule' too...., yet that's how they appear in the UI..there are many more such samples that could be provided....
root@OPNsense_LAB:~ # opnsense-patch https://github.com/opnsense/core/commit/a698c1d94a
Fetched a698c1d94a via https://github.com/opnsense/core
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|From a698c1d94a75d0f3389257bcd21278801bf4d0e7 Mon Sep 17 00:00:00 2001
|From: Ad Schellevis <ad@opnsense.org>
|Date: Thu, 13 Aug 2026 16:10:17 +0200
|Subject: [PATCH] Firewall: Diagnostics - use new rlabel from pfctl, closes
| https://github.com/opnsense/core/issues/10552
|
|since pftop uses numbers as well, we need to map these to labels too, which means mapping labels to numbers with `pfctl -vvPsr` inside the query_top() function.
|---
| src/opnsense/scripts/filter/lib/states.py | 78 ++++++++------------
| src/opnsense/scripts/filter/list_rule_ids.py | 16 ++--
| src/opnsense/scripts/filter/list_states.py | 2 +-
| 3 files changed, 39 insertions(+), 57 deletions(-)
|
|diff --git a/src/opnsense/scripts/filter/lib/states.py b/src/opnsense/scripts/filter/lib/states.py
|index 55f71249ec1..198e1174c12 100755
|--- a/src/opnsense/scripts/filter/lib/states.py
|+++ b/src/opnsense/scripts/filter/lib/states.py
--------------------------
Patching file opnsense/scripts/filter/lib/states.py using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 24.
Hunk #3 succeeded at 67.
Hunk #4 succeeded at 122.
Hunk #5 succeeded at 227.
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/opnsense/scripts/filter/list_rule_ids.py b/src/opnsense/scripts/filter/list_rule_ids.py
|index dc353952f1b..2840e3b4ecb 100755
|--- a/src/opnsense/scripts/filter/list_rule_ids.py
|+++ b/src/opnsense/scripts/filter/list_rule_ids.py
--------------------------
Patching file opnsense/scripts/filter/list_rule_ids.py using Plan A...
Hunk #1 succeeded at 1.
Hunk #2 succeeded at 31.
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/opnsense/scripts/filter/list_states.py b/src/opnsense/scripts/filter/list_states.py
|index bf74722c22f..dc4a6c5e42c 100755
|--- a/src/opnsense/scripts/filter/list_states.py
|+++ b/src/opnsense/scripts/filter/list_states.py
--------------------------
Patching file opnsense/scripts/filter/list_states.py using Plan A...
Hunk #1 succeeded at 1.
done
All patches have been applied successfully. Have a nice day.
root@OPNsense_LAB:~ #
here is a 'sample' additional debug info ( when running with patch applied, and after reboot ) for the 'Block IPC8' rule session/state
This rule isn't even applied to the vmx3 interface, it is applied to the vmx2 interface, yet the session appears under this rule, as originating from vmx3 interface on rule 'Block IPC8', which is not applied to vmx3 interface, really messed up!
vmx2 and vmx3 are separate interfaces, not connected to each other, they are separate and completely mutually exclusive L2 domains entirely...handled by ESXi vswitch vlans.
mappings as below, from OPNsense point of view
vmx2 <> untagged native VLAN 1 <> 10.0.0.0/24
vmx3 <> untagged VLAN 4 <> 10.0.1.0/24
In addition, the the state/session does not match the 'Block IPC8' match criteria either.
root@OPNsense_LAB:~ # pfctl -vvPsr | grep -A4 @41
No ALTQ support in kernel
ALTQ related functions disabled
@41 block drop in quick on vmx2 inet from <IPC8:1> to any label "dadac13d-fc61-4e50-9ff3-4769740d87b1"
[ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ]
[ Source Nodes: 0 Limit: 0 NAT/RDR: 0 Route: 0 ]
[ Inserted: uid 0 pid 0 State Creations: 0 ]
[ Last Active Time: N/A ]
root@OPNsense_LAB:~ # pfctl -vvs states | grep -C2 rule.41
No ALTQ support in kernel
ALTQ related functions disabled
all udp 255.255.255.255:6667 <- 10.0.1.2:59239 NO_TRAFFIC:SINGLE
age 00:21:12, expires in 00:00:25, 254:0 pkts, 58928:0 bytes, rule 41, rlabel c0b243c6-f1d4-471d-8dcf-62046c6215b0
id: a8547e6a00000000 creatorid: 30335776
origif: vmx3
root@OPNsense_LAB:~ #
A tcpdump shows the traffic is, as expected arriving on vmx3 interface only
root@OPNsense_LAB:~ # tcpdump -nevpi vmx2 host 10.0.1.2
tcpdump: listening on vmx2, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^[[A^C
0 packets captured
827 packets received by filter
0 packets dropped by kernel
root@OPNsense_LAB:~ # tcpdump -nevpi vmx3 src host 10.0.1.2 and dst host 255.255.255.255
tcpdump: listening on vmx3, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:34:18.270377 3c:0b:59:df:a5:cc > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 246: (tos 0x0, ttl 255, id 54285, offset 0, flags [none], proto UDP (17), length 232)
10.0.1.2.59239 > 255.255.255.255.6667: UDP, length 204
12:34:23.273712 3c:0b:59:df:a5:cc > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 246: (tos 0x0, ttl 255, id 54286, offset 0, flags [none], proto UDP (17), length 232)
10.0.1.2.59239 > 255.255.255.255.6667: UDP, length 204
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel
root@OPNsense_LAB:~ # tcpdump -nevpi vmx2 src host 10.0.1.2 and dst host 255.255.255.255
tcpdump: listening on vmx2, link-type EN10MB (Ethernet), snapshot length 262144 bytes
Quote from: franco on August 13, 2026, 04:21:54 PM# opnsense-update -zbr 26.7.2-label
# opnsense-patch https://github.com/opnsense/core/commit/a698c1d94a
(does not need a reboot)
Please follow these instructions.
Quote from: franco on August 14, 2026, 08:20:23 AMQuote from: franco on August 13, 2026, 04:21:54 PM# opnsense-update -zbr 26.7.2-label
# opnsense-patch https://github.com/opnsense/core/commit/a698c1d94a
(does not need a reboot)
Please follow these instructions.
Already did, and the issues noted above all still persist.
> as my OPNsense is already running 26.7.2_2-amd64, i only need to apply the patch, yes ?
vs.
> # opnsense-update -zbr 26.7.2-label
The answer is no.
as i already stated @franco, i followed your steps, and the issue still persists, and provided some details and debug data for you, so you can take that feedback or leave it, upto you...
Just make sure you actually installed the base package please.
# opnsense-version base
If that's the one mentioned above then make sure your labels are appearing in pfctl:
# pfctl -vvs states | grep rlabel
Then make sure your patch is properly applied and not reversed.
I checked the result with a colleague and firewall live log looks as before.
There's no real way for this to go wrong unless at point 1.
Cheers,
Franco
Quote from: franco on August 14, 2026, 11:11:10 AMJust make sure you actually installed the base package please.
# opnsense-version base
If that's the one mentioned above then make sure your labels are appearing in pfctl:
# pfctl -vvs states | grep rlabel
Then make sure your patch is properly applied and not reversed.
I checked the result with a colleague and firewall live log looks as before.
There's no real way for this to go wrong unless at point 1.
Cheers,
Franco
ok @franco, here it is just for you!
root@OPNsense_LAB:~ # opnsense-version base
26.7.2-label
root@OPNsense_LAB:~ # pfctl -vvs states | grep rlabel
No ALTQ support in kernel
ALTQ related functions disabled
age 00:08:37, expires in 00:00:29, 104:0 pkts, 24128:0 bytes, rule 50, rlabel c0b243c6-f1d4-471d-8dcf-62046c6215b0
age 00:08:33, expires in 00:00:10, 511:511 pkts, 14819:14819 bytes, rule 32, rlabel 112afb25dbf20a25190de3292c1a37df, allow-opts, max-mss 1452
age 00:08:21, expires in 23:59:59, 209:208 pkts, 12939:14956 bytes, rule 33, rlabel 112afb25dbf20a25190de3292c1a37df, allow-opts, max-mss 1452
age 00:08:15, expires in 00:00:58, 61:60 pkts, 7682:10847 bytes, rule 33, rlabel 112afb25dbf20a25190de3292c1a37df, allow-opts, max-mss 1452
age 00:08:12, expires in 00:00:52, 20:19 pkts, 4284:7382 bytes, rule 33, rlabel 112afb25dbf20a25190de3292c1a37df, allow-opts, max-mss 1452
age 00:00:53, expires in 24:00:00, 54:78 pkts, 7088:13173 bytes, rule 28, rlabel 36d299b849ebe9b05a0f6345a51a906b
age 00:00:24, expires in 00:00:06, 1:1 pkts, 53:117 bytes, rule 27, rlabel fcc89aee950e474ad952872fb6c678aa, allow-opts
age 00:00:24, expires in 00:00:06, 1:1 pkts, 53:165 bytes, rule 27, rlabel fcc89aee950e474ad952872fb6c678aa, allow-opts
age 00:00:14, expires in 00:00:16, 1:1 pkts, 76:76 bytes, rule 27, rlabel fcc89aee950e474ad952872fb6c678aa, allow-opts
age 00:00:02, expires in 00:00:08, 1:1 pkts, 29:29 bytes, rule 27, rlabel fcc89aee950e474ad952872fb6c678aa, allow-opts, max-mss 1360
root@OPNsense_LAB:~ #
Then I don't understand your report. It's merely using labels now instead of rule ids and the first post you talk about are different labels for rule id 41 which actually proves that the patch works.
Cheers,
Franco
perhaps you missed the UI screenshots i posted already -> https://forum.opnsense.org/index.php?msg=272854
which clearly show it's not working....
Without the -label package, reboot, patch steps Franco posted I get nothing from pfctl -vvs states | grep rlabel.
Once I follow the steps I get a lot of rlabel entries just as seen in your previous post.
The patch is fine. Afaik it's already in the latest BE and will come out in 26.7.3 for anyone who didn't see this thread.
I think you're expecting something different to happen...unsure what exactly.
Quote from: hharry on August 15, 2026, 12:43:59 AMperhaps you missed the UI screenshots i posted already -> https://forum.opnsense.org/index.php?msg=272854
which clearly show it's not working....
Still unsure and a bit exhausted by this discussion. Your states dump indicates the packet originated from vmx3 which cannot match
@41 block drop in quick on vmx2 inet from <IPC8:1> to any label "dadac13d-fc61-4e50-9ff3-4769740d87b1"
so the label is rlabel c0b243c6-f1d4-471d-8dcf-62046c6215b0 which is a different rule.
I take not accuracy for the state tracking. I merely added the label from the associated rule. If there is more considerable weirdness in the state tracking we've only just started being able to diagnose it.
That being said it's really demotivating to get negativity for doing something uniquely new trying to solve this for the community. Isn't the first time coming from you to be honest.
Cheers,
Franco
@newsense it's not in business as that is still on 14.3 and this is specific to 15.1