Device bypassing Pihole

Help
1

apologies if i am using the wrong term.

*i am running Pihole with Unbound on my Raspberry pi5. Setup quite some nftables rules with the help of googling / youtubing and chatgpt as am a complete noob with pihole.

Expected Behaviour:

With the nftables which reroute all traffics to pihole, block all outbound dns except my pihole, my tplink router as DHCP Server (static dns to my pihole) and my pihole upstream to unbound 127.0.0.1#5335.

I have setup nftables to block all outbound port53 except pihole. Block known public dns, doh and etc. I expect all local traffic via my network supposedly go through my pihole only.

Actual Behaviour:

Tested with pihole by running nslookup google.com which returns and shows the query went to unbound. Nslookup google.com 1.1.1.1 return with timeout as expected and intended.

I tried run nslookup google.com out of pihole return as expected (query responded by unbound). However i can't seem to get this when nslookup google.com 1.1.1.1 or whatever public dns server just seems to bypass my pihole.

I have tried changing my dns server back and forth between tplink router and pihole but doesn't make any difference.

Debug Token:

https://tricorder.pi-hole.net/A8faOObM/

2

seems to contradict:

Are you saying that sending lookups through 1.1.1.1 time out sometimes and at other times get resolved?

Please share the output of

nsookup google.com 1.1.1.1
3

I think I have just jumbled up the situations. Apologies for the confusion.

Based on my current nftables, my intention is to route / force all traffics whether hardcoded or not to go through pihole.

This is the first situation where I run nslookup google.com with and without 1.1.1.1 out of pihole

~ $ nslookup google.com
Server:         192.168.0.2
Address:        192.168.0.2#53

Non-authoritative answer:
Name:   google.com
Address: 216.58.200.14
Name:   google.com
Address: 2404:6800:4001:80a::200e

~ $ 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: 216.58.221.206
Name:   google.com
Address: 2404:6800:4001:80e::200e

The following is when I run nslookup google.com with and without 1.1.1.1 in pihole.

 $ nslookup google.com
Server:         192.168.0.2
Address:        192.168.0.2#53

Non-authoritative answer:
Name:   google.com
Address: 216.58.200.14
Name:   google.com
Address: 2404:6800:4001:80a::200e

 $ nslookup google.com 1.1.1.1
;; communications error to 1.1.1.1#53: timed out
;; communications error to 1.1.1.1#53: timed out
;; communications error to 1.1.1.1#53: timed out
;; no servers could be reached

I believe by running nslookup with 1.1.1.1 and return with 1.1.1.1 shows that there's bypass from my pihole from somewhere else when I have explicitly blocked 1.1.1.1

My nftables rules are as follows. I wonder if I missed out something or I am going the wrong direction? Thanks and apologies for the confusion.

(click for rule details) 
table inet nat {
        chain prerouting {
                type nat hook prerouting priority dstnat; policy accept;
                iifname "eth0" udp dport 53 counter packets 18411 bytes 1275269 dnat ip to 192.168.0.2
                iifname "eth0" tcp dport 53 counter packets 2 bytes 128 dnat ip to 192.168.0.2
                iifname "eth0" udp dport 53 counter packets 8 bytes 848 dnat ip6 to 2001:e68:5450:9ba:20a6:e591:c8d3:c76
                iifname "eth0" tcp dport 53 counter packets 0 bytes 0 dnat ip6 to 2001:e68:5450:9ba:20a6:e591:c8d3:c76
        }
}
table inet filter {
        chain input {
                type filter hook input priority filter; policy accept;
                ct state established,related counter packets 496713 bytes 43190785 accept
                iif "lo" counter packets 8900 bytes 606975 accept
                ip daddr 192.168.0.2 udp dport 53 counter packets 280024 bytes 19925463 accept
                ip daddr 192.168.0.2 tcp dport 53 counter packets 2 bytes 128 accept
                ip6 daddr 2001:e68:5450:9ba:20a6:e591:c8d3:c76 udp dport 53 counter packets 8 bytes 848 accept
                ip6 daddr 2001:e68:5450:9ba:20a6:e591:c8d3:c76 tcp dport 53 counter packets 0 bytes 0 accept
                ip daddr != 192.168.0.2 udp dport 53 counter packets 0 bytes 0 drop
                ip daddr != 192.168.0.2 tcp dport 53 counter packets 0 bytes 0 drop
                ip6 daddr != 2001:e68:5450:9ba:20a6:e591:c8d3:c76 udp dport 53 counter packets 0 bytes 0 drop
                ip6 daddr != 2001:e68:5450:9ba:20a6:e591:c8d3:c76 tcp dport 53 counter packets 0 bytes 0 drop
                ip daddr { 1.0.0.1, 1.1.1.1, 8.8.4.4, 8.8.8.8, 9.9.9.9, 45.90.28.0, 45.90.30.0, 77.88.8.1, 77.88.8.8, 94.140.14.14, 94.140.15.15, 149.112.112.112, 208.67.220.220, 208.67.222.222 } tcp dport { 443, 853 } counter packets 0 bytes 0 drop
                ip daddr { 1.0.0.1, 1.1.1.1, 8.8.4.4, 8.8.8.8, 9.9.9.9, 45.90.28.0, 45.90.30.0, 77.88.8.1, 77.88.8.8, 94.140.14.14, 94.140.15.15, 149.112.112.112, 208.67.220.220, 208.67.222.222 } udp dport 443 counter packets 0 bytes 0 drop
                ip6 daddr { 2001:4860:4860::8844, 2001:4860:4860::8888, 2606:4700:4700::1001, 2606:4700:4700::1111, 2620:fe::9, 2620:fe::fe, 2620:119:35::35, 2620:119:53::53 } tcp dport { 443, 853 } counter packets 0 bytes 0 drop
                ip6 daddr { 2001:4860:4860::8844, 2001:4860:4860::8888, 2606:4700:4700::1001, 2606:4700:4700::1111, 2620:fe::9, 2620:fe::fe, 2620:119:35::35, 2620:119:53::53 } udp dport 443 counter packets 0 bytes 0 drop
        }

        chain forward {
                type filter hook forward priority filter; policy drop;
                ct state established,related counter packets 0 bytes 0 accept
                ip daddr 192.168.0.2 udp dport 53 counter packets 0 bytes 0 accept
                ip daddr 192.168.0.2 tcp dport 53 counter packets 0 bytes 0 accept
                ip6 daddr 2001:e68:5450:9ba:20a6:e591:c8d3:c76 udp dport 53 counter packets 0 bytes 0 accept
                ip6 daddr 2001:e68:5450:9ba:20a6:e591:c8d3:c76 tcp dport 53 counter packets 0 bytes 0 accept
                ip daddr != 192.168.0.2 udp dport 53 counter packets 0 bytes 0 drop
                ip daddr != 192.168.0.2 tcp dport 53 counter packets 0 bytes 0 drop
                ip6 daddr != 2001:e68:5450:9ba:20a6:e591:c8d3:c76 udp dport 53 counter packets 0 bytes 0 drop
                ip6 daddr != 2001:e68:5450:9ba:20a6:e591:c8d3:c76 tcp dport 53 counter packets 0 bytes 0 drop
                ip saddr 192.168.0.0/24 counter packets 0 bytes 0 accept
                ip daddr 192.168.0.0/24 counter packets 0 bytes 0 accept
                ip daddr { 1.0.0.1, 1.1.1.1, 8.8.4.4, 8.8.8.8, 9.9.9.9, 45.90.28.0, 45.90.30.0, 77.88.8.1, 77.88.8.8, 94.140.14.14, 94.140.15.15, 149.112.112.112, 208.67.220.220, 208.67.222.222 } tcp dport { 443, 853 } counter packets 0 bytes 0 drop
                ip daddr { 1.0.0.1, 1.1.1.1, 8.8.4.4, 8.8.8.8, 9.9.9.9, 45.90.28.0, 45.90.30.0, 77.88.8.1, 77.88.8.8, 94.140.14.14, 94.140.15.15, 149.112.112.112, 208.67.220.220, 208.67.222.222 } udp dport 443 counter packets 0 bytes 0 drop
                ip6 daddr { 2001:4860:4860::8844, 2001:4860:4860::8888, 2606:4700:4700::1001, 2606:4700:4700::1111, 2620:fe::9, 2620:fe::fe, 2620:119:35::35, 2620:119:53::53 } tcp dport { 443, 853 } counter packets 0 bytes 0 drop
                ip6 daddr { 2001:4860:4860::8844, 2001:4860:4860::8888, 2606:4700:4700::1001, 2606:4700:4700::1111, 2620:fe::9, 2620:fe::fe, 2620:119:35::35, 2620:119:53::53 } udp dport 443 counter packets 0 bytes 0 drop
        }

        chain output {
                type filter hook output priority filter; policy accept;
                ip daddr 127.0.0.1 udp dport 53 counter packets 194 bytes 14562 accept
                ip daddr 127.0.0.1 tcp dport 53 counter packets 0 bytes 0 accept
                ip daddr { 1.0.0.1, 1.1.1.1, 8.8.4.4, 8.8.8.8, 9.9.9.9, 45.90.28.0, 45.90.30.0, 77.88.8.1, 77.88.8.8, 94.140.14.14, 94.140.15.15, 149.112.112.112, 208.67.220.220, 208.67.222.222 } udp dport 53 counter packets 3 bytes 168 drop
                ip daddr { 1.0.0.1, 1.1.1.1, 8.8.4.4, 8.8.8.8, 9.9.9.9, 45.90.28.0, 45.90.30.0, 77.88.8.1, 77.88.8.8, 94.140.14.14, 94.140.15.15, 149.112.112.112, 208.67.220.220, 208.67.222.222 } tcp dport 53 counter packets 0 bytes 0 drop
                ip daddr { 1.0.0.1, 1.1.1.1, 8.8.4.4, 8.8.8.8, 9.9.9.9, 45.90.28.0, 45.90.30.0, 77.88.8.1, 77.88.8.8, 94.140.14.14, 94.140.15.15, 149.112.112.112, 208.67.220.220, 208.67.222.222 } tcp dport { 443, 853 } counter packets 0 bytes 0 drop
                ip6 daddr { 2001:4860:4860::8844, 2001:4860:4860::8888, 2606:4700:4700::1001, 2606:4700:4700::1111, 2620:fe::9, 2620:fe::fe, 2620:119:35::35, 2620:119:53::53 } tcp dport { 443, 853 } counter packets 0 bytes 0 drop
                ip6 daddr { 2001:4860:4860::8844, 2001:4860:4860::8888, 2606:4700:4700::1001, 2606:4700:4700::1111, 2620:fe::9, 2620:fe::fe, 2620:119:35::35, 2620:119:53::53 } udp dport 53 counter packets 0 bytes 0 drop
        }
}
4

If the goal is to route all DNS traffic through Pi-hole, then a timeout would neither be expected nor intended, would it?

I also can't make sense of your nslookups.
Since both were issued on the machine running Pi-hole, I'd expect consistent results.
There's no reason why it would sometimes resolve and time out at other times when running from the same machine, unless 1.1.1.1 would really have been temporarily inaccessible or temporarily blocked by your firewall rules.

Your issue seems to be a firewall configuration rather than a Pi-hole one.
Glancing at your rules, it seems you are trying to redirect certain IPs (like 1.1.1.1), where you should focus on redirecting port 53 instead.

If you need further assistance with your firewall rules, you should consider to also consult forums specialising in your chosen firewall solution.

5

To be honest, my understanding towards the entire thing probably few % maybe? Have been screwing up the pihole and start from scratch for several time.

My intention is to route the traffics to pihole. And block other port 53 except pihole to force the other devices to pihole? Not sure if that's doable? Sorry if I sound stupid.

Anyway Thanks for looking into it.

Will continue to checkout on the firewall parts.

6

Well, where did you create those nftables rules?
On your router or on some dedicated firewall hardware?
Or on your RPi 5, perhaps?

7

Apologies for the late response. As mentioned, I have bare minimal knowledge. Hence Relying on google, reddit, chatgpt to cook up the nftables. Haha

The nftables are in my pi5.

Probably I should look at proper firewall ie pfsense / opnsense to route / force all traffic to pihole? I am aware that my router do not have such capability.

8

Then they are useless.

Your RPi will never see requests that clients are sending to public DNS servers.
The one device in your network that does is your router, as that acts as a gateway to the public Internet for all your clients.

Defining firewall rules to redirect DNS traffic on your RPi would only affect traffic originating from that RPi itself.

You should revert those rules.

1 Like
9

Yeap.

After going through more on firewall forums and read up. I need something like pfsense / opnsense to act as router cum firewall stick in between my Wan port and network switch / wifi bridge/ AP.

Ordered a mini pc and gonna try see which one better. Guess I gonna endup nuke my network or maybe the firewall thingy few times.

Thanks alot.

Looking forward for a robust home lab setup.

10

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.