Messages

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!

* You could inspect network traffic with wireshark or similar?
* Any firewall rules blocking traffic?
* Is vlan configuration correct?
* Any managed switches involved?

See https://forum.opnsense.org/index.php?topic=45521.0 - I'm suggesting a PR

I've made a PR for this - feedback welcome

https://github.com/opnsense/core/pull/8275

I see this has been asked a few times.

It seems as if specifying this in /var/unbound/etc/dot.conf

Code Select Expand

forward-first: yes
would help

My current file is

Code Select Expand

# Forward zones

# Forward zones over TLS
server:
  tls-cert-bundle: /usr/local/etc/ssl/cert.pem

forward-zone:
  name: "."
  forward-tls-upstream: yes
  forward-addr: 2620:fe::9@853#dns.quad9.net
  forward-addr: 149.112.112.112@853#dns.quad9.net
  forward-addr: 9.9.9.9@853#dns.quad9.net
  forward-addr: 2620:fe::fe@853#dns.quad9.net
This at least would fallback to recursive resolution if required (albeit siliently)

I wonder also if I have too many forwarders here - would unbound just try 1 or all. I suspect all might fail at once.

Still, this could be a useful opnsense enhancement. I previously did a PR to add another parm for unbound (now merged), so may see if I can suggest a change for this?