Messages

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

is there a clear understanding why this issue only impacted some OPNsense deployments ?

In all my OPNsense 25.7.4-amd64 deployments, i have several CA and server X.509v3 certificates, singed using sha256WithRSAEncryption, and having zero issues whatsoever....

same here, In earlier version 25.7.2, did not have this issue, seems like a clear regression.

Luckily i'd only upgraded pre-production LAB testing staging OPNsense and run into this issue, 25.7.3 won't be going into production....

same here, upgraded from 25.7.2 to 25.7.3 and now all the automatically generated firewall aliases (LAN, WAN, loopback, etc.) always show up as empty in Firewall -> Diagnostics -> Aliases.

In earlier version 25.7.2, did not have this issue, seems like a clear regression.

Luckily i'd only upgraded pre-production LAB testing staging OPNsense and run into this issue, 25.7.3 won't be going into production....

Youtube ads are not possible to block by DNS blackholing, as the ads are served from the same google CDN servers and domain names, as the regular content your watching. Adguard home does not block youtube add either for the same reason, your best option is to use brave broswer, with shields up, works perfectly -> https://brave.com/

Alternatively, zenarmor claims to have ad blocking, i'm not sure how good it is, never tried it -> https://www.zenarmor.com/docs/guides/how-to-block-ads-on-websites

For me i prefer to use Adguard home with OPNsense, as Adguard is quite lightweight and quite effective DNS blackhole, plus it has effective parental controls too, and i've already used brave browser for several years now, and enjoyed ad free youtube...

Perhaps this commit from yesterday:

# opnsense-patch https://github.com/opnsense/core/commit/30102d5ee4

A ticket on GitHub would speed this process up, BTW.


Cheers,
Franco

thanks Franco, i applied the patch to OPNsense 25.7.2-amd64, and have successfully tested the patch you provided in both test LAB and production environment's, in LAB i run nmap from the LAN side Linux host, to a WAN side destination, to create more than 10000 outbound active sessions, and confirmed it has resolved the issue, in the opnsense Firewall: Diagnostics: Sessions page

I also found the below pages also have the same issue, when there is a moderate number of rows to display, so perhaps i should raise a github ticket

opnsense Firewall: Diagnostics: States
opnsense Firewall: Diagnostics: Aliases

thanks for taking a look Franco, much appreciated.

I'm not sure which change regressed the behavior, but to replicate the issue, as below;

1. open the opnsense Firewall: Diagnostics: Sessions page
2. select the page option, All, i do this so i can scroll down and view all the F/W sessions on one single page, in earlier 25.1.x releases this always worked without delay, in opnsesne 25.7.x release, the page takes forever to load, with spinning circle. There is less than 1100 sessions, so the number is not massive....
3. entering an ip address, or other search string in the page search bar, again the page takes forever to load.


To workaround the regression, i reduce the number of rows to page display to something like 100, which helps speed up the page load and search, but then have multiple pages to further search for specific sessions / ports of interest etc...

I'll try the patch soon, once family have gone to bed....

Yes i can raise a templated github ticket...will do shortly...