HOWTO - Redirect all DNS Requests to Opnsense

[junantaiso]

It works now for me, I'm not sure I remember what I changed.

I have a NAT rule that redirects TCP/UDP 53 to 127.0.0.1 and one for ::1 and now the DNS lookups are corrected redirected and correctly answered, with source IP "faked".

But you use the Adguard on your OPNsense firewall or on a dedicated server on your lan network?

[CJ]

Is there a reason to do a redirection rather than just hand out DNS via DHCP and block outbound connections on 53 and 853?  That's my preference instead of doing a redirect as a redirect can lead to some fun troubleshooting.

[tiermutter]

There may be hardcoded or "misconfigured" devices where a block will lead to disfunction. I also don't want to configure every device of eg family members, a new device should simply work.

[CJ]

There may be hardcoded or "misconfigured" devices where a block will lead to disfunction. I also don't want to configure every device of eg family members, a new device should simply work.

I've never had to configure anyones device.  Pretty much everything defaults to DHCP and picks up the provided DNS.  Some things like Roku have hardcoded additional DNS servers but it still pulls the DNS from DHCP.  But they all just work.

If we were talking about NTP, I'd agree with you.  Apparently nothing respects DHCP NTP out of the box.

[9axqe]

Well, the reasoning is:

• if you are blocking port 53 outbound, it means you expect some devices to attempt to use external DNS.
• If a device is using and external DNS, it's either malicious or misconfigured.
• ergo, you are already planning for misconfigured devices
• Hence redirecting is the logical thing to do.

Additionally, I suspect some devices such as smart TVs to fallback to DNS over HTTPS/TLS/QUIC if they notice DNS to outside is being blocked. But I have never observed it, it's pure conjecture.

[CJ]

Well, the reasoning is:

• if you are blocking port 53 outbound, it means you expect some devices to attempt to use external DNS.
• If a device is using and external DNS, it's either malicious or misconfigured.
• ergo, you are already planning for misconfigured devices
• Hence redirecting is the logical thing to do.

Being prepared for something attempting to use external DNS is different from expecting it.  So far the main offenders I've run into are IOT devices that have something like Google DNS hardcoded in addition to what is provided by DHCP.  My assumption is to reduce support load when used on misconfigured consumer networks.

IME, redirections cause problems troubleshooting when people forget or don't realize that a redirection is in place.  Since every device accepts the DNS provided by DHCP, I'd rather just block 53 and 853 so that I can easily tell if there's a problem and quickly handle it.

Additionally, I suspect some devices such as smart TVs to fallback to DNS over HTTPS/TLS/QUIC if they notice DNS to outside is being blocked. But I have never observed it, it's pure conjecture.

I've not run into this personally.  Firefox defaults to DoH but devices with blocked DNS just attempt more connections instead of switching to an alternative method. 

[donkeyhero]

The original steps in the original guide are outdated at this point and do not work in OpnSense version 24.1.6 (Released on April 18, 2024).

There are a few key issues here which prevent it from working on my system.

1)

Under NAT -> Port Forward -> Create Rule:

Filter Rule Association: Pass

If you try to use Add associated filter rule or Add unassociated filter rule, the filter rules added to your Interface will FAIL because if you look at the rule created, it does not add in the associated Destination/Invert

• from the NAT Rule into the Firewall Rule. You can check by watching the Live Firewall Logs and seeing that the Traffic instead of doing the redirect (rdr) is actually doing the Firewall Rule associated with the NAT Rule.
  
  For me, I named that to be "DNS 53" for the DNS Port 53 forwarding. This will execute when the Conditions of the Firewall Rule for the Interface is met which is the IP or DEST of that rule and if you look at that DEST/IP, it does NOT have the "!" in front of it to be triggered by !DEST and it is actually being triggered by conditions where it is DEST + the desired PORT (DNS)! If you create but not apply or enable a NOT/Destination Invert
• rule under the same interface, you will see that for the Destination column, it will actually show "!" in front of the DEST entered into the Rule and it will also execute when that condition is met.
  
  2) Expansion on #1 re: Filter Rule Association of Associated/Unassociated Rules simply not working. The description says you can edit the Unassociated Rule manually after the NAT rule changes but for both Associated and Unassociated, the respective rule created under the Interface CANNOT be edited at all under any circumstance. This was mentioned here on September 28, 2021: https://forum.opnsense.org/index.php?topic=24905.msg119669#msg119669 where the OP points to the Solution being: https://forum.opnsense.org/index.php?topic=6320.msg26844#msg26844.
  
  Basically, use Pass as the Filter Rule Association and the NAT Rule will execute just fine.
  
  3) You have to check the Live Log or just Firewall Logs in general to see if this is working or not. I constantly tested against this website: https://www.dnsleaktest.com/ after manually setting a Static IP on my smart phone while watching the Firewall Live Log on OpnSense. The moment it started to work correctly, all the DNS other than the local DNS server being used got redirected to the local DNS server and resolved via the DNS servers that I set in AdGuard (QUIC: Adguard, DoH: Quad9).
  
  In the Live Log I'm watching for:
  Actions -> Contains -> rdr
  
  Once it starts to work correctly, that Live Log will start to show entries with the Label "rdr rule" and the respective DEST DNS that the various sources that tried to reach them and the resolution should be via the Local DNS Server specified in the NAT Rule.
  
  Hope this clears up some confusion for individuals who are attempting to do this in May, 2024 and beyond.

[rickygm]

Hi, I have followed this post and created almost all the rules to redirect my DNS traffic to a server with dnsmasq and it does not work for me, I am using the latest version of opnsense, I have adguard+unbound dns working together.

What I want to do is that my vlans can only use two DNS, the opnsense one and my server with dnsmasq, but I can't also pass the traffic to my dnsmasq

i have 3 vlan:

192.168.11.0/24 ## servers
192.168.13.0/24 ## users clients
192.168.14.0/24 ## wifi guest.

dnsmasq is  192.168.11.4

[SVMartin80]

I'm trying to set this up too, but need some help.

My setup is as follows:

server vlan running a pihole and unbound (on the opnsense box)

management vlan running all management interfaces, but also my desktop

The pihole uses unbound as the upstream dns server. I have created a firewall rule to allow hosts from the management vlan to connect to pihole on port 53.

When I add the port forward, a "nslookup www.tweakers.net 8.8.8.8" on the desktop does show up in the firewall logs as a redirect, and shows up in the pihole as being succesfully processed. Nevertheless, nslookup gives a connection error / timeout.

Doing a nslookup without any ip-address, just returns the proper response immediately.

As noted earlier in this discussion, I believe this might be because nslookup expects a response from 8.8.8.8, but gets it from the pihole. I tried to add an outbound nat rule, but have not been successful.

Anyone who could get me to the right direction? Help is greatly appreciated!

[Baender]

The whole topic is just weird. I read more than ten tutorials, and every tutorial tells me to add a Port Forward NAT, check invert and add 127.0.0.1 as destination.

However, that is not the point. If you select "Add associated filter rule" for NAT, it adds a rule to allow DNS traffic to destination 127.0.0.1. The problem is, that if you look into the live log, the destination for the DNS request is the gateway of the interface. For my LAN for instance 192.168.1.1 and not 127.0.0.1. So the DNS request of my client is blocked and not passed by the rule.

Every tutorial tells me, that I can create a firewall group, add a Port Forward with that group and get an associated filter rule. However, for every interface I get a rule with 127.0.0.1 as the destination, what is pointless. So I end up to create a NAT with "Filter rule association" "Pass" and add one rule for every interface by hand, to allow DNS to the gateway. Is that really the idea?

[Patrick M. Hausen]

In my opinion "Pass" is the only reasonable setting for "Filter rule association". You can set/filter source addresses right in the NAT rule - why an additional firewall rule at all? If you want to forward, you probably want to pass, don't you?

But that's just me - probably there's a use case for a split port forward and firewall rule. Mine are all set to "Pass".

[Baender]

How would you do that, if you would have five interfaces, that all need a Port Forward? Would you create five NAT's? If you create a Port Forward for one interface, then I have to agree with you. That you can set/filter the source addresses.

[Patrick M. Hausen]

If you have five interfaces that need a port forward, what is the problem with creating five NAT > Port Forward rules?

You can also create an interface group and use "This Firewall" as the destination address if the internal redirect address is the same for all.

[Baender]

My problem is, that I have no chance to create one rule in a way (like in a group, floating), where I can just allow connections to the gateway of each interface on port 53. The option, to enter 127.0.0.1 as the destination, will not work, as every client would contact the DNS server (firewalls ubound) via the gateway of the specific interface. That is the reason why I talk about firewall rules. I need to allow DNS in the first place on every interface. No matter if I forward the dns to ubound or not. Maybe that is the problem..

[Patrick M. Hausen]

Interface: XY (let's pick LAN)
Protocol: TCP/UDP
Source: any
Destination: any
Destination port: 53
Redirect address: 127.0.0.1
Firewall rule associaton: Pass

Puzzled why that is not working for you?

Your OPNsense is the default gateway in every single connected network, isn't it?