How reliable is Firewall:Diagnostics:States for troubleshooting

[hharry]

so what are the next steps @franco ?

[franco]

discuss internally how to proceed

[franco]

https://github.com/opnsense/core/issues/10552

[franco]

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

[hharry]

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

[hharry]

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....

Code Select Expand

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:~ #


[hharry]

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.

Code Select Expand

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

Code Select Expand

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




[franco]

# 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.

[hharry]

# 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.

[franco]

> 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.

[hharry]

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...

[franco]

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

[hharry]

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

ok @franco, here it is just for you!

Code Select Expand

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:~ #


[franco]

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