search

DesktopECHO / Pi-Hole-for-WSL1

Ad-blocking DNS server for Windows • Unbound pre-configured • Deployment ready in minutes • Does not require hypervisor/docker
365 stars 54 forks source link

Nothing is getting resolved #115

Closed swindlesmccoop closed 8 months ago

swindlesmccoop commented 8 months ago

When I set my DNS to the address of the server 127.0.1.1, I can see on the dashboard that it is receiving the requests and where everything is going and whatnot, however, nothing is actually getting resolved.

Yes, I have set upstream DNS servers: image

I have a few ideas as to what may be causing the issue from debug logs:

*** [ DIAGNOSING ]: Operating system
[i] Distro: Debian
[i] Version: 11
[✗] dig return code: 10
[✗] dig response: dig: couldn't get address for 'ns1.pi-hole.net': failure
[✗] Error: dig command failed - Unable to check OS
*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] toolbar.wips.com is :: on eth1 (fe80::1140:1c09:be69:1474)
[✓] toolbar.wips.com is :: on eth2 (fe80::1f76:7ba6:8ac5:8b6a)
[✓] toolbar.wips.com is :: on lo (::1)
[✓] toolbar.wips.com is :: on eth3 (fd7a:115c:a1e0::d5e7:8203)
[✗] Failed to resolve toolbar.wips.com on eth3 (fe80::d8ff:5060:f230:9168)
[✓] toolbar.wips.com is :: on wifi0 (fe80::4f2b:fbe4:d33:85c0)
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (2001:4860:4860::8888)

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   Timeout: 10 seconds
   Error: Could not bind socket to interface wifi0 (Protocol not available)

For the record, I am using wifi and only have one adapter.

*** [ DIAGNOSING ]: Pi-hole-FTL full status
[i] systemctl:  command not found
*** [ DIAGNOSING ]: contents of /etc/lighttpd/conf.d
/etc/lighttpd/conf.d does not exist.

This one doesn't seem particularly important but figured I would include it just in case.

DesktopECHO commented 8 months ago

Hello, it would be best to start with a clean, default setup. Uninstall and re-install should only take a few minutes. The installer by default should have configured an upstream DNS, the Unbound daemon listening on 127.0.0.1#5353

You mentioned you only use the WiFi adaptor, but what are eth0 to eth3? Temporarily disable these adaptors in Windows before you do a clean install, and verify Pi-hole is working properly before re-enabling the adaptors.

swindlesmccoop commented 8 months ago

The eth adapters were all virtual as far as I could tell aside from the motherboard port. I disabled and reinstalled everything and ran completely stock config and still got the following:

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   Timeout: 10 seconds
   Error: Could not bind socket to interface wifi0 (Protocol not available)

And once again, only changing the upstream DNS servers, while PiHole is receiving the queries, nothing is actually getting resolved.

I think I may be using WSL2 - would that affect anything?

DesktopECHO commented 8 months ago

And once again, only changing the upstream DNS servers, while PiHole is receiving the queries, nothing is actually getting resolved.

I don't understand, did you change the upstream DNS after your clean install, and if so, why?

The log output you posted is just for DHCP discovery, not really related to your issue. Run the following command to open a bash shell on the Debian/Pi-hole instance:

"C:\Program Files\Pi-hole\LxRunOffline.exe" r -n Pi-hole

What's the kernel version reported by uname -a To verify Internet access, when you run ping 8.8.8.8 in the bash session, do you get a reply?

swindlesmccoop commented 8 months ago

did you change the upstream DNS after your clean install, and if so, why?

I did, that way I can use Google to resolve domain names. Should I not have? I reinstalled and the same thing happens regardless of whether or not I enable the upstream.

What's the kernel version reported by uname -a To verify Internet access, when you run ping 8.8.8.8 in the bash session, do you get a reply?

C:\Users\Swindles>"C:\Program Files\Pi-hole\LxRunOffline.exe" r -n Pi-hole
root@SWINBLOWS:/mnt/c/Users/Swindles# uname -a
Linux SWINBLOWS 4.4.0-19041-Microsoft #3996-Microsoft Thu Jan 18 16:36:00 PST 2024 x86_64 GNU/Linux
root@SWINBLOWS:/mnt/c/Users/Swindles# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=109 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=109 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=108 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=108 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=117 time=156 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=117 time=112 ms
^C
--- 8.8.8.8 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5004ms
rtt min/avg/max/mdev = 107.796/116.910/156.205/17.617 ms
DesktopECHO commented 8 months ago

The installer by default should have configured an upstream DNS, the Unbound daemon listening on 127.0.0.1#5353

I did, that way I can use Google to resolve domain names. Should I not have? I reinstalled and the same thing happens regardless of whether or not I enable the upstream.

Everything is supposed to "just work" in a standard installation, where the upstream DNS server is set to 127.0.0.1#5353. This is the Unbound service, which upstreams DNS to CloudFlare and Quad9 DNS-over-TLS. You should be able to verify this entry exists in the 'Custom' Upstream DNS section of the Pi-hole web interface. Leave it alone for now until things work properly, afterwards you can tweak your setup as much as you like.

You're showing a 4.x kernel, that's what we're expecting for WSL1. You can ping 8.8.8.8 from the Pi-hole instance, that's good too.

Let's see if DNS is working directly from the Pi-hole instance. With a clean, unmodified install, open a bash prompt on the Pi-hole: "C:\Program Files\Pi-hole\LxRunOffline.exe" r -n Pi-hole

What's the output from from: dig google.com @127.0.0.1 +short ...also check Google DNS as a sanity check: dig google.com @8.8.8.8 +short ...and let's see if there's anything interesting in the log files: grep -riE 'err|fail' /var/log/pihole

swindlesmccoop commented 8 months ago 
C:\Users\Swindles> "C:\Program Files\Pi-hole\LxRunOffline.exe" r -n Pi-hole
root@SWINBLOWS:/mnt/c/Users/Swindles#  dig google.com @127.0.0.1 +short
142.250.80.78
root@SWINBLOWS:/mnt/c/Users/Swindles#  dig google.com @8.8.8.8 +short
172.253.122.100
172.253.122.102
172.253.122.101
172.253.122.138
172.253.122.139
172.253.122.113
root@SWINBLOWS:/mnt/c/Users/Swindles#  grep -riE 'err|fail' /var/log/pihole
/var/log/pihole/FTL.log:[2024-03-20 12:49:43.262 14346/T14365] gravityDB_count(SELECT value FROM info WHERE property = 'gravity_count';) - SQL error step no more rows available
/var/log/pihole/pihole.log:Mar 20 12:49:43 dnsmasq[14346]: failed to load names from /etc/pihole/local.list: No such file or directory
DesktopECHO commented 8 months ago

C:\Users\Swindles> "C:\Program Files\Pi-hole\LxRunOffline.exe" r -n Pi-hole root@SWINBLOWS:/mnt/c/Users/Swindles# dig google.com @127.0.0.1 +short 142.250.80.78

Ok, Pi-hole is working.
Does that lookup appear in the Pi-hole query log?

Now try in Windows, does nslookup google.com 127.0.0.1 work?
If that works, replace 127.0.0.1 with the IP address of your Windows machine and see if you get a reply. Next, try running nslookup from another computer on your network to verify Pi-hole is running properly.