How to Redirect Unencrypted DNS Requests to Your Local DNS Resolver in OPNsense


Photo by geralt from Pixabay

Table of Contents

When I first set up my home network using my OPNsense router and was learning firewall rules, I took the approach of allowing only the Unbound DNS service on OPNsense to be accessed and blocking access to all other DNS servers. This simplistic approach works well enough since any rogue access to external DNS servers are simply blocked. Only the DNS resolver on the local network is allowed (unless the DNS requests are encrypted, of course – see note below).

Later, I added 2 Raspberry Pi’s with Pi-hole installed to provide DNS blocking. I changed the DHCP settings of my local networks to use the IP addresses of the Pi-hole DNS servers rather than the default Unbound DNS in OPNsense so that all of my clients would go through Pi-hole. I had the Pi-holes use the Unbound DNS on my OPNsense router as the upstream DNS resolver in order to have local hostname resolution. The same strategy of only allowing access to the Pi-hole DNS servers on my local network and blocking all other DNS servers works without issue. Every DNS request had to go through Pi-hole or it would be blocked.

I have read that some devices (like Smart TVs) will attempt to use Google’s DNS servers or some other public DNS servers even though the devices should be automatically configured to use the local DNS server provided by the DHCP service (perhaps they do this to attempt to bypass ad blockers and/or to gather valuable data on the DNS requests made by your device). For those devices that only use alternative/hard-coded DNS servers, using the approach described above simply will not work if the device refuses to use the configured DNS servers. I personally have not yet experienced this issue with any of my devices.

Fortunately, there is another approach that can be taken. All DNS requests to alternate/external servers can be simply redirected to your local DNS server(s). This is not only useful to ensure proper functionality of those devices on your network, but it also allows you to apply DNS blocking/filtering to those DNS requests. The DNS redirect allows you to easily monitor the DNS requests that you otherwise would not have seen had the requests been blocked by a firewall rule.

I must mention that there are ways around DNS redirection – if the DNS requests are encrypted, they cannot blocked using this technique. On the page I read about Smart TVs using hard-coded DNS servers, it mentions that you could block access to all commonly used public DNS servers except for the ones being used by the Pi-hole device. Since it describes the process using pfSense, you should be able mimic the same rule in OPNsense pretty easily. I will leave that exercise up to the reader and is not the focus of this how-to. It should be stated that even blocking a huge list of known public DNS is not a perfect solution to blocking encrypted DNS requests because it is impossible to have a complete list especially since anyone can spin up a DNS server on the Internet. Still, it does provide some additional protection if you want to tighten your network down as much as possible.

Creating a NAT Port Forward Rule for DNS Redirection

To redirect DNS requests from a given network, a simple NAT port forward rule may be created. Even though NAT port forward rules are typically used to allow traffic from an outside network on the Internet to have access to various services hosted on your network, the rules may be used on internal network interfaces as well. In fact on the “Firewall: NAT: Port Forward” page, you will see that the default anti-lockout rule is applied to the LAN interface so that you do not lose access to the web interface should you accidentally create a rule which blocks access.

Default Anti-Lockout Rule

Go to the “Firewall > NAT > Port Forward” page and click the “Add” button. You will want to change the following settings as shown in the screenshot below:

Option Value
Interface IOT
Protocol TCP/UDP
Destination/Invert Checked
Destination IOT net
Destination port range DNS
Redirect target IP
Redirect target port DNS
Description Redirect DNS requests to internal DNS resolver
NAT Port Forward DNS Redirect Rule

The “Interface” may be any of the local network interfaces/VLANs that you have defined. I chose my IOT network as an example network. Only select one interface for this rule. For the “Destination”, you will want to pick the system generated network address for the interface you selected. In my example, that would be the “IOT net” alias. Pick “DNS” as the “Destination port range” since that is the traffic you will want to match. The “Redirect target IP” is set to (localhost) so it uses the internal Unbound DNS service in OPNsense.

Note: If you are running a Pi-hole DNS server, you will need to enter the IP address of your Pi-hole server in the “Redirect target IP” box. For those running 2 Pi-hole servers for redundancy (which I recommend to minimize network downtime for updates, etc), you could create an alias for both IP addresses. Then for the “Pool Options” select something like “Random” or “Round Robin” so that your DNS requests can be more balanced between the two servers. I never actually tried using the pool options for this purpose but when I was helping someone asking for assistance that had 2 Pi-holes, I thought of that possibility (you would still want to assign both Pi-holes as your DNS servers in each of the interface’s DHCP configuration page for the DNS traffic that is not redirected).

The “Redirect target port” should automatically be set to “DNS” based on your selection for the “Destination port range”, but I included it in the list to ensure you leave it set to “DNS”.

It is critical that you check the “Destination/Invert” box because that makes the rule match any traffic that originates from the IOT network and is not using the local IOT interface/gateway IP address to resolve DNS queries. In other words, this rule will be triggered on any DNS traffic that is destined for DNS servers located on the Internet or even other parts of your network. By default in OPNsense, the interface address configured for each network is the gateway/DNS address. So if you had an IOT network with the network IP address range of with the interface IP address set to, it will be the address of the gateway (to other networks/Internet) as well as the DNS server address for that network. That is why the redirection rule will allow DNS traffic to and redirect all other traffic to (or other configured DNS server). The address exists in the IOT net so it does not need redirected and the redirect rule is not triggered. Keep in mind that all of the interface addresses such as will resolve to the local Unbound DNS resolver which is the localhost address of, which is why the redirect target IP address is set to the localhost address.

Once you click the “Save” button and apply the NAT port forward rule, you may want to go to the firewall rule page for the interface you added the redirect rule. In my example, that would be the “Firewall > Rules > IOT” page. You will notice that there was a rule automatically added to bottom of the list. Depending on the other rules you have configured, you may need to move that auto-generated rule higher up in the list near the top so that it will have higher priority. You will want to make sure the other rule(s) do not prevent that rule from working properly (if any rules above a rule is matched, no rules below that rule will be triggered so the order of the rules is important).

You will need to repeat this rule for each network you wish to redirect DNS requests – but what if you have several networks? Repeating this process could get tedious and annoying. Also it adds more maintenance in the future should you decide to change the rule. Fortunately, there is one way you may go about creating a single rule for multiple interfaces.

Multiple Interface Configuration

In order to have a single rule apply to multiple interfaces, you can create a firewall group. Firewall groups allow you to group multiple interfaces and create rules that apply to all the interfaces in the group. Group rules are higher in the rule processing hierarchy than interface specific rules which means the group rules will be processed before the interface rules. For the DNS redirection rule, you likely should not encounter issues with the rule being processed earlier than the interface rules. However, when writing group rules for multiple interfaces, you should keep in mind the rule processing order since it could cause you issues trying to implement various rules (if your group rule matches traffic to allow/deny before it reaches the interface rules, your interface rule(s) will not have a chance to be processed, for instance).

To create a rule group, go to the “Firewall > Groups” page. Then click the “Add” button.

Firewall Groups Page

Enter a “Name” for the firewall group and then select all of the interfaces/networks in which you wish to redirect the DNS requests. In my example, I am using the name “CommonDNS” to make a descriptive name for the group. There may be some interfaces where you do not need or want redirection so you can leave them unchecked. For instance, you may have an isolated network that does not have access to the Internet. Perhaps there are networks which you prefer to block external DNS requests rather than redirecting them. Click “Save” to create the group.

Create Firewall Group

Now you can create the redirection as was done before except you will choose the firewall group rather than a specific interface. On the “Firewall > NAT > Port Forward” page, click the “Add” button. Enter the following values below:

Option Value
Interface CommonDNS
Protocol TCP/UDP
Destination/Invert Checked
Destination CommonDNS net
Destination port range DNS
Redirect target IP
Redirect target port DNS
Description Redirect DNS requests to internal DNS resolver

You should see on the “Firewall > Rules > CommonDNS” page that the redirection from the NAT port forward has been automatically added to the rule list.

CommonDNS Firewall Rules

Testing the Redirection

How do you go about testing if the redirection works properly? After all, you may not notice any difference if you configured everything properly. One simply way is to add a DNS override. A DNS override can be used to set a different IP address for a given domain – including public domain names on the Internet. In a corporate environment can be useful if you want to have an Intranet portal that is different from the public Internet website, for instance. For our purposes, it can be used to test DNS redirection.

Go to the “Services > Unbound DNS > Overrides” page. Click the “+” button to add a new override. Enter a well-known domain name that you do not use for anything on your network (to prevent possible temporary disruption of service) such as Pick a random local IP address on your network such as

DNS Override

Once you save the override, you will see it in the list. Click the “Apply” button in order for the changes to take effect.

DNS Override

If you are using Linux, you can run the following host command to do a DNS lookup to see which IP address will be returned. The host command can be given any arbitrary DNS server rather than using your default DNS server. I am using Google’s DNS server to make an external DNS request. You should notice that the local IP address is returned rather than the public IP address:

$ host
Using domain server:
Aliases: has address

If you are on Windows or prefer not to use a command line tool, you could open the web browser and try to visit It should fail unless the IP address is cached by the browser (perhaps use the Shift key + click the refresh button to force a refresh).

Important: Do not forget to remove the DNS override once you are done testing. Otherwise, you will not be able to visit that domain!


That simple redirect rule should be all you need in order to redirect rogue DNS request to your configured DNS servers. Depending on your preferences, you can use either the default Unbound DNS server or something like Pi-hole. It is even possible to redirect DNS requests randomly or round robin to multiple IP addresses using an alias, which is nice if you multiple DNS servers (I recommend having 2 in case one goes down or you are performing updates so your network does not go down). Also, you can configure multiple interfaces at one time using firewall groups. I hope you found the various different ways of configuring DNS requests useful for configuring your own home network!

comments powered by Disqus