Messages

perhaps you missed the UI screenshots i posted already -> https://forum.opnsense.org/index.php?msg=272854

which clearly show it's not working....

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


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

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

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




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


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

can you get the client OS to do a DHCP release, then DHCP renew ?

Also your reservation doesn't have the CID populated, and kea by default will try and match on CID (Match client-id), rather than MAC address, there is an option to disable CID matching, and to then match on MAC address instead, in the OPNsense KEA subnets UI...

I personally turn of KEA CID matching, as many client's rarely populate it, however your logs show the client is populating the CID (cid=[01:b8:1f:3f:fe:2d:74])...so perhaps add the proper CID to the reservation, then have the client do a DHCP release, then DHCP renew...

It's just a single file, take whichever version you want, or create your own:

https://github.com/opnsense/core/commits/master/src/opnsense/www/js/widgets/Services.js

Coke original taste xDD if you know what I mean

That would then break audit health checks, yeah ?

@franco is there a way to revert to the old services widget?, i'd rather have a vertical scroll button, where there is no long text run over....as below from my production OPNsense 26.1.11_10-amd64

i had the same issue, and the patch also worked.

@franco, will the patch be included in next release ?

Did you migrate your legacy firewall rules, to the new firewall rules ?

I migrated some time ago, and the icon/link to firewall rules in  interfaces > overview page is working without any issues for me...

also having the new and same issue...long items, like gateways and VPNs, run into the next column...

the answer is a little more nuanced.

It depends on the client, and the DHCP server

Some clients, like Win 10/11, Ubuntu, natively out of the box, automatically include DHCP Parameter option 119 (Domain search list) in their DHCP discover and DHCP request.

And some clients, like Android phones, don't natively request option 119 at all.

And some clients, like Linux clients, allow you to administratively configure which DHCP parameter options are requested in DHCP discover/requests...

On the DHCP server side, the DHCP option 119 (Domain search list) needs to be configured, to supply an answer to option 119 in DHCP offer and DHCP ack, to clients that asked/requested option 119 in DHCP discover/requests.

frr 10.6.1 ( currently used in both OPNsense and VYOS), supports  RIP routing to 'redistribute bgp route-map route_map_name'

I'm successfully used this in VYOS / FRR for years now.

It's an obvious OPNsense GUI config builder limitation, not implemented, even though FRR clearly supports it....

@ednt, you'll need to raise a github request to have it implemented in OPNsense GUI config builder...-> https://github.com/opnsense/core/issues