Messages

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

so what are the next steps @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...

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

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

I also have a question OPNsense 26.1.11_6-amd64

I see under outbound hybrid ( legacy rules ), automatic rules including the below sources ( which is correct )

LAN networks, LAN_VL4 networks, LAN_VL23 networks, Loopback networks, au761nordvpncom networks, us9417nordvpncom networks, 127.0.0.0/8



I've upgraded to OPNsense 26.1.11_6-amd64, and run the migration wizard, on see the below SNAT automatic rules, which seems to be missing LAN networks, au761nordvpncom networks, us9417nordvpncom networks

Loopback network, LAN_VL4 network, LAN_VL23 network

LAN side Interfaces are;

LAN
LAN_VL4
LAN_VL23

Automatic rule generation is enabled
OPNsense is not handling VLAN tagging, ESXi vswitch handles all vlan tagging, and interfaces are presented as untagged interfaces to OPNsense VM