Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - S1ardust

#1
Dear Franco,

thank you for pointing me into the right direction.
Knowing that the actual DNS cache remains intact is a huge relief, as that was my main concern.
#2
Hi everyone,

Quote from: franco on September 20, 2026, 08:55:05 PMUnbound hasn't lost its cache on restart by default for many years...

quick update on this. I tested franco's hint via SSH to check if the cache is actually wiped.
Here is what I did BEFORE triggering the adapter disconnect:

myusername@myhostname:~ # drill @127.0.0.1 www.wikipedia.org
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 242
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; www.wikipedia.org.   IN      A

;; ANSWER SECTION:
www.wikipedia.org.      86400   IN      CNAME   dyna.wikimedia.org.
dyna.wikimedia.org.     169     IN      A       185.15.59.224

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 166 msec
;; SERVER: 127.0.0.1
;; WHEN: Mon Sep 21 08:31:19 2026
;; MSG SIZE  rcvd: 80

myusername@myhostname:~ # unbound-control -c /var/unbound/unbound.conf dump_cache | grep "www.wikipedia.org"
www.wikipedia.org.      86373   IN      CNAME   dyna.wikimedia.org.
msg www.wikipedia.org. IN A 33152 1 142 3 2 0 0 -1
www.wikipedia.org. IN CNAME 0

Then I ran Disable-NetAdapter / Enable-NetAdapter on my Windows client.
After the link came back up and Unbound restarted, I checked the cache again:

myusername@myhostname:~ # unbound-control -c /var/unbound/unbound.conf dump_cache | grep "www.wikipedia.org"
www.wikipedia.org.      86171   IN      CNAME   dyna.wikimedia.org.

Result:
The entry is still there, and the TTL just counted down normally. It seems franco is right – the actual DNS cache seems to survive the link-reactive restart.

Apparently, only the web GUI counters under "Services: Unbound DNS: Statistics" get fully reset to zero during this process.

Is my logic/conclusion here correct, or am I missing something?
If it's just the statistics being flushed, I can probably live with that.

Thanks for the help!
#3
Quote from: Patrick M. Hausen on September 19, 2026, 12:05:13 PMUse a switch?

Thanks for the suggestion! Unfortunately, using a switch is not an option in my setup, so I need to find a solution that works without one.

Is there perhaps another way to prevent the LAN link state change from triggering the Unbound restart?
#4
Hi everyone,

I am running OPNsense on my network for some weeks now and I am facing an annoying issue where Unbound DNS performs a hard restart (losing its entire cache and resetting uptime to 0) every time my Windows 11 client disconnects from the LAN.

For reasons, I programmatically disable the network adapter on the Windows 11 client multiple times a day via Disable-NetAdapter.

The Phenomenon & Root Cause
Whenever the client disconnects, the virtualized OPNsense (running on Hyper-V) registers a physical link-loss on the LAN interface (hn1). The subsequent link-up triggers the system script /usr/local/etc/rc.newwanip, which forces a global Unbound restart.

Log output
From "System -> Log Files -> General" (or via clog /var/log/system.log):

hn1: link state changed to DOWN  (When disabling the client adapter)
hn1: link state changed to UP    (When re-enabling the client adapter)
[... followed by rc.newwanip triggering the Unbound restart ...]

Network Topology
You cannot view this attachment.

What I Have Already Tried (Without Success)

To prevent the Unbound restart on link-up, I have already tested the following:

  • Tested the setting "Flush DNS cache during reload"
  • Prevent interface removal: Activated under "Interfaces -> [LAN]".
  • Unbound Network Interfaces: Bound to "All" instead of specific interfaces.
  • System Tunables: Set com.opnsense.disable_interface_cycle = 1.
  • ...


Any advice or pointers would be highly appreciated!

Thank you
#5
Hello,

Quote from: meyergru on August 16, 2026, 11:49:48 AMNo problem here, neither with opening the site in Edge nor with the given command - it returns 200.

Thank you for checking! 🙏🏻

I found an issue on my network/gateway/router.
It was not an OPNsense problem.

Thank you
#6
Hello,

I am new to OPNsense and  I'm experiencing a strange HTTPS/TLS issue. (Version: 26.7.2_2)
On my Windows 11 Client behind OPNsense, I was missing thumbnails on the YouTube website.

When I try to open the URL "https://i.ytimg.com/vi/FLH1aARTpMg/hq720.jpg" i get the error "ERR_SSL_PROTOCOL_ERROR" in Edge-Browser:

You cannot view this attachment.

After a lot of troubleshooting, with some help from ChatGPT, I was able to reproduce the issue directly from the OPNsense shell.

Most HTTPS traffic works normally. For example:

curl -4 -sS -o /dev/null -w '%{http_code}\n' \
https://www.google.com

returns:
200


However, connecting to the YouTube image server directly from OPNsense fails:

curl -4 -sS -o /dev/null -w '%{http_code}\n' \
https://i.ytimg.com/vi/FLH1aARTpMg/hq720.jpg

results in:

curl: (35) TLS connect error:
error:0A00010B:SSL routines::wrong version number
000



DNS resolution works correctly, and the same i.ytimg.com IP is reachable. The URL also works normally when the client connects directly through the router instead of OPNsense.

Has anyone seen a similar TLS issue with OPNsense 26.7.x / FreeBSD 15.x?

Any hints on where to investigate further would be greatly appreciated.

EDIT: No Plug-Ins, No relevant Firewall rules, fresh Install

Thank you very much for your support!