This tutorial will show you how to force all DNS querys to go through Opnsense router regardless of DNS servers specified on the local system. This will redirect anything going through 53 to the router itself.
Go to Services -> Unbound DNS -> General
(https://i.imgur.com/VCXqn5W.png)
Verify that ether ALL is selected or localhost with your LAN is selected.
(https://i.imgur.com/Ib6XUS8.png)
or
(https://i.imgur.com/FQSxkNJ.png)
Go to Firewall -> NAT -> Port Forward
(https://i.imgur.com/cvOmcFS.png)
Click the add new rule button
(https://i.imgur.com/gfu1kwi.png)
Set the following settings below.
Interface: LAN
Protocol: TCP/UDP
Destination / Invert: Checked
Destination: LAN address
Destination Port: DNS
Redirect target IP: 127.0.0.1
Redirect target port: DNS
NAT reflection: Disable
Note: If you have multiple networks, you would have to make a rule for each network. Make sure unbound is listening on the other network interfaces too.
Example for Wireless network:
Interface: Wireless
Protocol: TCP/UDP
Destination / Invert: Checked
Destination: Wireless address
Destination Port: DNS
Redirect target IP: 127.0.0.1
Redirect target port: DNS
NAT reflection: Disable
(https://i.imgur.com/28ag7Ug.png)
Here is my setup as a example after adding all the rules.
(https://i.imgur.com/qmBUmfq.png)
Now that the port forward rules have been created. We now have to adjust the rules under the firewall to make sure the DNS redirect is hit first.
Go to Firewall -> Rules -> LAN
(https://i.imgur.com/o24T3aL.png)
Move the DNS redirect rule above "Default allow LAN to any rule" rule
(https://i.imgur.com/3lPHtbr.png)
Then apply changes, and the final result should look like this.
(https://i.imgur.com/pXM9Jfd.png)
Notes: If you have multiple interfaces, you would have to move the rule for each interface.
Hello cypher100,
Thank you very much, exactly what I was looking for! 8)
Just one question, how can I see that it is working correctly?
Because when I use 8.8.8.8 as manual DNS server everything works (as expected) but I want to see that it is really working in the Logs or somewhere else.
Thank you! :)
Quote from: Raccoon on July 27, 2018, 12:28:54 PM
Hello cypher100,
Thank you very much, exactly what I was looking for! 8)
Just one question, how can I see that it is working correctly?
Because when I use 8.8.8.8 as manual DNS server everything works (as expected) but I want to see that it is really working in the Logs or somewhere else.
Thank you! :)
I added yahoo.com pointing to 127.0.0.1 as a host override. Then on my windows computer I use the command "nslookup yahoo.com 8.8.8.8" to see if it resolves to 127.0.0.1. Using nslookup should bypass any DNS cache on your local computer, but if it doesn't I ran ipconfig /flushdns before running the nslookup command.
Thank you, this process worked well for me. I guess advanced options had a lot to do with it and no other posted mentioned such important part of the setup : /
Best!!
How would this work on ipv6? I tried to mimic the NAT rules for ipv6, however then the DNS queries fail completely
I try to redirect to a dns server inside the lan with this rule
(https://picload.org/thumbnail/dcrgcila/dns_redirect.jpg) (https://picload.org/view/dcrgcila/dns_redirect.jpg.html)
But it doesnt work :(
please help
Thank you, tested whit nslookup and works great.
from chris42
QuoteHow would this work on ipv6? I tried to mimic the NAT rules for ipv6, however then the DNS queries fail completely
Excellent question what would be the destination for IPv6 or what is the equivalent to 127.0.0.1 for IPv6?
would it be ::1 for the loopback like 127.0.0.1 is for IPv4 loopback?
Also, pay attention to non-standard DNS ports used by public DNS servers, ports like 5353, 9953 and alike... And for DNS-over-TLS the standard port is 853.
A really tech savvy user will bypass your forced DNS redirection anyway!
Quote from: GDixon on November 26, 2018, 05:20:07 AM
from chris42QuoteHow would this work on ipv6? I tried to mimic the NAT rules for ipv6, however then the DNS queries fail completely
Excellent question what would be the destination for IPv6 or what is the equivalent to 127.0.0.1 for IPv6?
would it be ::1 for the loopback like 127.0.0.1 is for IPv4 loopback?
Normally ::1 is the IPv6-localhost-Address. I must configure the IPv6-Address of the Interface (created an Alias) instead of ::1 in the NAT Rule and then it works. The clients resolves DNS-Records even if using his own IPv6-DNS-Servers.
I tested this with my Android Phone. This has the App DNSChanger installed
https://play.google.com/store/apps/details?id=com.frostnerd.dnschanger
with this App you can use other DNS-Server. With the IPv6 DNS NAT Rule you can farther resolve your own DNS-Records in the Override Tab from Unbound DNS. Normally when using a external DNS-Server you can't resolve internal DNS-Records.
QuoteNormally ::1 is the IPv6-localhost-Address. I must configure the IPv6-Address of the Interface (created an Alias) instead of ::1 in the NAT Rule and then it works. The clients resolves DNS-Records even if using his own IPv6-DNS-Servers.
Hey p1n0ck10, could you go in to a little more detail regarding this?
NAT redirects now use floating rules when the rule's running across multiply interfaces.
You saying I'm going to have to create individual rules & aliases for each interfaces ipv6 address?
Currently I've got a floating ipv6 NAT rule redirecting to
::1, and it's clearly not working.
Quote from: Cypher100 on July 26, 2018, 03:16:37 AM
This tutorial will show you how to force all DNS querys to go through Opnsense router regardless of DNS servers specified on the local system. This will redirect anything going through 53 to the router itself.
Hi Cypher,
will this procedure also work for an DNS-Server, e.g. Pi-Hole, within my environment when I fill in the IP of Pi-Hole instead of 127.0.0.1 to the NAT rules?
Regards Chris
Quote from: ChrisChros on December 28, 2020, 09:23:27 AM
Quote from: Cypher100 on July 26, 2018, 03:16:37 AM
This tutorial will show you how to force all DNS querys to go through Opnsense router regardless of DNS servers specified on the local system. This will redirect anything going through 53 to the router itself.
Hi Cypher,
will this procedure also work for an DNS-Server, e.g. Pi-Hole, within my environment when I fill in the IP of Pi-Hole instead of 127.0.0.1 to the NAT rules?
Regards Chris
Have the same question.
Hi, so not sure I am doing this right but trying to re-direct all DNS queries to OPNsense as even thought I have my SmartTV set to this (GW of .1), it still ends up going to google (8.8.8.8). All other devices on the network are fine and use their default GW for DNS.
Here is how I have the NAT port forwarding setup.
(https://i.imgur.com/DuoGK7F.png)
Quote from: mayo on December 29, 2020, 08:28:46 AM
Quote from: ChrisChros on December 28, 2020, 09:23:27 AM
Quote from: Cypher100 on July 26, 2018, 03:16:37 AM
This tutorial will show you how to force all DNS querys to go through Opnsense router regardless of DNS servers specified on the local system. This will redirect anything going through 53 to the router itself.
Hi Cypher,
will this procedure also work for an DNS-Server, e.g. Pi-Hole, within my environment when I fill in the IP of Pi-Hole instead of 127.0.0.1 to the NAT rules?
Regards Chris
Have the same question.
I have now set my Pi-Hole IP instead of 127.0.0.1 to the NAT rules and it looks like its working
I tried the different methods from this thread to redirect everything to my pihole with cloudflare upstream dns.
When I change the DNS server of my computer to 8.8.8.8 and go to https://www.dnsleaktest.com/ and start a test, it then shows a bunch of google servers, so it doesn't seem to work. Or is my understanding wrong?
In another thread (https://forum.opnsense.org/index.php?topic=15472.0) it is mentioned to create an outbound NAT translation. I haven't read that anywhere else. So is this needed?
Redirecting DNS to 127.0.0.1 seem to fail for me:
Whereas a redirect to the relevant LAN/VLAN's gateway (e.g. 192.168.1.1:53) works, a redirect to 127.0.0.1:53 does not:
Quote
nslookup www.ft.com ns2.google.com.
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 216.239.34.10
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an UnKnown.
The DNS request shows up in my (adguard home) logs, but apparently the response to my client is faulty.
If redirecting to 192.168.1.1, the redirect works and the client "does not notice":
Quotenslookup www.ft.com ns2.google.com.
Server: ns2.google.com
Address: 216.239.34.10
Nicht autorisierende Antwort:
Name: ft2.map.fastly.net
Addresses: 151.101.2.209
151.101.66.209
151.101.130.209
151.101.194.209
Aliases: www.ft.com
What could be the reason?
Redirecting to 127.0.0.1 would be favourable as I could apply it globally to all local LAN/VLAN/VPN interfaces, whereas redirecting to a gateway address would require individual rules for each interface (bleh!).
that would be the case if you have disabled it on Systems > Settings > General > "Do not use the local DNS service as a nameserver for this system"
One quick way to check is to see the contents of your /etc/resolv.conf file. I suspect it doens't have 127.0.0.1
Whether that is what you want or not is another matter.
Thanks but that's not it - the option is unchecked..
Probably more of a firewall issue I guess?
Quote from: abulafia on September 16, 2021, 06:42:14 PM
Thanks but that's not it - the option is unchecked..
Probably more of a firewall issue I guess?
Did you ever solve this issue?
its still a nightmare fror the DOT. canot seems to get it working neither.
followed every tutorial i could find but nothing really worked.
same issue for me as well...
For DoT it wont work because the client will not accept answers from your own resolver. Im just blocking DoT requests by FW rule, most clients will fallback to normal DNS, bad luck for those which doesnt...
For DoH Im doing similar, blocking 443 for source= Alias "DNS Servers" with some DNS Server lists I found on github. This will not cover every existing DNS Server, but is the best way I found.
QuoteFor DoH Im doing similar, blocking 443 for source= Alias "DNS Servers" with some DNS Server lists I found on github.
Could you please share the link for this github list?
UnboundDNS > General > Network Interfaces:
I'm running 21.7.6 so I guess that's why don't see the option for "all" or "Localhost". I do see my 3 interfaces and the WAN interface. Along with my 3 interfaces, should I select WAN here as well?
There's no mention in this tutorial for the setting "Outgoing Network Interfaces". It says by default all interfaces are used. Should I leave it using all interfaces or should I only select WAN?
Thanks
Quote from: meschmesch on November 25, 2021, 12:01:08 PM
Could you please share the link for this github list?
Sorry, didnt read until today...
This are the lists I am using:
https://raw.githubusercontent.com/BBerastegui/fresh-dns-servers/master/resolvers.txt
https://raw.githubusercontent.com/flo-wer/doh-list/master/domains.txt
https://raw.githubusercontent.com/neargle/public-dns-list/master/all.txt
https://raw.githubusercontent.com/oneoffdallas/dohservers/master/iplist.txt
https://raw.githubusercontent.com/oneoffdallas/dohservers/master/ipv6list.txt
https://public-dns.info/nameservers-all.txt
Hello,
I just wanted to say that this HOWTO saved me a ton of trouble I had with my Android mobiles, that were not seeing local hosts even though they are added in the default DNS (which is piHole).
Apparently, my mobiles were still looking for them outside and so it failed.
Once I redirected all external DNS queries to my piHole - everything works great !
Thanks for this !
I have this working also. But what I do not understand or know how to do this in the FW rules, is what zenarmor/sensei does. It looks like it goes one step further.
With the settings in this forum thread and when I do nslookup google.com 1.1.1.1
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
Name: google.com
Address: 142.251.39.110
------------
But with zenarmor app control - blocking - "network management" I get:
nslookup google.com 1.1.1.1
;; connection timed out; no servers could be reached
and nslookup google.com 192.168.1.1 (opnsense ip)
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: google.com
Address: 142.251.39.110
So how to create this effect in the firewall of opnsense without sensei/zenarmor? looks even more secure. Allowing opnsense dns but no other
If DNS forwarding is set up correctly then the outcome is achieved and you don't need additional rules. A host may think it is using other DNS servers but it is actually not. That's a more sophisticated outcome than just blocking the other DNS servers entirely.
yes ok. I did a rewrite check on yahoo.com to 127.0.0.1 and that worked:
nslookup yahoo.com 9.9.9.9
Server: 9.9.9.9
Address: 9.9.9.9#53
Non-authoritative answer:
Name: yahoo.com
Address: 127.0.0.1
But why I asked it that I have some bird box cams on the network that are blocked from internet access.
I noticed with the sensei/zenarmor blocked network management that it was blocking port 53 queries from those bird boxes. That made me think what to do, block port 53 access for those cam's or just keep current redirect all DNS as sufficient ?
Other configuration: https://www.sunnyvalley.io/docs/network-security-tutorials/how-to-configure-opnsense-firewall-rules#1-allowing-only-specific-dns-servers
i have those redirect and block rules operating.
I thing that zenarmor/semsei is operating before those firewall rules(?)
Is someone else facing problems with DNS redirection an Google Nest mini?
My Google Home mini is working as expected with the redirecting rules but the Nest mini not. The Nest is not able to establish an internet connection and stops working.
I tried with port forward rule only as well a combination of outbound and port forward, no luck with the Nest mini.
Any suggestions to fix this problem?
UPDATE:
So I think I have it now.
I checked all my port forward rules and realized that NAT reflection was set to "Use system default", this has to be set to "Disabled".
I'm also trying to understand how this works and I have created the NAT-> port forward rule (attached) and the rule 1 has automatically been created.
The issue I have with my Google Chromecast is that it only works if I have rules 2 and 3, but my understanding was that I didn't need any addional rule, can someoen shed some light?
Tia.
Destination has to be negated ( ! ) as you want to redirect traffic whichs destination is NOT lanNet/ThisFirewall.
LAN TCP/UDP * * ! This Firewall 53 (DNS) 10.13.12.2 53 (DNS) Redirect DNS to this Firewall
LAN TCP/UDP * * ! This Firewall 53 (DNS) fd00:10:13:12::2 53 (DNS) Redirect v6 DNS to this Firewall
@tiermutter
I guess you're referring to the port forward rule, right? In that case, it's been negated (see screenshot) - ! LAN address - or you mean something elese?
huh?! Sorry... watched the secreenshots on the smartphone, looks like I mixed up something.
I remember I had problems using loopback IP for redirect to, thats why I use the LAN interface IP instead.
Ah no worries, I will change the loopback address with the address of my firewall and will see if any better, will keep you posted.
Thanks.
Yes, after changing the loopback address also my Goolge chromcast is working :P
@hushcoden
Can you please share a picture of your now working rules.
Two attachments, one for the port forward and one for the LAN rule, which is automatically created.
Don't forget the rules for IPv6, if it's not disabled... :)
comprehension questions, what is the difference between "127.0.0.1" and "This Firewall"?
Im not really sure, but I think "this firewall" contains all interface IPs of the firewall. All client traffic passing the firewall will be destinated to this firewall / an interface IP or to another network, but can never be destinated to a loopback address.
Hi, many thanks for this HowTo, works flawlessly for me.
Would it be possible to add a similar Redirect rule for NTP service port 123 so that Opnsense NTP server will only be used?
Quote from: skyfighter on March 19, 2022, 11:04:52 AM
Hi, many thanks for this HowTo, works flawlessly for me.
Would it be possible to add a similar Redirect rule for NTP service port 123 so that Opnsense NTP server will only be used?
Yes, its basically the same.
br
I use a Port Forward rule to forward all NTP traffic, which is not coming from the firewall, to my OPNsense.
The interface local_Networks is an alias for all my lan and vlan, so I need only one rule.
I found this article https://www.derekseaman.com/2021/04/how-to-redirect-hardcoded-dns-to-opnsense.html and it's slightly different as it also considers the source address, why is that and which solution is better?
Tia.
I'd really like to understand what the difference in using as source address 'any' vs !firewall_ip_address ?!?
Tia.
"!firewall_ip" as source takes care (or should to) that the firewall itself can use any DNS servers without being redirected to itself. I think this is superfluous as the rule is placed on LAN interface and the firewall itself will never hit the rule for outgoing DNS requests. However, without specifying the source everything works fine and the firewall itself is able to make necessary requests to DNS servers in WAN.
One more question: is it possible for just a device on the LAN being able to use custom DNS servers ?
Tia.
When configure that device with static ip and then add the dns you like in the " DNS servers" field. Have not tried that myself while I use adguard home for all devices / dns.
A few months later.... :)
In the past I excluded my wifes smartphone (IP by alias) from being redirected because she didnt want to use (ad-)filtered DNS servers. Just edit the forward rule and add the IP/alias negated ( ! ) to the source.
Quote from: tiermutter on June 15, 2022, 09:45:30 AM
In the past I excluded my wifes smartphone (IP by alias) from being redirected because she didnt want to use (ad-)filtered DNS servers. Just edit the forward rule and add the IP/alias negated ( ! ) to the source.
Can you please check the two attachments (NAT before, NAT2 after)? After that change, the port forward will work for all the IPs but 192.168.0.13 ?
Tia.
Yes, this should work and this IP can use those DNS specified in the clients setting or whatever any app wants to. Remember IPv6... If there is a redirect rule for v6, the client must be excluded here too. In this case it might be better to use MAC address instead of IPs.
Simple and clean tutorial Thanks!
Thank you so much OP of this tutorial everything seems to be working :)
Quote from: RamSense on April 21, 2022, 06:53:32 PM
When configure that device with static ip and then add the dns you like in the " DNS servers" field. Have not tried that myself while I use adguard home for all devices / dns.
I also use Adguard Home but want to exclude a VLAN from this to be redirected to the DNS I have setup in the DHCP for the VLAN interface, is this possible? I haven't been able to figure out a way to exclude my VLAN for Adguard.
Josh
After hours of testing this, I can get my Chromecast to have the correct DNS and all of that, I can fool the Chromecast with the direction above or at least I think I am. But certain apps like Disney, HBO Max and Hulu just won't work on the Chromecast. On my phone and computer it is no problem.
I believe there is something going on with the apps themselves or I am not doing something right. I even went as far as changing my DNS in AdGuard home to my VPNs and it does work but all these apps are still detecting a VPN.
Hopefully I am doing something wrong here?
Quote from: abulafia on September 11, 2021, 09:45:23 PM
Redirecting DNS to 127.0.0.1 seem to fail for me:
Whereas a redirect to the relevant LAN/VLAN's gateway (e.g. 192.168.1.1:53) works, a redirect to 127.0.0.1:53 does not:
Quote
nslookup www.ft.com ns2.google.com.
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 216.239.34.10
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an UnKnown.
The DNS request shows up in my (adguard home) logs, but apparently the response to my client is faulty.
If redirecting to 192.168.1.1, the redirect works and the client "does not notice":
Quotenslookup www.ft.com ns2.google.com.
Server: ns2.google.com
Address: 216.239.34.10
Nicht autorisierende Antwort:
Name: ft2.map.fastly.net
Addresses: 151.101.2.209
151.101.66.209
151.101.130.209
151.101.194.209
Aliases: www.ft.com
What could be the reason?
Redirecting to 127.0.0.1 would be favourable as I could apply it globally to all local LAN/VLAN/VPN interfaces, whereas redirecting to a gateway address would require individual rules for each interface (bleh!).
Quote from: TarrasQ on November 20, 2021, 03:32:33 AM
Quote from: abulafia on September 16, 2021, 06:42:14 PM
Thanks but that's not it - the option is unchecked..
Probably more of a firewall issue I guess?
Did you ever solve this issue?
Figured out a way to solve this issue. You can now safely use 127.0.0.1 in your NAT rule, instead of specifying the interface address (192.168.1.1 and other VLAN addresses).
The culprit here is AdGuardHome; as the 127.0.0.1 setting works fine when using Unbound instead of AGH.
Steps to FIX:
S1) Goto AdGuardHome webpage, navigate to 'Setup Guide' page
S2) Note down all the IP addresses (you can ignore the https, tls, quic addresses if any)
S3) Stop AdGuardHome service
S4) Edit the AdGuardHome.yaml file manually (make a backup !)
- file should be here... /usr/local/AdGuardHome/AdGuardHome.yaml
S5) Find the bind_hosts: line in the file
S6) Remove the 0.0.0.0 and replace with all the IP addresses you wish to listen
e.g.
bind_hosts:
- aaa.xxx.yyy.zzz
- 127.0.0.1
- ::1
- fe80::1%lo0
- 192.168.1.1
- 192.168.10.1
- 192.168.60.1
- 10.0.0.1
S7) Save the file
S8) Enable AdGuardHome service again.
S9) Goto AdGuardHome webpage, navigate to 'Setup Guide' page
S10) Compare these with Step2 - They should be the same as before...
All set...You can now change your NAT rules to 127.0.0.1 instead of 192.168.1.1 :)
Quote from: gspannu on February 16, 2023, 01:47:10 AM
Quote from: abulafia on September 11, 2021, 09:45:23 PM
Redirecting DNS to 127.0.0.1 seem to fail for me:
Whereas a redirect to the relevant LAN/VLAN's gateway (e.g. 192.168.1.1:53) works, a redirect to 127.0.0.1:53 does not:
Quote
nslookup www.ft.com ns2.google.com.
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 216.239.34.10
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an UnKnown.
The DNS request shows up in my (adguard home) logs, but apparently the response to my client is faulty.
If redirecting to 192.168.1.1, the redirect works and the client "does not notice":
Quotenslookup www.ft.com ns2.google.com.
Server: ns2.google.com
Address: 216.239.34.10
Nicht autorisierende Antwort:
Name: ft2.map.fastly.net
Addresses: 151.101.2.209
151.101.66.209
151.101.130.209
151.101.194.209
Aliases: www.ft.com
What could be the reason?
Redirecting to 127.0.0.1 would be favourable as I could apply it globally to all local LAN/VLAN/VPN interfaces, whereas redirecting to a gateway address would require individual rules for each interface (bleh!).
Quote from: TarrasQ on November 20, 2021, 03:32:33 AM
Quote from: abulafia on September 16, 2021, 06:42:14 PM
Thanks but that's not it - the option is unchecked..
Probably more of a firewall issue I guess?
Did you ever solve this issue?
Figured out a way to solve this issue.
You can now safely use 127.0.0.1 in your NAT rule, instead of specifying the interface address (192.168.1.1 and other VLAN addresses).
The culprit here is AdGuardHome; as the 127.0.0.1 setting works fine when using Unbound instead of AGH.
Steps to FIX:
S1) Goto AdGuardHome webpage, navigate to 'Setup Guide' page
S2) Note down all the IP addresses (you can ignore the https, tls, quic addresses if any)
S3) Stop AdGuardHome service
S4) Edit the AdGuardHome.yaml file manually (make a backup !)
- file should be here... /usr/local/AdGuardHome/AdGuardHome.yaml
S5) Find the bind_hosts: line in the file
S6) Remove the 0.0.0.0 and replace with all the IP addresses you wish to listen
e.g.
bind_hosts:
- aaa.xxx.yyy.zzz
- 127.0.0.1
- ::1
- fe80::1%lo0
- 192.168.1.1
- 192.168.10.1
- 192.168.60.1
- 10.0.0.1
S7) Save the file
S8) Enable AdGuardHome service again.
S9) Goto AdGuardHome webpage, navigate to 'Setup Guide' page
S10) Compare these with Step2 - They should be the same as before...
All set...
You can now change your NAT rules to 127.0.0.1 instead of 192.168.1.1 :)
Cool, thanks!
I am having some trouble with this and a pi hole. I set the firewall rule to send all traffic from port 53 to the pi-hole. The pi-hole is set and the dns server in the opnsense settings. When the firewall rule is enabled there is too much traffic to the pihole. I think what is happening is the pihole is also sending queries out on port 53 which is getting bounced back to itself causing a never ending loop.
I came across this thread while looking for a way to perform DNS NAT'ing. However it seems that if, like I am, using unBound, the DNSBL's don't get adhered to when performing these instructions with a NAT rule.
Has anyone else found a solution to that?
Quote from: p1n0ck10 on November 28, 2018, 06:15:14 AM
Quote from: GDixon on November 26, 2018, 05:20:07 AM
from chris42QuoteHow would this work on ipv6? I tried to mimic the NAT rules for ipv6, however then the DNS queries fail completely
Excellent question what would be the destination for IPv6 or what is the equivalent to 127.0.0.1 for IPv6?
would it be ::1 for the loopback like 127.0.0.1 is for IPv4 loopback?
Normally ::1 is the IPv6-localhost-Address. I must configure the IPv6-Address of the Interface (created an Alias) instead of ::1 in the NAT Rule and then it works. The clients resolves DNS-Records even if using his own IPv6-DNS-Servers.
I tested this with my Android Phone. This has the App DNSChanger installed
https://play.google.com/store/apps/details?id=com.frostnerd.dnschanger
with this App you can use other DNS-Server. With the IPv6 DNS NAT Rule you can farther resolve your own DNS-Records in the Override Tab from Unbound DNS. Normally when using a external DNS-Server you can't resolve internal DNS-Records.
Quote from: dave on June 25, 2020, 06:11:53 PM
QuoteNormally ::1 is the IPv6-localhost-Address. I must configure the IPv6-Address of the Interface (created an Alias) instead of ::1 in the NAT Rule and then it works. The clients resolves DNS-Records even if using his own IPv6-DNS-Servers.
Hey p1n0ck10, could you go in to a little more detail regarding this?
NAT redirects now use floating rules when the rule's running across multiply interfaces.
You saying I'm going to have to create individual rules & aliases for each interfaces ipv6 address?
Currently I've got a floating ipv6 NAT rule redirecting to ::1, and it's clearly not working.
Did either of you find a solution for IPv6. I was having the exact same issue as dave.
Quote from: gspannu on February 16, 2023, 01:47:10 AM
Figured out a way to solve this issue.
You can now safely use 127.0.0.1 in your NAT rule, instead of specifying the interface address (192.168.1.1 and other VLAN addresses).
The culprit here is AdGuardHome; as the 127.0.0.1 setting works fine when using Unbound instead of AGH.
Steps to FIX:
S1) Goto AdGuardHome webpage, navigate to 'Setup Guide' page
S2) Note down all the IP addresses (you can ignore the https, tls, quic addresses if any)
S3) Stop AdGuardHome service
S4) Edit the AdGuardHome.yaml file manually (make a backup !)
- file should be here... /usr/local/AdGuardHome/AdGuardHome.yaml
S5) Find the bind_hosts: line in the file
S6) Remove the 0.0.0.0 and replace with all the IP addresses you wish to listen
e.g.
bind_hosts:
- aaa.xxx.yyy.zzz
- 127.0.0.1
- ::1
- fe80::1%lo0
- 192.168.1.1
- 192.168.10.1
- 192.168.60.1
- 10.0.0.1
S7) Save the file
S8) Enable AdGuardHome service again.
S9) Goto AdGuardHome webpage, navigate to 'Setup Guide' page
S10) Compare these with Step2 - They should be the same as before...
All set...
You can now change your NAT rules to 127.0.0.1 instead of 192.168.1.1
:)
@Aida, AdGuardHome does not start any more when I add all these hosts under "bind_hosts":
- 192.168.1.1
- 127.0.0.1
- ::1
- fd00:1::
- fe80::f690:edff:fe00:b3a1
So I fixed the issue with AdGuard not starting: it seems it has issues parsing specific IPv6. This works:
bind_hosts:
- 192.168.1.1
- 127.0.0.1
- ::1
- 'fd00:1::'
But, the problem remains, a DNS request to 1.1.1.1 for example is properly redirected to AdGuard, but the answer does not make it to the client initiating the request.
In the packet capture done on the client (laptop) I can see what the reason is: the DNS request goes to 1.1.1.1, as expected, but the answer is coming from 192.168.1.1, which of course is then ignored.
Does someone know how I can get the Source IP "faked" on the way back? Or is that not really possible?
It's not really that important, it's in case I have a device on my home network with a hardcoded DNS server, but it would be useful in this case.
Quote from: aida on April 26, 2023, 07:28:14 PM
Did either of you find a solution for IPv6. I was having the exact same issue as dave.
Sadly no. Wish I knew the answer but using an Alias for ::1 and/or the link local IPv6 of my OPNsense's LAN interface does not work. I really don't know how to make this work.
Hopefully giving this topic a push with this post raises some attention.
Edit:
I read that you should use an Alais with the type "Dynamic IPv6 Host" and did as told in the documentation (https://docs.opnsense.org/manual/aliases.html) but still no luck.
Hi! Nice write up. Thank you!
I was toying around with this before finding this HOWTO-resource.
So here is what I did and wanted to check that I haven't created any holes or stupid things.
Got 3 networks. LAN, KIDS and GUEST. KIDS and GUEST are VLANs.
Got a alias net_RFC1918 which holds all private network addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Port Forward:
Checked all three networks above.
Proto: TCP/UDP
Destination: ! net_RFC1918
Ports: 53
Redirect IP: 127.0.0.1
This would catch any DNS request going outside private addresses and forward them to localhost DNS.
Floating rule:
It was automatically created from the Port Forward and looks like this.
Proto: TCP/UDP
Source: *
Destination: *
Port: 53
And it indicates that 3 interfaces are involved in this rule.
Allow rule for KIDS and GUEST are as follows, example here is for KIDS:
Proto: IPv4*
Source: KIDS_net
Destination: ! net_RFC1918
The thought here is that everything not targeting any private address is going through. Not allowing KIDS or GUEST to access the LAN 😁 (can't have my creative kids in the LAN as they install all sort of things... Yes, we clean them out periodically and learns from the cyber-not-to-do lesson...)
Allow rule for LAN is default. Any allow.
So, good or bad take on the DNS redirect thingy?
Brgs!
Hey All ;D,
Hopefully, this can be helpful as I saw several posts above in regards to NTP and PiHoles specifically, both of which I have running on my network and across a VLAN for IOT devices. I have been running OPNSense with a PiHole for several years- I've been able to NAT things to it without issue.
Physical setup is pretty simple - Modem -> OPNSense -> Managed Switch -> PiHole -> End Users
First suggestion: If you don't already, start using Aliases! They make the rule tables much easier to read and understand.
Let's address the PiHole or local DNS server other than OPNSense itself. The reason it breaks when this (the generic tutorial rule) is applied to the PiHole address is that the NAT rule will also catch the requests coming out of the PiHole, UNLESS you also change the source piece of the rule. We actually need to use both inverse matches (the !) on source and destination for this to work properly. See attachment 1. It reads as follows;
On LAN interface - if the source address is NOT the PiHole on any port (end devices randomize source ports) AND the destination address is NOT the PiHole on port 53, then NAT the request to the PiHole on port 53.
What this double negative rule does, is allow the PiHole to send traffic to the router/firewall whilst catching every other request.
For the VLAN or IOT interface - the source inverse is not needed as the PiHole resides on a different subnet, so you can simply say- If the destination is NOT the PiHole, NAT it to the PiHole. See attachment 2. I have a firewall rule in place that allows/passes DNS traffic to the PiHole (can be seen in attachment 3).
Furthermore, I block all other DNS requests and keep the IOT devices from talking to each other. See attachment 3. You can now extrapolate this idea across however many VLANs or subnets are in use.
Next, let's address the NTP service. I use the OPNSense machine to host NTP, which makes the NAT rules quite simple. The service is also applied on the VLAN/IOT interface. Unfortunately, within the OPNSense UI we can't select multiple destinations, so separate NAT rules are required for each interface (no biggie, just clone it and modify the interface). Additionally, within the UI, I could not select from known addresses/interfaces for the NAT IP as I could for any other NAT rule (appears to be a UI bug). I opted not using an alias here as the addresses are those of the interfaces themselves i.e. X.X.X.1 - NTP only uses UDP on port 123. See attachment 4.
The NTP rule(s) read as follows:
On selected Interface- any source on UDP that the destination is NOT the interface address on port 123, then NAT to the interface address on port 123.
Finally, don't forget to adjust the rule order across all interfaces to get traffic flowing as you intend. Remember, they process top down. Hopefully, this can save someone from banging their head too many times or giving up on the PiHole altogether! Happy computing!
Quote from: Lakkiada on October 10, 2023, 04:45:50 PM
Also, DNS does not use TCP (DoT uses TCP, but uses port 853 not 53). You can simplify and clean up the rules by applying it to UDP only or adjusting to your use case.
This is factually incorrect, do NOT do this. You will cause yourself a lot of trouble with large DNS responses and things like DNSSEC. Even worse when EDNS0 does not work for some reason.
"Traditional" DNS queries only use UDP but are limited, AFAIK. eDNS and DNSSec are extensions to the DNS system - also AFAIK. However, after reading further about DNS extensions @ https://en.wikipedia.org/wiki/Domain_Name_System (https://en.wikipedia.org/wiki/Domain_Name_System) and https://en.wikipedia.org/wiki/Extension_Mechanisms_for_DNS (https://en.wikipedia.org/wiki/Extension_Mechanisms_for_DNS) It appears that these extensions run on TCP across port 53, thus I decided to enable the rules for both protocols (TCP/UDP) across port 53, as per your suggestion.
If I am incorrect please point me to resources. I am all in for continued learning and ongoing education. Hopefully, with this change we can see further performance improvements! To clarify, I changed the protocols in my firewall allow rules and also the NAT rules to be sure that traffic may flow as intended.
Thanks for the tip! @ doktornotor
Quote from: Lakkiada on January 03, 2024, 06:29:53 PM
If I am incorrect please point me to resources.
No idea what you mean by traditional DNS. TCP is required for fallback, end of story.
https://dnsinstitute.com/documentation/dnssec-guide/ch03s05.html
https://datatracker.ietf.org/doc/rfc7766/
https://cmdns2.dev.dns-oarc.net/
Edited my original post to remove the inaccuracy. Dug up the old Unix networking book to clarify in my own brain:
"DNS hostname lookups are typically performed over UDP, but DNS also uses TCP for some operations."
Further in the hardening section, I was able to locate:
"DNS communicates over both UDP and TCP. Because UDP is a quick, packet-based protocol that allows for limited data transfer, it is typically used for the actual process of hostname resolution. TCP, meanwhile, is most commonly used for transactions that require large, reliable, and sustained data transfer- that is, zone transfers. However, individual queries can be made over TCP as well."
I must have confused the information in the zone transfer section as it goes onto discuss blocking TCP on 53 specifically in business settings and does warn: "in rare cases, this may block DNS queries, which are also permitted to use TCP. So use this approach with caution."
Thanks again for pointing me in the right direction @doktornotor and apologies for any confusion caused.
Quote from: 9axqe on May 14, 2023, 11:42:03 AM
So I fixed the issue with AdGuard not starting: it seems it has issues parsing specific IPv6. This works:
bind_hosts:
- 192.168.1.1
- 127.0.0.1
- ::1
- 'fd00:1::'
But, the problem remains, a DNS request to 1.1.1.1 for example is properly redirected to AdGuard, but the answer does not make it to the client initiating the request.
In the packet capture done on the client (laptop) I can see what the reason is: the DNS request goes to 1.1.1.1, as expected, but the answer is coming from 192.168.1.1, which of course is then ignored.
Does someone know how I can get the Source IP "faked" on the way back? Or is that not really possible?
It's not really that important, it's in case I have a device on my home network with a hardcoded DNS server, but it would be useful in this case.
I had the same problem and the reason is that the DNS request from the client with be answered by the AdGuard server directly to the client, because the systems are in the same network. The IP of the answer will be rewrite by the firewall, because the OPNsense redirected the traffic. There are currently two solutions, which I found out.
- Put the AdGuard server to a new subnet to use OPNsense for network traffic.
- Change the netmask of the AdGuard server to 255.255.255.255
But keep in mind that for both options all the traffic will be route via the OPNsense firewall and not anymore directly at the same network!
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".
Quote from: 9axqe on January 17, 2024, 02:37:15 PM
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?
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.
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.
Quote from: tiermutter on January 17, 2024, 05:15:15 PM
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.
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.
Quote from: 9axqe on January 17, 2024, 06:16:55 PM
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.
Quote from: 9axqe on January 17, 2024, 06:16:55 PM
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.
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:
PassIf 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 (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 (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/ (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.
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
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!
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?
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".
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.
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.
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..
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?
If I set it like yours, to allow destination 127.0.0.1 for dns and enter google.de into my browser, the browser fails to load the webpage. At the same time, I look into the live view, and I see that my client sends a dns request to 192.168.1.1 and gets blocked.
This is the fact that makes me suspicious and I therefore assume that 127.0.0.1 cannot be the correct destination under Rules>LAN.
Not under Rules > LAN.
NAT > Port Forward
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
I think the problem here is that I used the LAN interface as an example, which usually has default rules. Let's assume that I create a new interface. Then there are no rules under Rules>NEW. Everything is blocked per se. I can't even access the Internet. And if I now only create a forward port, with pass, then a client will not be able to connect to Ubound running on the FW. Or am I wrong?
So first I have to create a rule under Rules>NEW that allows a client to contact Ubound. And in this example, this is 192.168.10.1 and not 127.0.0.1, because on the one hand, I can see that the browser runs in a timeout with 127... and on the other hand, I can see it in the live logs, which show the connection from the client to 192.168.10.1 as blocked.
The port forward will allow the DNS request if configured as I wrote. But of course you will need at least an additional firewall rule to permit the browser to actually access the Internet after the DNS request has been answered and possibly - depending on your global NAT setup (automatic/hybrid/manual) also at least one outbound NAT rule.
How do I allow a single device to bypass the DNS redirect? I have AdGuard installed on my phone (192.168.68.118) and use a different set of lists than I do on my local AdGuard Home setup.
If you have a port forward rule in place to direct your devices to AGH, then place one rule above that one, source "your phone", flag "do not redirect" set.
Or use the AGH UI ;)
Quote from: Patrick M. Hausen on July 28, 2024, 08:12:31 PM
If you have a port forward rule in place to direct your devices to AGH, then place one rule above that one, source "your phone", flag "do not redirect" set.
Or use the AGH UI ;)
Could you be slightly more specific please? I'm new to OpnSense coming from Asuswrt-Merlin and most of the options and descriptions are still foreign to me.
Show your DNS redirect rule, please.
What did you set as source, why are you using source invert, why is the rule disabled?
Please show your current working DNS redirect rule and then I can help you to exempt your phone. OTOH as I alsow wrote the AdGuard home UI allows disabling filtering for individual clients - why not use that?
Quote from: Patrick M. Hausen on July 28, 2024, 10:37:42 PM
What did you set as source, why are you using source invert, why is the rule disabled?
Please show your current working DNS redirect rule and then I can help you to exempt your phone. OTOH as I alsow wrote the AdGuard home UI allows disabling filtering for individual clients - why not use that?
I used this tutorial which is exactly what's posted in the OP of this thread.
https://homenetworkguy.com/how-to/redirect-all-dns-requests-to-local-dns-resolver/
The rule is disabled until I can figure how how to allow specific devices to bypass it. Why does that matter anyway? I showed you the full config of the rule. Works fine except that I need to be able to allow a device to bypass that rule. Should I have it setup differently?
QuoteAdGuard home UI allows disabling filtering for individual clients - why not use that?
Because that does not solve the issue that I am having. I want to force all devices on LAN to use AGH. That's why I need the rule. But I don't want my phone to be forced to use AGH.
This rule cannot technically force all devices to use AGH - you have LAN net as destination instead of source, you have a source invert and you did not show your source setting, yet.
Please show all details of your rule.
I'm not following. I used the exact setup that's listed in the OP. I accidentally had LAN Net set for Destination. I changed that to LAN Address. I just need to know how to allow a device to bypass this rule.
Interface: LAN
Protocol: TCP/UDP
Destination / Invert: Checked
Destination: LAN address
Destination Port: DNS
Redirect target IP: 127.0.0.1
Redirect target port: DNS
NAT reflection: Disable
What exactly is the source set to in that rule?
Since I am going to go to sleep now:
1. duplicate the rule
2. set source to "your phone" in the duplicate
3. tick the "No RDR" checkbox in the duplicate
4. make sure the duplicate is above the general redirect rule for all devices in the list
That should do it.
Quote from: Patrick M. Hausen on July 28, 2024, 11:06:32 PM
What exactly is the source set to in that rule?
Since I am going to go to sleep now:
1. duplicate the rule
2. set source to "your phone" in the duplicate
3. tick the "No RDR" checkbox in the duplicate
4. make sure the duplicate is above the general redirect rule for all devices in the list
That should do it.
Source is set to any. I did not realize I had to hit the "Advanced" button to see the input box for source. I will try what you said. Thank you.
Can someone please clarify if the 'source port range' must be set on DNS or any and why?
Tia.
Source port range for DNS lookups is "any". A client may pick any random port, usually one >= 1024.
Would it also be advised to create a blockrule for port 53 dns when using dot or is enabling the redirect rule enough?
I did a redirect, just in case there's some badly configured device on the network with static DNS server IP.
The source port is randomly selected by the client, leave as any. Theoretically, the redirect rule "should" catch everything. I, however, also have block rules for port 53, 853, 5353 and 9953 - just in case - Zero Trust. Do be sure the redirect rule is above the block rules.
I also block DNS on the WAN if source is !WAN address on port 853 (also block all other 53,853,5353,9953). This effectively limits all DNS to my selected DNS over TLS servers.
How do I redirect ipv6 dns queries? Redirecting it to ::1?
That's what I'm doing, yes.
Quote from: sanji on January 11, 2021, 10:05:42 PM
I tried the different methods from this thread to redirect everything to my pihole with cloudflare upstream dns.
When I change the DNS server of my computer to 8.8.8.8 and go to https://www.dnsleaktest.com/ and start a test, it then shows a bunch of google servers, so it doesn't seem to work. Or is my understanding wrong?
In another thread (https://forum.opnsense.org/index.php?topic=15472.0) it is mentioned to create an outbound NAT translation. I haven't read that anywhere else. So is this needed?
Wondering this same question. Followed the guide but when I change my DNS server on my Iphone to 8.8.8.8 and run a dnsleaktest I can see the Google servers where I had expected my local unbound service?
What does your server use in terms of DNS protocol? HTTPS, QUIC, TLS...?
If it's using DNS over HTTPs for example, you're going to have to block 8.8.8.8:443 (both UDP and TCP).
If you want to go down that route, there are lists of public DNS over HTTPS/TLS providers, such as https://public-dns.info/nameservers.txt, which you then need to configure as FW aliases.
For DNS over TLS or QUIC it's simpler, you simply block anything to port 853 or 8853 (no point in redirecting, the certificate would not match).
Quote from: vicking on November 05, 2024, 10:33:07 AM
Quote from: sanji on January 11, 2021, 10:05:42 PM
I tried the different methods from this thread to redirect everything to my pihole with cloudflare upstream dns.
When I change the DNS server of my computer to 8.8.8.8 and go to https://www.dnsleaktest.com/ and start a test, it then shows a bunch of google servers, so it doesn't seem to work. Or is my understanding wrong?
In another thread (https://forum.opnsense.org/index.php?topic=15472.0) it is mentioned to create an outbound NAT translation. I haven't read that anywhere else. So is this needed?
Wondering this same question. Followed the guide but when I change my DNS server on my Iphone to 8.8.8.8 and run a dnsleaktest I can see the Google servers where I had expected my local unbound service?
All working now.. after setting it up again! Even when using 8.8.8.8 I can see the dns used is my local DNS service! :)