Status: active
Logging: on (low)
Default: deny (incoming), deny (outgoing), allow (routed)
New profiles: skip
To Action From
1194/udp ALLOW IN Anywhere
22 ALLOW IN 10.8.0.0/24
53 ALLOW IN Anywhere
22/tcp (OpenSSH) ALLOW IN Anywhere
10.8.0.0/24 ALLOW IN Anywhere
80 ALLOW IN Anywhere
53 (v6) ALLOW IN Anywhere (v6)
80 (v6) ALLOW IN Anywhere (v6)
53 ALLOW OUT Anywhere
80/tcp ALLOW OUT Anywhere
443/tcp ALLOW OUT Anywhere
10.8.0.0/24 ALLOW OUT Anywhere
192.168.1.6 1194/udp ALLOW OUT Anywhere
Anywhere ALLOW OUT Anywhere on tun0
443 ALLOW OUT Anywhere
53 (v6) ALLOW OUT Anywhere (v6)
80/tcp (v6) ALLOW OUT Anywhere (v6)
443/tcp (v6) ALLOW OUT Anywhere (v6)
Anywhere (v6) ALLOW OUT Anywhere (v6) on tun0
443 (v6) ALLOW OUT Anywhere (v6)
You don't need to be a user. When you run the debug log, at the end it will ask if you want to upload the log (Y/N). Answer yes and it will upload to the file server and give you a token. Post that token. You will see something like this - your token will not be the same.
********************************************
********************************************
[✓] ** FINISHED DEBUGGING! **
* The debug log can be uploaded to tricorder.pi-hole.net for sharing with developers only.
* For more information, see: https://pi-hole.net/2016/11/07/crack-our-medical-tricorder-win-a-raspberry-pi-3/
* If available, we'll use openssl to upload the log, otherwise it will fall back to netcat.
[?] Would you like to upload the log? [y/N] y
* Using openssl for transmission.
***********************************
***********************************
[✓] Your debug token is: 72wugm0mlt
***********************************
There is only one problem showing in your debug log
[i] Default IPv4 gateway: 192.168.1.1
* Pinging 192.168.1.1…
[✗] Gateway did not respond. ([Why is a default gateway important for Pi-hole?](https://discourse.pi-hole.net/t/why-is-a-default-gateway-important-for-pi-hole/3546))
But, further down the test for blocking both within the Pi (on the localhost and on the IP of the Pi) are working, as is the ability of the Pi-Hole to contact the Google DNS server.
*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] [count731.51yes.com](http://count731.51yes.com) is 0.0.0.0 via localhost (127.0.0.1)
[✓] [count731.51yes.com](http://count731.51yes.com) is 0.0.0.0 via Pi-hole (192.168.1.6)
[✓] [doubleclick.com](http://doubleclick.com) is 216.58.217.110 via a remote, public DNS server (8.8.8.8)
What is the output of these commands from the Pi terminal:
These results show that your Pi-Hole is/was working in the past 24 hours. The first output is a summary of the activity in the past 24 hours. We have only tested DNS lookups for a domain not likely to be on a block list. Let's run a few more checks.
From the Pi terminal, run these commands for a domain that is on the default block lists.
dig flurry.com
dig flurry.com @1.1.1.1
dig flurry.com @127.0.0.1
Then, from the client that is seeing ads, run (dig or nslookup, depending on your system)
Apologies for the delay - I missed your reply. Here's what those digs and nslookups are telling us:
dig flurry.com should have returned 0.0.0.0, since this is a blocked domain.
dig flurry.com@1.1.1.1 returned the correct address, which is expected. This confirms that the Pi can get to the internet as well.
dig flurry.com@127.0.0.1 (the Pi loopback address) returned the correct result.
The two nslookup commands from your client both show that the clients are not using Pi-Hole for DNS, as the requests went to an OpenDNS resolver directly. This is a configuration problem in your client or router.
Please generate a new debug log, upload it when prompted, and post the token here.