capture/forward all outbound DNS traffic

[mikeyw64]

Hi Guys,

Trying to setup my internal network  so that all outbound requests regardless of destination get sent to a specific device on my internal network  ie if a client makes a request to say 8.8.8.8 then it actually get's redirected to 192.168.1.2

My setup is that I have a Raspberry pi (running Raspbian Buster) with 2 ethernet ports & on wifi network which is running PiHole for DHCP & DNS based ad blocking


Everything working using the below configuration:

eth0 
Static IP : 192.168.1.2
DGW : 192.168.1.1 (ISP provided router, DHCP disabled, no advanced config available)
DHCP : Assigns in Range 192.168.1.100-200; DNS 192.168.1.2 ; DGW 192.168.1.1 (to be switched to .254 if I can get this working)

 

eth1 (currently being tested using static config on laptop to use as DGW which works as expected for internet access)
Static IP : 192.168.1.254
 

wlan0 (guest wifi)
Static IP : 10.0.0.1
DHCP : Assigns in range 10.0.0.100-200; DNS 10.0.0.1; DGW 10.0.0.1


What I'm attempting to do is to monitor the inbound traffic on eth1/192.168.1.254 and transparently redirect all DNS requests to 192.168.1.2

So far I have tried the following configs without success (although "normal" dns lookups via 192.168.1.2 always work correctly.) as lookups from a client to say 8.8.8.8 simply time out

 

pi@Heimdall:~ $ sudo  iptables -t nat -A PREROUTING -i eth1 ! -s 192.168.1.2 -p tcp --dport 53 -j DNAT --to 192.168.1.2:53
pi@Heimdall:~ $ sudo  iptables -t nat -A PREROUTING -i eth1 ! -s 192.168.1.2 -p udp --dport 53 -j DNAT --to 192.168.1.2:53


pi@Heimdall:~ $ sudo iptables -t nat -L --line-numbers
Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    DNAT       tcp  -- !Heimdall             anywhere             tcp dpt:domain to:192.168.1.2:53
2    DNAT       udp  -- !Heimdall             anywhere             udp dpt:domain to:192.168.1.2:53

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    MASQUERADE  all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

NB have also tried the above without  stating the :53 

Have also tried a more explicit option without any success (the .10 IP is a laptop being used for testing, statically configured to use .254 as it's DGW)

 

pi@Heimdall:~ $ sudo iptables -t nat -A PREROUTING -s 192.168.1.10  -d 8.8.8.8 -p tcp --dport 53 -j DNAT --to-destination 192.168.1.2:53
pi@Heimdall:~ $ sudo iptables -t nat -A PREROUTING -s 192.168.1.10  -d 8.8.8.8 -p udp --dport 53 -j DNAT --to-destination 192.168.1.2:53
pi@Heimdall:~ $ sudo iptables -t nat -L --line-numbers
Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    DNAT       tcp  --  192.168.1.10         dns.google           tcp dpt:domain to:192.168.1.2:53
2    DNAT       udp  --  192.168.1.10         dns.google           udp dpt:domain to:192.168.1.2:53

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    MASQUERADE  all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

 

[WereCatf]

31 minutes ago, mikeyw64 said:

Everything working using the below configuration:

eth0 
Static IP : 192.168.1.2
DGW : 192.168.1.1 (ISP provided router, DHCP disabled, no advanced config available)
DHCP : Assigns in Range 192.168.1.100-200; DNS 192.168.1.2 ; DGW 192.168.1.1 (to be switched to .254 if I can get this working)

 

eth1 (currently being tested using static config on laptop to use as DGW which works as expected for internet access)
Static IP : 192.168.1.254

Your DHCP-settings are telling your computers to use the ISP-router as gateway? That's not going to work. You need to set up your Pi as the router if you want it to capture and redirect traffic.

 

EDIT: I was a bit hasty in clicking "post" because I forgot to mention that even then, your setup won't be able to capture and redirect encrypted DNS -- Firefox is moving to use encrypted DNS by default in the future and I think I've read somewhere that Chrome does that already. Getting that to work is a whole another rabbit-hole.

[mikeyw64]

1 hour ago, WereCatf said:

Your DHCP-settings are telling your computers to use the ISP-router as gateway? That's not going to work. You need to set up your Pi as the router if you want it to capture and redirect traffic.

 

EDIT: I was a bit hasty in clicking "post" because I forgot to mention that even then, your setup won't be able to capture and redirect encrypted DNS -- Firefox is moving to use encrypted DNS by default in the future and I think I've read somewhere that Chrome does that already. Getting that to work is a whole another rabbit-hole.

Correct, DNS interception will eventually require all traffic to go through the Pi however the current setup is that the Clients on the LAN only use the Pi for DHCP & DNS via eth0/192.168.1.2.


To test the new setup I'm statically configuring a laptop to use eth1 /192.168.1.254 as its DGW and on the Pi traffic through eth1 is being masqueraded out through eth0/192.168.1.2  to 192.168.1.1(ISP router) and then onwards to the internet.

Where I'm having problems  is capturing the DNS traffic on port 53.

In regards to DNS over HTTPs/DOH  (which is what Chrome & Firefox are moving to support rather then DNSencrypt) that will only kick in if the client computer  is configured to use DNS services which support DOH and even then they fail back to standard 53 if that fails.

https://www.zdnet.com/article/google-to-run-dns-over-https-doh-experiment-in-chrome/
 

[WereCatf]

9 minutes ago, mikeyw64 said:

In regards to DNS over HTTPs/DOH  (which is what Chrome & Firefox are moving to support rather then DNSencrypt) that will only kick in if the client computer  is configured to use DNS services which support DOH and even then they fail back to standard 53 if that fails

That's actually incorrect about Firefox: Firefox is moving to use DOH by default, regardless of your DNS-settings. You can disable it by setting your DNS-server to return NXDOMAIN for "use-application-dns.net" -- redirecting it to e.g. 127.0.0.1 isn't enough, it has to return NXDOMAIN for DOH to be disabled. See e.g. https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/

 

You may be correct about Chrome, I wouldn't know.

[mikeyw64]

30 minutes ago, WereCatf said:

That's actually incorrect about Firefox: Firefox is moving to use DOH by default, regardless of your DNS-settings. You can disable it by setting your DNS-server to return NXDOMAIN for "use-application-dns.net" -- redirecting it to e.g. 127.0.0.1 isn't enough, it has to return NXDOMAIN for DOH to be disabled. See e.g. https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/

 

You may be correct about Chrome, I wouldn't know.

I'll cross that bridge if and when it crops up, for now I simply want to try and capture all outbound traffic on port 53 from my LAN and redirect it

EDIT:

Actually looking at https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet that's a fairly trivial exercise, just need to add the canary address in my local DNS server and get it to return the correct info so firefox knows local content filtering is in place and then it will fall back to using system settings.

EDIT:

Sorted the Canary thing , see attachement 

[mikeyw64]

ok that’s v.interesting

If I add a rule to redirect all non https traffic back to 192.168.1.2 that works exactly as expected (ie I get the default blocked page) so that says to my mind that the “rule” or “logic” or whatever you want to call it is correct.

So why do I get that nslookup error/timeout when specifying anything other than pihole with the same rule (other than port number) applied?

/me scratches head

 

pi@Heimdall:~ $ sudo iptables -t nat -A PREROUTING -i eth1   -p tcp --dport 80 -j DNAT --to-destination 192.168.1.2:80


pi@Heimdall:~ $ sudo iptables -t nat -L --line-numbers
Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    DNAT       tcp  --  anywhere             anywhere             tcp dpt:http to:192.168.1.2:80
2    DNAT       tcp  --  anywhere             anywhere             tcp dpt:domain to:192.168.1.2:53
3    DNAT       udp  --  anywhere             anywhere             udp dpt:domain to:192.168.1.2:53

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    MASQUERADE  all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

 

[mikeyw64]

Success!!!

Found the “solution” at this page.

Forward the DNS traffic to my ISP provided router and it then bounces it back to PiHole.

 

pi@Heimdall:~ $ sudo iptables -t nat -A PREROUTING -i eth1 ! -s 192.168.1.2 -p tcp --dport 53 -j DNAT --to 192.168.1.1:53
pi@Heimdall:~ $ sudo iptables -t nat -A PREROUTING -i eth1 ! -s 192.168.1.2 -p udp --dport 53 -j DNAT --to 192.168.1.1:53
pi@Heimdall:~ $ sudo iptables -t nat -L --line-numbers
Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    DNAT       tcp  -- !Heimdall             anywhere             tcp dpt:domain to:192.168.1.1:53
2    DNAT       udp  -- !Heimdall             anywhere             udp dpt:domain to:192.168.1.1:53

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    MASQUERADE  all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

Top half below is the test results from my laptop configured statically as:
Static IP : 192.168.1.10
DNS : 192.168.1.2
DGW : 192.168.1.1

In the lower half the DGW was changed to 192.168.1.254 which is eth1 on the Pi, as you can see DNS requests to 8.8.8.8 now give the same response as going directly to the PiHole