Messages

A possible alternative to reducing bad to 1220 is to enable the newer pmtu discovery

I noticed this is setup via

net.inet.tcp.pmtud_blackhole_detection=1
net.inet.tcp.pmtud_blackhole_mss=1220

Have added this but I'll stick with the max at 1220 too for a day anyway.

But this might resolve the opnsense issue - if the stack remembers long enough since it seems many many network have a lower limit for various reasons, and so it may be a balance....

ISP is EE(BT) in the UK. 1 Gbps service (this and lower services are provisioned very differently to the 1.6 Gbps service+)

I have had some trouble with various sites & my ISP
 - many networks discard fragmented IPv6 packets
 - my ISP appears to be blocking ALL icmp responses for things like packet too big. (confirmed with isp router as well as opnsense - nothing coming in on a tcpdump :-( )

The consequence is black holes! I hate this.... !!

As a consequence I've now configured my RA to force a MSS of 1240 (Link MTU 1280), and I also have a normalization rule (for all ipv6 tcp) to set the mss to 1220. This seems to address client issues

However I notice that unbound does have an issue:

root@OPNsense:/usr/local/opnsense/service/templates/OPNsense/Unbound/core # drill . DNSKEY @2001:4860:4860::8888
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 10473
;; flags: qr tc rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; .    IN      DNSKEY

;; ANSWER SECTION:

;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:

;; Query time: 3 msec                                                                                                                         ;; SERVER: 2001:4860:4860::8888
;; WHEN: Sun Feb  8 17:52:17 2026
;; MSG SIZE  rcvd: 17

;; WARNING: The answer packet was truncated; you might want to                                                                                ;; query again with TCP (-t argument), or EDNS0 (-b for buffer size)
root@OPNsense:/usr/local/opnsense/service/templates/OPNsense/Unbound/core #

This would be because opnsense itself will still be using the regular mtu (1500) ...

unbound will work with:

root@OPNsense:/usr/local/opnsense/service/templates/OPNsense/Unbound/core # drill -b 1232 . DNSKEY @2001:4860:4860::8888                      ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 65176
;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0                                                                         ;; QUESTION SECTION:
;; .    IN      DNSKEY
;; ANSWER SECTION:                                                                                                                            .       56179   IN      DNSKEY  257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ;{id = 20326 (ksk), size = 2048b}
.       56179   IN      DNSKEY  256 3 8 AwEAAbNTVC2+pry4pc37pZI9Oj6b8FHxT3VGrvSPKLE1Tjyfe2kUZUtVX5xrv6AV4BVO+ygrYjGZMNgEnbLU4zknnlnhI2e0g6iTza1aZh0dRZXGH16C1NUNq1CxBkUhIYQhQDeIOtLacx+RmFTc+hSHJJ2MJ79IS00kA7eKi6mofQ7SPJmdJVjI+JAx791y0f5QaB+iHGANU53FwiYXNUQjfAzCrtOaSevGsx8SO8BTaXLAjFq5eewOtwScVwfVDhEXlvpE6e+mIncwhNKaMRD9IPuHENqCNPI5MjxfAMVS6cEY8eEozIkv/vHc+0Auu3n+Fcx6F2Js4KPXaHEShAXugfU= ;{id = 21831 (zsk), size = 2048b}    .       56179   IN      DNSKEY  257 3 8 AwEAAa96jeuknZlaeSrvyAJj6ZHv28hhOKkx3rLGXVaC6rXTsDc449/cidltpkyGwCJNnOAlFNKF2jBosZBU5eeHspaQWOmOElZsjICMQMC3aeHbGiShvZsx4wMYSjH8e7Vrhbu6irwCzVBApESjbUdpWWmEnhathWu1jo+siFUiRAAxm9qyJNg/wOZqqzL/dL/q8PkcRU5oUKEpUge71M3ej2/7CPqpdVwuMoTvoB+ZOT4YeGyxMvHmbrxlFzGOHOijtzN+u1TQNatX2XBuzZNQ1K+s2CXkPIZo7s6JgZyvaBevYtxPvYLw4z9mR7K2vaF18UYH9Z9GNUUeayffKC73PYc= ;{id = 38696 (ksk), size = 2048b}

    ;; AUTHORITY SECTION:

                                                                                                                         ;; ADDITIONAL SECTION:

                                                                                                                        ;; Query time: 5 msec
;; EDNS: version 0; flags: ; udp: 512                                                                                                         ;; SERVER: 2001:4860:4860::8888
;; WHEN: Sun Feb  8 17:52:41 2026                                                                                                             ;; MSG SIZE  rcvd: 853
root@OPNsense:/usr/local/opnsense/service/templates/OPNsense/Unbound/core #

So I thought I should set
edns-buffer-size: 1232
msg-buffer-size: 8192

but had trouble figuring out how to inject these values. Eventually for a test I just edited config /var/unbound/unbound.conf directly and sent a SIGHUP.

Still the error. Then checking the unbound docs at https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html it seems as if the default for edns-buffer-size and max-udp-size is already 1232 - as an outcome from DNS flag day. Yet it doesn't seem this way

Has anyone figured out this can of worms?

or is this just a client issue? (drill) and I shouldn't need to worry. I'm concerned it may be comprimising my dns resolution/dnssec in some way? Or indeed are there any other changes recommended on opnsense itself, given that it's unique in the network in not having the info from the RAs.

ah! fantastic!

I've noticed a lot of SERVFAIL noise with one particular DNS server which, on investigation, is behaving correctly (FORMERR->SERVFAIL) when receiving requests for local addresses.

I wanted to add something like that below, but I'm unsure if this is possible given that the unbound config files are rewritten each time. Is there any 'safe' override location? Or would adding this require a code change?

server:
    ########################################
    # RFC 6303: Local-use reverse zones
    ########################################

    # Loopback
    local-zone: "127.in-addr.arpa." static
    local-data-ptr: "127.0.0.1 localhost."

    # Private-use
    local-zone: "10.in-addr.arpa." static
    local-zone: "168.192.in-addr.arpa." static
    local-zone: "16.172.in-addr.arpa." static
    local-zone: "17.172.in-addr.arpa." static
    local-zone: "18.172.in-addr.arpa." static
    local-zone: "19.172.in-addr.arpa." static
    local-zone: "20.172.in-addr.arpa." static
    local-zone: "21.172.in-addr.arpa." static
    local-zone: "22.172.in-addr.arpa." static
    local-zone: "23.172.in-addr.arpa." static
    local-zone: "24.172.in-addr.arpa." static
    local-zone: "25.172.in-addr.arpa." static
    local-zone: "26.172.in-addr.arpa." static
    local-zone: "27.172.in-addr.arpa." static
    local-zone: "28.172.in-addr.arpa." static
    local-zone: "29.172.in-addr.arpa." static
    local-zone: "30.172.in-addr.arpa." static
    local-zone: "31.172.in-addr.arpa." static

    # Link-local
    local-zone: "254.169.in-addr.arpa." static

    # TEST-NETs
    local-zone: "2.0.192.in-addr.arpa." static
    local-zone: "100.51.198.in-addr.arpa." static
    local-zone: "113.0.203.in-addr.arpa." static

    # Multicast / reserved (optional)
    local-zone: "224.in-addr.arpa." static
    local-zone: "225.in-addr.arpa." static
    local-zone: "226.in-addr.arpa." static
    local-zone: "227.in-addr.arpa." static
    local-zone: "228.in-addr.arpa." static
    local-zone: "229.in-addr.arpa." static
    local-zone: "230.in-addr.arpa." static
    local-zone: "231.in-addr.arpa." static
    local-zone: "232.in-addr.arpa." static
    local-zone: "233.in-addr.arpa." static
    local-zone: "234.in-addr.arpa." static
    local-zone: "235.in-addr.arpa." static
    local-zone: "236.in-addr.arpa." static
    local-zone: "237.in-addr.arpa." static
    local-zone: "238.in-addr.arpa." static
    local-zone: "239.in-addr.arpa." static

    ########################################
    # Special-use forward zones
    ########################################

    # mDNS / Bonjour
    local-zone: "local." static
    # Home networking
    local-zone: "home.arpa." static

    ########################################
    # Optional: Dummy PTR for LAN gateway
    ########################################
    # Replace 192.168.1.1 with your actual gateway IP
    local-data-ptr: "192.168.1.1 router. Local."

I've got cloudflare ddns configured (method - interface ipv4, wan,)

In the dashboard widget, as well as under Service->Dynamic DNS->settings the 'currentIP' and 'last updated' fields are blank

However the log file seems to indicate ddclient is working properly, and has updated ddns to the correct IP - and at least currently, it is correct (though my connection whilst dynamic is very stable, though I did reboot earlier today after messing with the 25.7 update!)

So could just be cosmetic issue with the panels?

and also confirmed here (op)!

With 25.7 I don't seem to be able to get netflow working.

- destination is set to 127.0.0.1:2056
- lan, wan are listening
- wan interface is 'wan'
- local capture is selected
- using v9
- insight aggregator/netflow distributor are running (and has been restarted)
- I've reset the rrd & netflow data

I still don't seem to get any data showing up under reporting->insight

I cannot 'telnet 127.0.0.1:2056'

I do have a large flowd.log file

I was able to sort this out (thanks to gemini)
 - unlocked/force removed opnsense-devel
 - ran bootstrap
 - force-sync

Seems intact - nice to see how the recovery processes work

Last week I upgraded to 25.7 RC2 - which has worked well. I did this by changing to the development stream and then updating.

Now that 25.7 is released I switched back to the community stream & searched for updated.

mostly the suggested updates looked good, but I noticed this on the preview:

opnsense   N/A   25.7   new   OPNsense
opnsense-devel   25.7.r_33   26.1.a_4   upgrade   OPNsense
opnsense-update   25.7.r2   25.7   upgrade   OPNsense

So presumably that would result in both opnsense & opnsense-devel being installed (with the latter being on the next alpha)

Is there an appropriate way around this to get to 25.7? Do I just accept?

It's not a big issue -- I have a snapshot (proxmox) from before the update to 25.7 rc2 so I could revert to that and do a normal update. My config is also backed up automatically to google drive, and it's only a home system. So no big risks.

But it was intriguing to know if there is an appropriate process to follow here? (other than don't)

I'm using PPPOE with dual ipv4/ipv6 stack.
Version 25.1.5_5.

I decided to enable gateway monitoring.

The ipv6 interface shows ok, but oddly ipv4 is just showing as offline (ie red status icon) Update: Specified monitor IP to a known good target (ie 1.1.1.1) which works fine. My ppp gateway is not responding to icmp.

Now I realise something I did.

After the upgrade I noticed I had no flow stats, so I clicked the button to 'repair' the database. I'm guessing that is what caused the sudden demand, and subsequent OOM errors. I vaguely seem to remember having this in the past.

I've had opnsense running very reliably for months. Simple home network - nothing fancy. I tend to update soon after release. I applied the latest minor update yesterday.
I'm running on an n100 (16GB ram) with proxmox (4GB ram)

Today for the first time I hit a memory limit - no obvious change in workload. I don't recollect running close to limits before. Suricata was active, but my traffic volumes are low.

Many opnsense services stopped/were killed. traffic is still flowing normally, but the UI is failing (ie unable to view logs etc), and some components are not running.

pid 64347 (suricata), jid 0, uid 0, was killed: failed to reclaim memory
pid 88258 (unbound), jid 0, uid 59, was killed: failed to reclaim memory
pid 85419 (crowdsec), jid 0, uid 0, was killed: failed to reclaim memory
pid 51196 (python3.11), jid 0, uid 0, was killed: failed to reclaim memory
pid 9872 (python3.11), jid 0, uid 0, was killed: failed to reclaim memory
pid 91615 (crowdsec-firewall-b), jid 0, uid 0, was killed: failed to reclaim memory
pid 28803 (python3.11), jid 0, uid 0, was killed: failed to reclaim memory
pid 53875 (php-cgi), jid 0, uid 0, was killed: failed to reclaim memory
pid 20235 (python3.11), jid 0, uid 0, was killed: failed to reclaim memory
pid 19721 (haproxy), jid 0, uid 80, was killed: failed to reclaim memory
pid 35672 (python3.11), jid 0, uid 0, was killed: failed to reclaim memory
pid 28774 (python3.11), jid 0, uid 0, was killed: failed to reclaim memory
pid 54200 (php-cgi), jid 0, uid 0, was killed: failed to reclaim memory
pid 54650 (php-cgi), jid 0, uid 0, was killed: failed to reclaim memory
pid 54426 (php-cgi), jid 0, uid 0, was killed: failed to reclaim memory
pid 54185 (php-cgi), jid 0, uid 0, was killed: failed to reclaim memory
pid 54065 (php-cgi), jid 0, uid 0, was killed: failed to reclaim memory

For now I'm going to assume it was suricata - so I may disable, or increase vm size. Just wanted to mention it in case anyone else has found a change with the latest build ...

Also worth saying that the data I have from proxmox suggests only 3GB was in use - so could there have been a sudden demand that caused an issue? (since proxmox only polls every ?min?)

Just to say this was merged, and is now available in 25.1.2. Yay!

Just to say this was merged, and is now available in 25.1.2. Yay!