Requests to blocked domains are rejected immediately and the webpage is loaded within a reasonable amount of time.
Actual Behaviour:
When visiting a website with blocked ads, blocked requests hang for 1-2min before timing out. During this time they render-block the webpage.
Debug Token:
6cmybo8i2p
Specifics:
No response is sent at all and the request is failed. screenshot
Attempting to connect to a blocked domain via browser does not immediately resolve to the Pi-Hole, instead eventually returning a connection failed error.
I am using Pi-Hole on a Raspberry Pi connected to Google OnHub over WiFi. The Pi-Hole works - ads are blocked, and the logs indicate that it is properly detecting blocked domains and filtering them. It is just not returning the proper response. IPV6 is not turned on.
The Raspi is running Raspbian GNU/Linux 9.
This happens on all devices - Macbook, Windows PC, Android, etc. and on both HTTP and HTTPS.
I have tried adding rules to the firewall on the Raspberry Pi to reject from port 443, as recommended here (which every search result seems to link to). This is the output of iptables:
I've tried updating and restarting both gravity and DNS on Pi-Hole, upgrading everything on apt-get, restarting the Wi-Fi point, restarting the Raspberry Pi, and I've added the iptables configuration to /etc/rc.local.
Anyone have ideas as to what might be going wrong? I don't have the technical experience to fully understand everything that's going on under the hood.
If you open further details of one of the failed requests (try e.g. double-clicking one of the entries), does anything meaningful come up?
Unfortunately, it seems that up till now all developers have not been able to engineer this situation at home. I know some are using Windows, I'm only using Linux so it may still be an issue with e.g. custom antivirus or firewall, but as you have the issue also on other devices (as Mac), it seems not very likely.
Although connecting the Pi-hole via WiFi is explicitly not recommended, I doubt it will be the issue here.
My conclusion, so far, would be the following: You have a firewall issue going on. Hold on, I know what you wrote and I have also seen which parts of the text are in bold face, but still, what you describe seems to indicate that your computer never receives the REJECT from your Pi-hole. It is just not clear where this fails. It could be your computer, it could be the router or it could be the Raspberry.
As a first step, please try
nmap --reason pi.hole -p443 # for TCP
sudo nmap --reason pi.hole -p443 -sU # for UDP
With and without the iptables rules you posted above, I get:
PORT STATE SERVICE REASON
443/tcp closed https conn-refused
PORT STATE SERVICE REASON
443/udp closed https port-unreach ttl 64
As for the nmap, I wasn't sure where to run the commands from, so I ran it from both a macbook and the pi-hole. Both the macbook and the pi-hole returned something like this:
Starting Nmap 7.60 ( https://nmap.org ) at 2018-01-16 18:06 PST
Stats: 0:00:01 elapsed; 0 hosts completed (0 up), 1 undergoing Ping Scan
Ping Scan Timing: About 50.00% done; ETC: 18:06 (0:00:01 remaining)
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.12 seconds
Starting Nmap 7.60 ( https://nmap.org ) at 2018-01-16 18:06 PST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.17 seconds
I tried running it again with -Pn, not sure if useful:
pi@Pihole:~ $ nmap --reason pi.hole -p443 -Pn # for TCP
Starting Nmap 7.40 ( https://nmap.org ) at 2018-01-17 02:12 UTC
Nmap scan report for pi.hole (192.168.1.124)
Host is up, received user-set.
rDNS record for 192.168.1.124: Pihole
PORT STATE SERVICE REASON
443/tcp filtered https no-response
Nmap done: 1 IP address (1 host up) scanned in 2.26 seconds
pi@Pihole:~ $ sudo nmap --reason pi.hole -p443 -sU -Pn # for UDP
Starting Nmap 7.40 ( https://nmap.org ) at 2018-01-17 02:14 UTC
Nmap scan report for pi.hole (192.168.1.124)
Host is up, received user-set.
rDNS record for 192.168.1.124: Pihole
PORT STATE SERVICE REASON
443/udp open|filtered https no-response
Nmap done: 1 IP address (1 host up) scanned in 2.38 seconds
So the conclusion from these outputs is that your firewall rule - although being present - is not visible from your computer! See:
(let's for now concentrate on TCP, as this is more likely the cause of your problem). An interesting question: Who is responsible for that your PC doesn't get the REJECT packet from your Pi?
I'm afraid that there might be no fast way of detecting this, but let me just summarize my thoughts below, maybe you find something in them you want to test:
You have a firewall properly configured on the Pi to REJECT port 443.
I see basically five possibilities for something to "get lost":
Your computer does not even send it out (may be a software issue with an installed firewall, etc.)
The request gets lost in transport from your computer to the Raspberry (may be the router)
Your Raspberry does not react accordingly and doesn't send out the REJECT packet, although you explicitly configured iptables to do that.
The response gets lost in transport from the Raspberry to the computer
Your computer ignores the response and somehow discards it
"1." and "5." seem similarly unlikely as you report that is happens with several clients running different operating systems,
"2." and "4." seem a bit unlikely, but would at least make sense as it would affect all clients. As you have a transition between WiFi <-> wired Ethernet, the router can have an impact and this possibility should not be taken too lightly.
Finally, "3." seems quite unlikely in itself (that would mean either that there is an issue with the WiFi interface or that there is an issue with iptables). I don't run Raspbian Stretch on any device (still Jessie), but I'll try to test this over the coming days.
Just one side note: Please confirm that the (static?) IP address of your Pi-hole is 192.168.1.124.
Can you try to
a) switch to wired networking for the Pi (you should be able to still use the same static IP when disabling WiFi on the Raspberry) to reduce the likeliness of that the router is messing around with your packets?
b) maybe configure static IPs also for your computer and connect them directly (w/o the router in between) to see if it works correctly when there is no device in between computer and Raspberry?
We've never been able to get pi-hole to work on a wired connection (the OnHub doesn't detect the pi as a device) and still haven't been able to after many failed attempts today. Ultimately this looks more and more like just a problem with the setup of the network as well as a lack of understanding of networking / raspberry pi in general, and less to do specifically with Pi-hole.
Thanks for your time, but it seems like the problem is unrelated to this forum. This is basically resolved, I guess.
This is very strange (concerning its Ethernet port, a Raspberry should not be any different from a "regular" PC) but it doesn't seem to be too unlikely that it is messing around with other networking stuff as well then.
If you can a hold of a router that is working as expected, we can continue this (if the issues still persists with the new device).
