HOWTO - Redirect all DNS Requests to Opnsense

[SenseX]

@meyergru

Yes, with the rules I've been using it seems to work well. I also have a few additional DNS rules in place to tighten things up a bit.

I also redirect DoT traffic on port 853, which helps prevent devices from bypassing the local resolver using encrypted DNS directly to external providers.

Additionally, I've been experimenting with blocking DoH endpoints, starting with things like Google DNS, to stop clients from using DNS-over-HTTPS to bypass local policies. So far this setup seems to be working well in my tests.

[Gilgamesh]

I also redirect DoT traffic on port 853

But what is the point to redirect (instead of block) if such queries will not be served due to certificate not matching.

[yourfriendarmando]

I just block outgoing access to port 853. I have it in an alias full of ports clients have no business accessing.
The alias is used in a Floating rule to block local nets from accessing ports to !local nets

[hushcoden]

Sorry if it's a dumb question, but in the forward rule, --> destination, is it !LAN net or !LAN address ?

Could someone explain to me what the difference is?

Also, as for the source, why is it 'any' and not LAN net if I want to 'control' the clients on my LAN network?

[nero355]

Sorry if it's a dumb question, but in the forward rule, --> destination, is it !LAN net or !LAN address ?

Could someone explain to me what the difference is?

LAN Net = Your network's subnet so let's say 192.168.1.0/24
LAN Address = The Gateway IP Address so let's say 192.168.1.1

Also, as for the source, why is it 'any' and not LAN net if I want to 'control' the clients on my LAN network?

It doesn't really matter, but you could say 'Any' does in theory catch more since it's ANYTHING instead of something SPECIFIC :)

[hushcoden]

LAN Net = Your network's subnet so let's say 192.168.1.0/24
LAN Address = The Gateway IP Address so let's say 192.168.1.1

Yes, but which one is more accurate (and if possible, also why)?

[nero355]

LAN Net = Your network's subnet so let's say 192.168.1.0/24
LAN Address = The Gateway IP Address so let's say 192.168.1.1

Yes, but which one is more accurate (and if possible, also why)?

Between those two ?!

Well your Gateway does not create the traffic so you have to choose your Network Subnet anyway : 192.168.1.0/24


Simply think about how your traffic flows and what the rule does and you got your answer right there immediately! :)

[hushcoden]

On post #128, you stated "You only need to catch DNS traffic NOT going to your DNS Server IP (in this case OPNsense) and not ALL DNS traffic".

Now, in my case 192.168.0.1 is the LAN address of my OPNsense that is also the IP address of the DNS server --> I can either use !192.168.0.1 or !LAN address, is that right?

Let's say that "networking concepts go over my head faster than gigabit speeds" :-)

[nero355]

I can either use !192.168.0.1 or !LAN address, is that right?

Yes! :)

[rumshot]

Hi 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!

[rumshot]

Hi Folks,

Actually maybe its working. Just need to know when capturing packets from opnsense, if it capture before NAT, if its the case, then probably its working.
Im confused now. lol

[nero355]

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).

After applying the correct DNAT/SNAT Rules and related Firewall Rules that should work indeed, but instead of the queries going to those Public DNS Servers the queries should show up in the Query Log of your Private DNS Server ;)

I also noticed:

* some DNS requests *are* going to `192.168.50.1`
* but other requests still leave directly to public DNS servers

That's not good...

Try these settings : https://forum.opnsense.org/index.php?msg=259581
And if you have questions let me know :)