Messages

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

as the default F/W rule on WAN interfaces, is drop, i'm not interested in unsolicited inbound dropped traffic, i instead run suricata in IDS mode on all LAN interfaces....which included all outbound LAN-> WAN traffic as well. So my attention is only focused in internal potential threats, and not concerned in unsolicited inbound dropped traffic....

From my side I can currently rule out a pure L1 problem, since I always have an uplink to the modem, even when PPPoE drops. Do you generally run without VLAN tagging on the WAN, or do you offload the VLAN to the modem? In my setup, there's nothing between the modem and the OPNsense: WAN port goes directly to the modem, LAN to my Unifi 48PoE switch.

That modem is performing a L2 bridge / switch function..

In my deployments, my upstream WAN provider presents ethernet L2 as untagged, and in their L2 domain, is where my traffic is then encapsulated and switched in it's own unique S-TAG'ed VLAN

Other folks running vlan interfaces on OPNsense have in the past reported some connectivity issues, i suggest you use the forum search function to find them...

Can your on-premises modem present your WAN ethernet as untagged ?

i would start by looking at WAN L1 and L2 issues, i run PPPoE on several OPNsense deployments and it's been rock solid. Using untagged ethernet on the WAN side, is only difference in my deployments.


If your able to capture a tcpdump on igc0 interface when the issue occurs would help confirm that the PPPoE PADI discovery packets should be hitting the wire.

Is there a L2 domain under you control connecting to igc0 ? It is sanitized and rock solid ?

When the issue occurs, have tried first re-starting the DrayTek modem instead ?

so kea successfully gave 7 hours of lease affinity with below config, it behaved exactly according to kea 2.6.3 documentation

Code Select Expand

    "expired-leases-processing": {
        "reclaim-timer-wait-time": 10,
        "hold-reclaimed-time": 25200,
        "flush-reclaimed-timer-wait-time": 25
    },

Now that testing is done, I've now increased the lease affinity to 30 days (2592000 seconds ), as below....

Code Select Expand

        "expired-leases-processing": {
            "reclaim-timer-wait-time": 10,
            "hold-reclaimed-time": 2592000,
            "flush-reclaimed-timer-wait-time": 25
        },


Great to hear! I will try to add it over the next day or two. I will let you know to try it, if you feel brave :)

I already have it implemented, with 30 days of lease affinity, and have no intention of reverting back to having zero lease affinity...be nice if the OPNsense devs would expose the options to the UI so manual control of /usr/local/etc/kea/kea-dhcp4.conf is no longer needed...

wink wink -> https://github.com/opnsense/core/issues/9094

Yeah, I have seen the github issue. I am willing to fix it/ expose it to the UI for everyone.

Anyway, I will ping you when the code is ready but will probably test it myself since I don't see you being brave enough 😅

Thank your Sir, i'm always to happy to test code etc, already have a sandbox pre-production envionment allways available for use...

Would appreciate your feedback on this:

Code Select Expand

opnsense-patch -a sopex -c core c6d7453d5809d948df6f29eba32b6aee39b02227

patch worked, without any issue, and i found the UI options you added to be intuitive and effective, and built the correct / expected config in /usr/local/etc/kea/kea-dhcp4.conf

Thank you sir, very well done. Let me know if you'd like some test artifacts, screenshots etc...that may help with pull request / check in etc...

It seems for OSPFv2 (IPv4) the built syntax is correct, and operational

Code Select Expand

root@OPNsense:~ # vtysh

Hello, this is FRRouting (version 10.4).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

OPNsense.localdomain# show ip ospf neighbor

Neighbor ID     Pri State           Up Time         Dead Time Address         Interface                        RXmtL RqstL DBsmL
10.0.0.11         0 Full/DROther    1w1d18h           19.817s 10.0.0.11       vmx0:10.0.0.138                      0     0     0
10.0.0.45         0 Full/DROther    1w1d18h           19.818s 10.0.0.45       vmx0:10.0.0.138                      0     0     0
10.0.0.105      200 Full/Backup     1w1d18h           19.818s 10.0.0.105      vmx0:10.0.0.138                      0     0     0

OPNsense.localdomain# show running-config

Building configuration...

Current configuration:
!
frr version 10.4
frr defaults traditional
hostname OPNsense.localdomain
log syslog notifications
!
interface vmx0
 ip ospf area 0.0.0.10
 ip ospf authentication message-digest
 ip ospf dead-interval 20
 ip ospf hello-interval 5
 ip ospf message-digest-key 1 md5 nicetry....!
 ip ospf priority 254
 ip ospf retransmit-interval 4
exit




so kea successfully gave 7 hours of lease affinity with below config, it behaved exactly according to kea 2.6.3 documentation

Code Select Expand

    "expired-leases-processing": {
        "reclaim-timer-wait-time": 10,
        "hold-reclaimed-time": 25200,
        "flush-reclaimed-timer-wait-time": 25
    },

Now that testing is done, I've now increased the lease affinity to 30 days (2592000 seconds ), as below....

Code Select Expand

        "expired-leases-processing": {
            "reclaim-timer-wait-time": 10,
            "hold-reclaimed-time": 2592000,
            "flush-reclaimed-timer-wait-time": 25
        },


Great to hear! I will try to add it over the next day or two. I will let you know to try it, if you feel brave :)

I already have it implemented, with 30 days of lease affinity, and have no intention of reverting back to having zero lease affinity...be nice if the OPNsense devs would expose the options to the UI so manual control of /usr/local/etc/kea/kea-dhcp4.conf is no longer needed...

wink wink -> https://github.com/opnsense/core/issues/9094

Yeah, I have seen the github issue. I am willing to fix it/ expose it to the UI for everyone.

Anyway, I will ping you when the code is ready but will probably test it myself since I don't see you being brave enough 😅

Thank your Sir, i'm always to happy to test code etc, already have a sandbox pre-production envionment allways available for use...

so kea successfully gave 7 hours of lease affinity with below config, it behaved exactly according to kea 2.6.3 documentation

Code Select Expand

    "expired-leases-processing": {
        "reclaim-timer-wait-time": 10,
        "hold-reclaimed-time": 25200,
        "flush-reclaimed-timer-wait-time": 25
    },

Now that testing is done, I've now increased the lease affinity to 30 days (2592000 seconds ), as below....

Code Select Expand

        "expired-leases-processing": {
            "reclaim-timer-wait-time": 10,
            "hold-reclaimed-time": 2592000,
            "flush-reclaimed-timer-wait-time": 25
        },


Great to hear! I will try to add it over the next day or two. I will let you know to try it, if you feel brave :)

I already have it implemented, with 30 days of lease affinity, and have no intention of reverting back to having zero lease affinity...be nice if the OPNsense devs would expose the options to the UI so manual control of /usr/local/etc/kea/kea-dhcp4.conf is no longer needed...

wink wink -> https://github.com/opnsense/core/issues/9094