Messages

It was not removed, I just told you how you can have it.

Also, you can still use the legacy rules for as long as you like, they're not going anywhere for a while.

highlighted in yellow is the button that is removed in 26.x, your simply trying to dodge the question !

You can also see it at all times in the new release, just toggle the "Inspect" and the "Tree View" buttons. They are sticky too so a reload will always show all rules and folders.

why was the automatic generated rules expand button removed in 26.x ?

I wouldn't call it a regression because you don't need to see them all the time, and it improves performance a lot by only collecting them when "Inspect" is active.

I rather have a more response GUI for day to day operation than seeing everything all the time.

In prior release;

1. Could see the automatic generated rules "display" button all the time, so the automatic generated rules wasn't showed all the time, as you needed to click the automatic rules button for then to show in GUI, but this button has disappeared in 26.x, so the option is removed. It is a user interface regression for zero apparent benefit.

2. never had any performance issue what so ever.

Hi hharry

The new GUI for the firewall rules is unfortunately a bit confusing and will certainly need some further optimization. To see the automatic rules, simply click the 'Inspect' button.

Thanks, it is a definite GUI regression, in prior 25.7.11 release could see the automatic generated rules all the time, not in inspection mode.

LAB sand box test environment upgraded from 25.7.11 to 26.1_4-amd64, and now unable to view automatic rules in new firewall.

Under the old firewalls rules, can see all the automatic rules applied, i used the rules migration feature, and cannot view any of the automatic generated rules in the new firewall rules...

Howto view automatic generated rules in new firewall rules ?

kea 3.0.2 supports DHCP options

https://kea.readthedocs.io/en/kea-3.0.2/arm/dhcp4-srv.html#standard-dhcpv4-options
https://kea.readthedocs.io/en/kea-3.0.2/arm/dhcp4-srv.html#dhcpv4-private-options
https://kea.readthedocs.io/en/kea-3.0.2/arm/dhcp4-srv.html#dhcpv4-vendor-specific-options

OPNsense GUI has not been developed to make options configuration for kea

i can confirm the OP's point here, i as able to re-create the issue in LAB, can clearly see the received PPPoE servers MRU = 1472, however whilst OPNsense LCP ack's the PPPoE servers MRU,  OPNsense then just defaults to a PPPoE interface MTU = 1492


Below can clearly see the PPPoE servers LCP advertised MRU = 1472, which OPNsesne LCP acks.

PPPoE server MAC address in below tcpdump == 00:0c:29:2a:de:ad

OPNsense PPPoE client interface MAC address == 00:0c:29:55:0d:8a

Code Select Expand

root@OPNsense_LAB:~ # tcpdump -nevi vmx0
tcpdump: listening on vmx0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
08:05:48.180841 00:0c:29:55:0d:8a > ff:ff:ff:ff:ff:ff, ethertype PPPoE D (0x8863), length 36: PPPoE PADI [Host-Uniq 0x40517C3B00F8FFFF] [Service-Name]
08:05:48.201268 00:0c:29:2a:de:ad > 00:0c:29:55:0d:8a, ethertype PPPoE D (0x8863), length 74: PPPoE PADO [AC-Name "VYOS03"] [Service-Name] [AC-Cookie 0x7A9041E0E45617BFDABF9F34EF35229B4B7E454C99D2D63C] [Host-Uniq 0x40517C3B00F8FFFF]
08:05:48.201293 00:0c:29:55:0d:8a > 00:0c:29:2a:de:ad, ethertype PPPoE D (0x8863), length 74: PPPoE PADR [Host-Uniq 0x40517C3B00F8FFFF] [AC-Cookie 0x7A9041E0E45617BFDABF9F34EF35229B4B7E454C99D2D63C] [AC-Name "VYOS03"] [Service-Name]
08:05:48.221657 00:0c:29:2a:de:ad > 00:0c:29:55:0d:8a, ethertype PPPoE D (0x8863), length 60: PPPoE PADS [ses 0x180] [AC-Name "VYOS03"] [Service-Name] [Host-Uniq 0x40517C3B00F8FFFF]
08:05:48.221879 00:0c:29:55:0d:8a > 00:0c:29:2a:de:ad, ethertype PPPoE S (0x8864), length 36: PPPoE  [ses 0x180] LCP (0xc021), length 16: LCP, Conf-Request (0x01), id 1, length 16
        encoded length 14 (=Option(s) length 10)
          MRU Option (0x01), length 4: 1492
          Magic-Num Option (0x05), length 6: 0xcb840b5a
08:05:48.221932 00:0c:29:2a:de:ad > 00:0c:29:55:0d:8a, ethertype PPPoE S (0x8864), length 60: PPPoE  [ses 0x180] LCP (0xc021), length 21: LCP, Conf-Request (0x01), id 137, length 21
        encoded length 19 (=Option(s) length 15)
          Auth-Prot Option (0x03), length 5: CHAP, MD5
          MRU Option (0x01), length 4: 1472
          Magic-Num Option (0x05), length 6: 0x5a0802f3
08:05:48.222042 00:0c:29:55:0d:8a > 00:0c:29:2a:de:ad, ethertype PPPoE S (0x8864), length 41: PPPoE  [ses 0x180] LCP (0xc021), length 21: LCP, Conf-Ack (0x02), id 137, length 21
        encoded length 19 (=Option(s) length 15)
          Auth-Prot Option (0x03), length 5: CHAP, MD5
          MRU Option (0x01), length 4: 1472
          Magic-Num Option (0x05), length 6: 0x5a0802f3
08:05:48.242128 00:0c:29:2a:de:ad > 00:0c:29:55:0d:8a, ethertype PPPoE S (0x8864), length 60: PPPoE  [ses 0x180] LCP (0xc021), length 16: LCP, Conf-Ack (0x02), id 1, length 16
        encoded length 14 (=Option(s) length 10)
          MRU Option (0x01), length 4: 1492
          Magic-Num Option (0x05), length 6: 0xcb840b5a



Operationally the PPPoE interface MTU on OPNsense still defaults to 1492, despite LCP ack'ing the remote PPPoE servers MRU = 1472

Code Select Expand

root@OPNsense_LAB:~ # ifconfig
pppoe1: flags=10088d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492
        description: WAN (wan)
        options=0
        inet 192.168.40.1 --> 192.168.40.254 netmask 0xffffffff
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>


OPNsense not handling any vlan's in above example!, all vlan handling performed in ESXi vSwitch port groups...

Most vendors consider such behavior as a clear and repeatable defect, needing fixing !

Kea is a relatively new introduction to opnsense, i'm not sure why kea-dhcp-ddns hasn't been implemented, but kea supports it...over here -> https://kea.readthedocs.io/en/kea-3.0.1/arm/ddns.html, nor do i know if it's already on the opnsense roadmap....as this question had been requested before, but closed without implementation...

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

You'll likely get push back for native kea ddns support, along the lines to use unbound DNS, for the DDNS component...

AFAIK, the dashboard gateways widget is meant to display the gateway IP address being monitored.

You should check in Interfaces: Overview for the gateway ip address...also check in System: Gateways: Configuration, ideally your Monitor address should = interface gateway address.

If the widget still reporting incorrect interface gateway IP address, you could also try deleting the dashboard gateway widget, then re-adding it to see if it clears up....

it's starting up on boot ok for me, OPNsense 25.7.6-amd64 with adguard v0.107.69.

from /var/log/system/latest.log

Code Select Expand

<13>1 2025-11-01T08:08:49+11:00 OPNsense_LAB.localdomain kernel - - [meta sequenceId="12"] ---<<BOOT>>---
.
.
.
<13>1 2025-11-01T08:08:55+11:00 OPNsense_LAB.localdomain kernel - - [meta sequenceId="450"] <118>[41] Starting adguardhome.
.
.
.
<13>1 2025-11-01T08:09:08+11:00 OPNsense_LAB.localdomain kernel - - [meta sequenceId="20"] <118>*** OPNsense_LAB.localdomain: OPNsense 25.7.6 (amd64) ***


Perhaps you can check your logs, and also do a health check too...

what do the graphs look like in Reporting: Health, then select Category: System, Subject: states....

# opnsense-patch https://github.com/opnsense/core/commit/2abca1ccde42f
# opnsense-patch https://github.com/opnsense/core/commit/25fee9b05b7f8
# opnsense-patch https://github.com/opnsense/core/commit/08c88a1f3e19a

In that order. Try after each one to evaluate the effect is has.


Cheers,
Franco

I applied https://github.com/opnsense/core/commit/2abca1ccde42f to OPNsense 25.7.6-amd64,, and re-run several penetration nmap scan tests, and looking much better, the browser TAB CPU utilization is looking much lower, and the live view never froze or became unresponsive....I haven't applied any other patch...

+1 here, i've been testing OPNsense 25.7.6-amd64 in LAB sandbox pre-production environment, and find when there are a number of firewall denies, the page just locks up and becomes completely unresponsive, using fully upto date brave and chrome browser's etc...

The issue is 100% reproducible on OPNsense 25.7.6-amd64, very easy to replicate....on demand...one just needs to run a wan side initiated penetration test using nmap from a host on the wan side of OPNsense, destined to OPNsense wan interface IP address to replicate the issue....


Running the same test on OPNsense 25.7.5-amd64  completely resolves the issue, so it's a clear regression.

you should check the log file in Services: Kea DHCP: Log File, be sure to set the log level in the pull down box to informational.

Also do you see kea listening on the expected interfaces from the ssh cli command as below example

Code Select Expand

root@OPNsense:~ # sockstat -ln | egrep -ai 'user|:67'
USER     COMMAND    PID   FD  PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
0        kea-dhcp4  19321 15  udp4   10.0.1.138:67         *:*
root@OPNsense:~ #

i see, so the source of your corruption is not yet identified ?

I've had NordVPN Root CA X.509 cert installed since migrating to new openvpn instance configuration, once i upgraded to 25.7...

I've only recently in last several months deployed additional subordinate CA and server X.509 certs to OPNsense deployments....been through several upgrades since, and no corruption so far