Recent posts

#1
25.7, 25.10 Series / Re: Captive Portal slows down ...
Last post by HappyUserB - Today at 12:35:25 AM
After updating to 25.7.10 the issue is back again - so it is definitely related to .10 .
#2
25.7, 25.10 Series / Re: DNSmasq and Unbound Peacef...
Last post by vimage22 - December 27, 2025, 11:23:56 PM
QuoteDNSSEC is already enforced by Quad9
Maybe, but you are not addressing the technical details of my response. Without DSNSEC, you have no guarantee the the DNS answer is from Quad9.

BTW, I am running a performance test against DSNSEC fully enabled or disabled. Granted, using cloudflare, as opposed to Quad9. I want to look at a 24 hr period looking at:
Services: Unbound DNS: Statistics:
It will show:
Recursion time (average):
Recursion time (median):
Hoping this will show any performance issue.

#3
German - Deutsch / Re: KEA DHCP4 - Keine einstell...
Last post by paperware - December 27, 2025, 11:21:42 PM
Moechte mich bei euch beiden fuer die Hilfe bedanken!
Das hatte ich dort nicht vermutet.
#4
25.7, 25.10 Series / Re: DNSmasq and Unbound Peacef...
Last post by DEC740airp414user - December 27, 2025, 10:38:36 PM
DNSSEC is already enforced by Quad9, and enabling DNSSEC at the forwarder level can cause false DNSSEC failures.
#5
25.7, 25.10 Series / Re: DNSmasq and Unbound Peacef...
Last post by DEC740airp414user - December 27, 2025, 10:38:08 PM
Quote from: vimage22 on December 27, 2025, 04:56:24 PMGreat. And you needed to add a forward from unbound to dnsmasq, right? As for DNSEC, I have been reading up on this:
https://blog.cloudflare.com/dns-encryption-explained/
https://www.cloudflare.com/learning/dns/dns-security/
https://security.stackexchange.com/questions/239698/does-cloudflares-dns-over-tls-dot-implement-dnssec-too

I think DSNSEC should be enabled. It is a client/server situation.
"DNSSEC allows clients to verify the integrity of the returned DNS answer"
It seems like a provider, like cloudflare, will use DNSSEC flags and the client, like OPNsense, will process them. If you turn off DNSSEC, then you can no longer trust the answer you get was from your provider.

In summary:
DoT: Encrypts your DNS query.
DNSSEC: cryptographically verifies DNSSEC-signed records. (only within unbound)

Therefore, these are two different functions that work together to increase DNS security. Quite fascinating.

DNSSEC is already enforced by Quad9, and enabling DNSSEC at the forwarder level can cause false DNSSEC failures.



#6
Hardware and Performance / Re: Dec740 connected to a USW-...
Last post by DEC740airp414user - December 27, 2025, 10:34:59 PM
Ordered and the rj45 spf modules in the opnsense store.

Finally got the sp+ setup as my primary lan though the console.
Dec740 port 0- 9 the spf port on the pro ui switch.  It shows connected at full duplex 10gb

Now when I activate wireguard tunnels, any device going over the wireguard tunnel can't access the router gui.   If I create a rule to have that device go over the wan I can access the gui?    I can't believe this is my only issue and I've spent hours on trying to fix this.  Disable routes is checked on each tunnel.  Everything is setup exactly as my previous appliance.  But I am struggling to figure this out.

It is setup to listen on all interfaces so that is not the issue

Any suggestions are welcome
#7
Virtual private networks / Re: os-softether-devel (miscon...
Last post by mimugmail - December 27, 2025, 09:52:06 PM
I added it today on my repo.
#8
25.7, 25.10 Series / Re: Captive Portal slows down ...
Last post by HappyUserB - December 27, 2025, 07:53:11 PM
25.7.9 is working flawlessly. So it seems to be related to .10 . Please let me know if I can somehow help you by reproducing this issue and thank you for your support.
#9
General Discussion / Re: ECS and DNSSEC Setup
Last post by vimage22 - December 27, 2025, 06:31:53 PM
I do not think it is too much of an issue with DNSSEC off because it is hard to imagine something trying to interfere with a DoT encrypted request to Quad9. And I can picture Quad9 uses DNSSEC when making a query to an upstream authoritative DNS server.

And @newsense, is there a way to see queries that are not validated from within unbound?

However, just for my own knowledge, I am interested in taking this further.
Using cloudflare, with "Enable DNSSEC Support" = true, for many years, there have not been any issues.
Under Unbound DNS: Advanced the "Harden DNSSEC Data" is currently false. If this is changed to true, and the chain of DNSKEY is broken, at any point in the chain of DNS servers, then the answer part of the query will fail because OPNsense cannot verify the response. Which equals 'false bogus' in Quad9's language. And by 'chain' I mean:
unbound --> cloudflare (or Quad9) --> not resolved in their cache --> some authoritative DNS server --> answer returned to cloudflare (or Quad9)--> answer returned to unbound where DNSKEY is verified.
It seems the risk on this is that any authoritative server that is queried from cloudflare (or Quad9) that does not have DNSSEC configured will result in a failed answer. This is more discussion all the way back from 2017:
https://github.com/opnsense/core/issues/1962

To check performance, this should work (pwsh)
(Measure-Command { Resolve-DnsName apple.com }).TotalMilliseconds
But the cache needs to be cleared.
Windows: ipconfig /flushdns
unbound: Flush DNS Cache during reload = true
But is there a command to clear unbound, other than restarting the service?
#10
General Discussion / Re: My pf ruleset causing clie...
Last post by Patrick M. Hausen - December 27, 2025, 06:19:45 PM
It's the standard behaviour for IP routing. Specifically in IP there is no "connection" anywhere. Routing decisions are made per packet based on destination address only.

Also the information on which interface some packet arrived is not kept, anywhere. So the reply can never be based on "but the request came in on this and that interface - the reply must go out the same one!" No. Does not exist and never did. IP is about packet switching as opposed to curcuit switching.

I have been fighting uphill battles with folks who just would not accept the world does not work how they think it does over on the TrueNAS forum.

Yes, one can implement systems that work like that. Of course. But it's not how any Unix/Linux based implementation works by default. And it would be proprietary, there's no standard mandating anything but routing based on destination address.