OPNsense Forum
English Forums => Tutorials and FAQs => Topic started by: 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.
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! :)
-
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
How 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!
-
from chris42How 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.
-
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.
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.
-
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
-
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)
-
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:
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":
nslookup 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?
-
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.
-
For 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
-
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?
-
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.
-
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 :)
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?
-
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:
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":
nslookup 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!).
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
:)
-
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:
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":
nslookup 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!).
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?
-
from chris42How 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.
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.
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.
-
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.
-
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!
-
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
-
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.
-
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".
-
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.
-
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.
-
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.