Update: 2018-08-06
As of v4.0, this should no longer be a problem unless you choose to deviate from the new default blocking mode and return to the IP-based mode. And the
iptablesrules mentioned in this article should not be needed.
Update
As of v3.1 the first reason should not be an issue anymore
That being said, there are generally two reasons this happens:
-
your ISP changes your IPv6 address (Global Unicast Address), causing Pi-hole to become misconfigured and timing out when trying to load a page.
-
a domain is requested over port 443 (HTTPS/SSL) and times out since Pi-hole doesn't currently respond to HTTPS requests
Resolving these issues
1. Use ULA or edit setupVars.conf
As of v3.1 this (IPv6) should not be an issue.
You can look for a setting in your router to enable ULA (Unique Local Address). This is the best solution.
If your router does not have this setting, you can edit setupVars.conf with the correct IP address and update the ad block lists. Below is a script that should do this for you:
IPV6_ADDRESS=$(ip -6 a | grep 'fc\|fd' | awk -F " " '{gsub("/[0-9]*",""); print $2}')
echo ${IPV6_ADDRESS}
sed -i.setupVars.bak "/IPV6_ADDRESS/d;" "/etc/pihole/setupVars.conf"
echo "IPV6_ADDRESS=${IPV6_ADDRESS}" >> "/etc/pihole/setupVars.conf"
pihole -g
2. Setup HTTPS firewall rules
There is a good reason we don't currently support HTTPS:
HTTPS requires a certificate that matches the domain name in order to be valid. It's difficult to enable that for the Pi-hole pages. It would be considered a form of a Man-In-The-Middle attack as we would be impersonating the encrypted communications between the browser client and the end server, which should be encrypted from client to server.
Technical users may be able to set this up with a self-signed certificate themselves, but it's not something we want to do on a clean installation
Users have also had success blocking TCP/UDP port 443 so it denies the request instead of waiting to timeout. Similarly, QUIC uses UDP (as described here) so that is blocked as well.
iptables -A INPUT -p tcp --destination-port 443 -j REJECT --reject-with tcp-reset
iptables -A INPUT -p udp --destination-port 80 -j REJECT --reject-with icmp-port-unreachable
iptables -A INPUT -p udp --destination-port 443 -j REJECT --reject-with icmp-port-unreachable
ip6tables -A INPUT -p tcp --destination-port 443 -j REJECT --reject-with tcp-reset
ip6tables -A INPUT -p udp --destination-port 80 -j REJECT --reject-with icmp6-port-unreachable
ip6tables -A INPUT -p udp --destination-port 443 -j REJECT --reject-with icmp6-port-unreachable
Some users have reported that these rules do not work on Windows machines, but these very similar commands below will:
iptables -A INPUT -p tcp --dport 443 -j REJECT --reject-with tcp-reset
ip6tables -A INPUT -p tcp --dport 443 -j REJECT --reject-with tcp-reset
The tcp-reset option will tell REJECT to send a TCP RST packet in reply to the sending host. TCP RST packets are used to close open TCP connections gracefully.
To save your firewall rules to persist across reboots, run
iptables-save > /etc/iptables/rules.v4
ip6tables-save > /etc/iptables/rules.v6
Test HTTPS Blocking Performance
You may want to check if HTTPS is timing out or not after making the firewall changes. A good test can be found here.
