collect all external DNS requests redirect incoming DNS queries transmit them as needed
collect all external DNS requests redirect incoming DNS queries transmit them as needed
Hey everyone, I'm trying to configure my internal network so that every outgoing request—no matter where it goes—ends up on a specific device inside. For example, if a client sends 8.8.8.8, it should be automatically redirected to 192.168.1.2. My current arrangement uses a Raspberry Pi running Raspbian Buster with two Ethernet ports and a Wi-Fi network powered by PiHole for DHCP and DNS-based ad blocking. Everything functions as expected with the setup I have:
- eth0 has a static IP of 192.168.1.2
- DGW is 192.168.1.1 (ISP router, DHCP off, no advanced settings)
- DHCP range covers 192.168.1.100–200
- DNS points to 192.168.1.2
- eth1 is being tested with a static configuration that works for internet access
- Static IP 192.168.1.254 for guest Wi-Fi
- DHCP range 10.0.0.100–200, DNS 10.0.0.1
My goal is to monitor incoming traffic on eth1/192.168.1.254 and seamlessly forward all DNS queries to 192.168.1.2. I've tried various configurations without success—normal DNS lookups still work fine, but when a client tries 8.8.8.8 it times out. I'm looking to switch the DGW IP to .254 if possible.
I also attempted:
- A more direct DNAT rule for DNS 53
- Using a different IP (10.0.0.1) for DHCP and DNS
- Testing with a laptop as the client to verify routing
So far, I need to adjust these settings carefully to ensure smooth redirection while keeping everything stable.
Your DHCP configuration is directing devices to rely on the ISP router as a gateway, which isn't ideal. You should configure your Pi as the router to intercept and redirect traffic. Note: I acted quickly without realizing that even then, encrypted DNS capture won't function. The future looks promising with browsers adopting encrypted DNS by default—Firefox is already planning this shift, and Chrome seems to be following suit. Successfully implementing this will require further research.
Correcting DNS interception means all traffic must pass through the Pi, but presently clients on the LAN rely on the Pi for DHCP and DNS via eth0/192.168.1.2. For testing the updated configuration, I’m manually setting up a laptop to use eth1 /192.168.1.254 as its default gateway and routing Pi traffic through eth1 to 192.168.1.2. The current method hides Pi traffic on eth0/192.168.1.2 to 192.168.1.1 (ISP router) and beyond to the internet. The main issue is capturing DNS traffic on port 53. Concerning DNS over HTTPS/DOH (the approach Chrome and Firefox are adopting instead of DNSEncrypt), it activates only if the client device supports DOH, otherwise it reverts to standard port 53. https://www.zdnet.com/article/google-to-...in-chrome/
Firefox is transitioning to use DOH by default, independent of your DNS preferences. To disable it, configure your DNS server to return NXDOMAIN for "use-application-dns.net" — redirecting it to an IP like 127.0.0.1 isn't sufficient; it must return NXDOMAIN for DOH to be blocked. Refer to the relevant blog post for details. You might be right about Chrome, though I'm not sure.
I'll proceed with the bridge only when it appears; right now I'm just aiming to capture all outbound traffic on port 53 from my LAN and reroute it. Edit: Referring to the support page, it's a straightforward task—just add the canary address to my local DNS server so it returns accurate data, enabling Firefox to apply local content filtering before switching to system defaults. Edit: Organized the Canary setup, attached documentation.
This setup ensures every non-HTTPS traffic is sent to the default gateway at 192.168.1.2, which functions as expected. It confirms the logic is working properly. The issue with NSLookup errors or timeouts occurs when applying the same rule without specifying the protocol (like pihole) or changing other parameters, causing mismatches in how traffic is handled.
Success!!! Located the “solution” on that page. Send DNS traffic to your ISP using the router, and it will forward 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 shows 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