"Recent posts
#11
Hardware and Performance / Re: TOPTON Mini PC Running OPN...
Last post by Nullman - May 12, 2026, 09:58:36 PMQuote from: BrandyWine on May 12, 2026, 05:15:41 AMSet It and Forget It ?Yes. I dont want to open my device just so i can remove dust carpets. I dont want to lubricate or replace failing/dead fans. I dont want to get my hands dirty with thermal paste.
Quote from: BrandyWine on May 12, 2026, 05:15:41 AMThat's like speaking for every end-user who plugs anything in and wants it to work 100% w/o ever having an issue. Never gonna happen.Its already happening for me, and im happy.
Quote from: BrandyWine on May 12, 2026, 05:15:41 AMPlus, with OPNsense you'll be updating frequently, no real way around that if you wish to maintain security posture.I have no problem with that. However, my set it and forget it statement was referring to hardware, not the software.
#12
26.1, 26,4 Series / Re: 26.1.8 breaks Firewall Rul...
Last post by meyergru - May 12, 2026, 09:56:34 PMYes, I see that, too.
#13
26.1, 26,4 Series / "Outbound" NAT is broken after...
Last post by jle - May 12, 2026, 09:54:26 PMGood evening,
In my setup, "Outbound" NAT is set as "Automatic outbound NAT rule generation". I think that's the default setting.
Therefore all packets from private LANs are supposed to be SNAT'ed with the appliance's WAN facing IP address.
However after a restart of my OPNsense VM, that outbound NAT is not applied. Packets from internal devices (all of them behind a Wireguard tunnel) leave the OPNsense VM's WAN facing interface with their private IP address as the packet source.
Clicking (without any change to the configuration!) the "Apply" button in Firewall > Rules [new], or in Firewall > NAT > Outbound, restores the expected behaviour: packets from internal LANs are SNAT'ed.
That behavior is seen with 26.1.7 and 26.1.8 and is reproducible after each restart.
Could this be a misconfiguration, or would that be a bug instead ?
Thank you for your feedback.
In my setup, "Outbound" NAT is set as "Automatic outbound NAT rule generation". I think that's the default setting.
Therefore all packets from private LANs are supposed to be SNAT'ed with the appliance's WAN facing IP address.
However after a restart of my OPNsense VM, that outbound NAT is not applied. Packets from internal devices (all of them behind a Wireguard tunnel) leave the OPNsense VM's WAN facing interface with their private IP address as the packet source.
Clicking (without any change to the configuration!) the "Apply" button in Firewall > Rules [new], or in Firewall > NAT > Outbound, restores the expected behaviour: packets from internal LANs are SNAT'ed.
That behavior is seen with 26.1.7 and 26.1.8 and is reproducible after each restart.
Could this be a misconfiguration, or would that be a bug instead ?
Thank you for your feedback.
#14
26.1, 26,4 Series / Re: 26.1.8 breaks Firewall Rul...
Last post by Patrick M. Hausen - May 12, 2026, 09:51:14 PMHere for an interface with 6 defined rules the UI displays these 6 plus the 2 floating rules that also apply to this interface. The number shown in the selector is 6, the number of rules displayed is 8.
Works that way both without and with the patch.
Same for interface groups. The floating rules are always added to the display but do not change the number in the little circle in the selector.
See screenshots - 1 vs. 3 and 5 vs. 7. Makes sense to me - if that is intended and consistent.
Works that way both without and with the patch.
Same for interface groups. The floating rules are always added to the display but do not change the number in the little circle in the selector.
See screenshots - 1 vs. 3 and 5 vs. 7. Makes sense to me - if that is intended and consistent.
#15
Q-Feeds (Threat intelligence) / Invalid license after update t...
Last post by vpx23 - May 12, 2026, 09:51:07 PMI get this error in the dashboard after the update to 26.1.8.
You cannot view this attachment.
A second reboot also didn't resolve it.
I'll wait till the next sync in the TIP dashboard and see if that resolves it.
The latest update of Q-Feeds (1.6) states: "Feature: Add alert when license expired or invalid".
But my API key is listed to never expire so it could only be a bug.
Either that or the license "Community - Self-Provisioned" expired for everyone and we have to create a new API key?
You cannot view this attachment.
A second reboot also didn't resolve it.
I'll wait till the next sync in the TIP dashboard and see if that resolves it.
The latest update of Q-Feeds (1.6) states: "Feature: Add alert when license expired or invalid".
But my API key is listed to never expire so it could only be a bug.
Either that or the license "Community - Self-Provisioned" expired for everyone and we have to create a new API key?
#16
Hardware and Performance / Re: quad interface fierwall PC...
Last post by Nullman - May 12, 2026, 09:50:10 PMQuote from: nero355 on May 12, 2026, 06:49:24 PMThat's something to dig into then when considering one of their products. Thnx! :)You are welcome.
#17
26.1, 26,4 Series / Re: 26.1.8 breaks Firewall Rul...
Last post by meyergru - May 12, 2026, 09:48:44 PMYes for the floating rules: 10/10 displayed now. No for the interface group with 16 rules, still 22 in the list when I select it. Also no for one of my interfaces with 1 rules, where 3 are listed.
As it turns out, the rules with "any" are also listed when any specific interface is selected, which can be argued as expected.... this probably explains the higher number for the other categories.
As it turns out, the rules with "any" are also listed when any specific interface is selected, which can be argued as expected.... this probably explains the higher number for the other categories.
#18
26.1, 26,4 Series / Re: Autoscroll in the update l...
Last post by vpx23 - May 12, 2026, 09:41:03 PMAdblocker and CanvasBlocker are off, I suspect something in LibreWolf causes the bug. Does anybody using LibreWolf on Windows have the same bug?
#19
26.1, 26,4 Series / Re: 26.1.8 breaks Firewall Rul...
Last post by franco - May 12, 2026, 09:37:49 PM #20
Tutorials and FAQs / Re: HOWTO - Redirect all DNS R...
Last post by rumshot - May 12, 2026, 09:30:58 PMHi everyone,
I'm trying to enforce DNS redirection/blocking on the latest OPNsense version for a VLAN network, but I'm seeing behavior that I don't fully understand and would appreciate some clarification from experienced users.
My setup:
* VLAN interface: `VLAN50Users`
* Firewall IP / local DNS resolver: `192.168.50.1`
* Goal:
* Force all clients to use the local Unbound resolver
* Prevent clients from using external DNS servers like:
* `1.1.1.1`
* `8.8.8.8`
* `2.2.2.2`
What I configured:
1. NAT Port Forward rule:
* Interface: VLAN50Users
* Protocol: TCP/UDP
* Source: VLAN50Users net
* Destination: any
* Destination Port: 53
* Redirect target IP: 192.168.50.1
* Redirect target port: 53
2. Firewall rules on VLAN50:
* Pass DNS to `This Firewall`
* Block DNS to external destinations
* General allow rule below them
States were reset after every change.
However, packet captures still show direct DNS traffic going to public resolvers:
Example captures:
```text id="8x3y4q"
192.168.50.214 -> 1.1.1.1:53
192.168.50.214 -> 8.8.8.8:53
192.168.50.214 -> 2.2.2.2:53
```
Even more confusing:
* `dig @1.1.1.1 google.com`
* `dig @2.2.2.2 aljazeera.com`
still succeed from the client (macbook terminal) (just in case has something special with mac).
I also noticed:
* some DNS requests *are* going to `192.168.50.1`
* but other requests still leave directly to public DNS servers
Additional notes:
* Client is connected via Ethernet (not Wi-Fi)
* Rules are on the VLAN interface tab (not floating)
* Direction is IN
* Protocol is TCP/UDP
* Tested with macOS terminal using `dig`
Questions:
1. Is packet capture showing packets before NAT/filter processing?
2. Is there something different in newer OPNsense versions regarding DNS interception?
3. Is the recommended modern approach:
* NAT redirect only?
* block only?
* or both together?
4. Is DNS over TLS / HTTPS interfering here?
5. Is there a known requirement for floating rules or reply-to disabling in this scenario?
I found this old tutorial:
https://forum.opnsense.org/index.php?topic=9245.0
but behavior on current versions seems different.
Any clarification on the correct/recommended way to fully enforce local DNS on current OPNsense would be greatly appreciated.
Thanks!
I'm trying to enforce DNS redirection/blocking on the latest OPNsense version for a VLAN network, but I'm seeing behavior that I don't fully understand and would appreciate some clarification from experienced users.
My setup:
* VLAN interface: `VLAN50Users`
* Firewall IP / local DNS resolver: `192.168.50.1`
* Goal:
* Force all clients to use the local Unbound resolver
* Prevent clients from using external DNS servers like:
* `1.1.1.1`
* `8.8.8.8`
* `2.2.2.2`
What I configured:
1. NAT Port Forward rule:
* Interface: VLAN50Users
* Protocol: TCP/UDP
* Source: VLAN50Users net
* Destination: any
* Destination Port: 53
* Redirect target IP: 192.168.50.1
* Redirect target port: 53
2. Firewall rules on VLAN50:
* Pass DNS to `This Firewall`
* Block DNS to external destinations
* General allow rule below them
States were reset after every change.
However, packet captures still show direct DNS traffic going to public resolvers:
Example captures:
```text id="8x3y4q"
192.168.50.214 -> 1.1.1.1:53
192.168.50.214 -> 8.8.8.8:53
192.168.50.214 -> 2.2.2.2:53
```
Even more confusing:
* `dig @1.1.1.1 google.com`
* `dig @2.2.2.2 aljazeera.com`
still succeed from the client (macbook terminal) (just in case has something special with mac).
I also noticed:
* some DNS requests *are* going to `192.168.50.1`
* but other requests still leave directly to public DNS servers
Additional notes:
* Client is connected via Ethernet (not Wi-Fi)
* Rules are on the VLAN interface tab (not floating)
* Direction is IN
* Protocol is TCP/UDP
* Tested with macOS terminal using `dig`
Questions:
1. Is packet capture showing packets before NAT/filter processing?
2. Is there something different in newer OPNsense versions regarding DNS interception?
3. Is the recommended modern approach:
* NAT redirect only?
* block only?
* or both together?
4. Is DNS over TLS / HTTPS interfering here?
5. Is there a known requirement for floating rules or reply-to disabling in this scenario?
I found this old tutorial:
https://forum.opnsense.org/index.php?topic=9245.0
but behavior on current versions seems different.
Any clarification on the correct/recommended way to fully enforce local DNS on current OPNsense would be greatly appreciated.
Thanks!
