"Recent posts
#1
High availability / Re: Can interface identifiers ...
Last post by am312 - Today at 12:14:49 AMIs this still the only way in 26.1? If the identifiers need to match between FWs in an HA pair then not having a simple way to sync the values in the GUI seems like a miss.
#2
General Discussion / Re: DNS, DoH, DoT, DoQ, DNSCry...
Last post by OPNenthu - April 07, 2026, 11:28:08 PM- I think this is as good a thread as any to request a peer review of a DNS rule matrix and maybe some others will get something from it, too.
- Redirect plain DNS (Do53) to OPNsense on a loopback device
- Block plain DNS escapes and also DoT (tcp/853) outbound
- Block DoQ to standard UDP ports (853, 784) outbound
- Block DoH (tcp/443) and DoH3 (udp/443) to public DNS IP lists ...but try to minimize breakage of HTTP/3 and QUIC for general web traffic!
- Cover a few lesser known but still "standard" or semi-standard ports
- Selectively allow some web clients to Quad9 for all encrypted protocols including their new DoH3/DoQ. These are mainly Androids with "private DNS" turned on and have no plain DNS fallback for when at home.
- https://raw.githubusercontent.com/dibdot/DoH-IP-blocklists/refs/heads/master/doh-ipv4.txt
- https://raw.githubusercontent.com/dibdot/DoH-IP-blocklists/refs/heads/master/doh-ipv6.txt
- https://public-dns.info/nameservers.txt
- https://raw.githubusercontent.com/oneoffdallas/dohservers/master/iplist.txt
- https://raw.githubusercontent.com/oneoffdallas/dohservers/refs/heads/master/ipv6list.txt
- https://raw.githubusercontent.com/jameshas/Public-DoH-Lists/refs/heads/main/lists/doh_ips_plain.txt
I made some updates to try and take DoQ (DNS-over-QUIC) and DoH3 (DNS-over-HTTP/3) into account, but this might have some holes in it that I'd be grateful to get feedback on. Blocking these protocols and all their known/common ports (at a minimum) is becoming tedious.
The goals:
For the resolver IP block lists ("NETS_PUBLIC_DNS") I use these:
For DNS-based block lists in Unbound I use:
- [hagezi] DoH/VPN/TOR/Proxy Bypass (built-in)
- [hagezi] Dynamic DNS blocking (built-in)
- https://dbl.ipfire.org/lists/doh/domains.txt
*Ditto, Unbound supports allowlist overrides to fix the occasional break.
Rules on local interface group:
You cannot view this attachment.
DNAT (using auto "Pass" rule):
You cannot view this attachment.
Ports alias:
You cannot view this attachment.
Are there cracks here for things to slip through, aside from 1) remote services on non-standard ports, and 2) missed resolver IPs in block lists?[/list]
#3
General Discussion / Re: Opnsense and Win 11 in Vir...
Last post by nero355 - April 07, 2026, 10:00:20 PMQuote from: thiagohass on April 07, 2026, 06:28:44 PMHi, how are you?Hi, I am fine. How are you ? ^_^
QuoteWindows 11 is bad at understanding VLAN tagsCould be... I don't know... Never used it and don't feel like ever using it to be honest!
QuoteLinux is much better for doing these tests than Windows.You have got more tools for this kind of stuff in general anyway, so I would never use Windows instead.
#4
General Discussion / Re: DNS, DoH, DoT, DoQ, DNSCry...
Last post by meyergru - April 07, 2026, 09:49:30 PMWhat else would be the intent of HTTPS introspection? As I said, Adblocking (and even kid safety) can be done with DNS and / or IP blocking (that is, iff you also control DNS tightly).
The easiest point to intercept HTTPS traffic is on the endpoint device itself, not by interfering with traffic on any intermediary (to prevent that is essentially a design goal of traffic encryption in the first place).
In my experience, if you want enterprise-level security, you conceptually will have to use a layered approach, because punctual measures will be circumvented sooner or later. If you do not need to protect your users from themselves, you do not need most of that, anyway.
That of course includes 802.1x, DNS redirection (plus blocking of DoT and DoH, which is also hard), and control of HTTPS traffic (preferably on the endpoint), not to forget blocking VPN traffic of any kind.
To do all of that is a major effort which most people - including me - will not take, but it is certainly a nice playing field.
The easiest point to intercept HTTPS traffic is on the endpoint device itself, not by interfering with traffic on any intermediary (to prevent that is essentially a design goal of traffic encryption in the first place).
In my experience, if you want enterprise-level security, you conceptually will have to use a layered approach, because punctual measures will be circumvented sooner or later. If you do not need to protect your users from themselves, you do not need most of that, anyway.
That of course includes 802.1x, DNS redirection (plus blocking of DoT and DoH, which is also hard), and control of HTTPS traffic (preferably on the endpoint), not to forget blocking VPN traffic of any kind.
To do all of that is a major effort which most people - including me - will not take, but it is certainly a nice playing field.
#5
Hardware and Performance / Re: DEC3920 Quick Review
Last post by newsense - April 07, 2026, 09:47:04 PMAnother thing I didn't see mentioned here:
Did you try disabling the auto negotiation on the ports ?
Did you try disabling the auto negotiation on the ports ?
#6
26.1 Series / Re: "Danger. Unexpected error,...
Last post by franco - April 07, 2026, 08:35:17 PM #7
26.1 Series / Re: "Danger. Unexpected error,...
Last post by franco - April 07, 2026, 08:30:54 PMI'll promise to work on an alternative/mitigation for the popup message during firmware upgrades. It's a benign message and fixing it correctly is currently out of our control (as the package manager deletes files on the disk and puts them back which may produce an intermittent fatal error because a class could not be loaded).
Cheers,
Franco
Cheers,
Franco
#8
Tutorials and FAQs / Re: IPv6 Control Plane with FQ...
Last post by OPNenthu - April 07, 2026, 08:11:22 PMI appreciate the feedback...
Hmm, but, as I mentioned it persisted across reboots. I can set it up again to make sure the rules were disabled, but if it happened on bootup then I'm not confident it won't get into that state again on the next router reboot. The messages come early, even before OPNsense is fully booted.
Disabling ECN didn't seem to have a noticeable effect though I didn't try TARGET & INTERVAL. I think I've accepted that FQ_CoDel itself is good enough and not worth the trouble to try and prioritize further (you were right, it's difficult) :)
I'm running with the original setup now (FQ_CoDel data pipes + QFQ control pipes for ICMP only) and for whatever reason the Waveform test is not stalling. I still don't know if the test itself is sometimes faulty or if it was something on my end that got cleared, but I'm keeping an eye on it.
I gave up on trying to get an 'A' on the LibreQoS Houshold test. I had seen a couple F's before, but mostly it's giving me a B. I think @meyergru is seeing 'B' as well, and I should not presume that I can beat him :)
Quote from: Seimus on April 06, 2026, 10:59:53 AMThat error tells you that you are trying to reconfigure a flowset (pipe or queue) while there is an actual traffic uses that flowset (it has an active scheduler).
However, there is an easy workaround to avoid this error. If you make sure that there's no traffic passes through the pipe/queue that you want to reconfigure, then you can reconfigure the pipe/queue without problems.
I would advice to disable the rules, and than try to reapply the settings.
Hmm, but, as I mentioned it persisted across reboots. I can set it up again to make sure the rules were disabled, but if it happened on bootup then I'm not confident it won't get into that state again on the next router reboot. The messages come early, even before OPNsense is fully booted.
Quote from: Seimus on April 06, 2026, 11:18:05 AMThe Scheduler set to QFQ with a Weighted Queue with No MASK, has only the BW Available per the weight ratio per Queue. But here is the main point, its just a Queue without any flow recognition. So basically 1st flow comes in 1st flow gets out & the BW. Once full 50 packets size Queue, anything that will come after TAIL Drops.
For CoDel in Queue you can adjust two parameters TARGET & INTERVAL, the defaults should be enough but maybe you can try to tune them. You can focus on the Upload and set it so CoDel will more aggressively drop or ECN flag packets. Potentially as well try to disable ECN, as instead of flagging first and dropping then ECN supported flows it will drop them right away.
Disabling ECN didn't seem to have a noticeable effect though I didn't try TARGET & INTERVAL. I think I've accepted that FQ_CoDel itself is good enough and not worth the trouble to try and prioritize further (you were right, it's difficult) :)
I'm running with the original setup now (FQ_CoDel data pipes + QFQ control pipes for ICMP only) and for whatever reason the Waveform test is not stalling. I still don't know if the test itself is sometimes faulty or if it was something on my end that got cleared, but I'm keeping an eye on it.
I gave up on trying to get an 'A' on the LibreQoS Houshold test. I had seen a couple F's before, but mostly it's giving me a B. I think @meyergru is seeing 'B' as well, and I should not presume that I can beat him :)
#9
General Discussion / Re: Unable to connect to gatew...
Last post by trekkie500 - April 07, 2026, 08:04:06 PMIt seems I cannot delete this post. I just figured out the issue after hours of messing with it.
I must have done something wrong during setup and used 192.168.4.0 for my OPNSense box which is outside the subnet range and hence Mac was not liking it (even though other devices had no issues with it.. pure luck I guess). After setting gateway to 192.168.4.1 and renewing info from DHCP, everything is working again!
I must have done something wrong during setup and used 192.168.4.0 for my OPNSense box which is outside the subnet range and hence Mac was not liking it (even though other devices had no issues with it.. pure luck I guess). After setting gateway to 192.168.4.1 and renewing info from DHCP, everything is working again!
#10
Hardware and Performance / Re: DEC3920 Quick Review
Last post by dirtyfreebooter - April 07, 2026, 07:14:13 PMhttps://www.reddit.com/r/opnsense/comments/1sesnc1/opnsense_randomly_loses_lan_wan_connection_with/
lol, i226 is such hot garbage, and even more so in freebsd
lol, i226 is such hot garbage, and even more so in freebsd
