Since I'm seeing the expected results then I should not need to add those commands? I have also disabled ipv6 on my router.
I've had an odd issue, from time to time a few pages stall for a minute then goes to the chrome dns error page for a quick 3 seconds and then page loads.
At first I thought it was my wifi as no wired issues have had this issue, but now I'm thinking it maybe more of an android issue with pihole and ipv6. I've seen request in pihole even though I have ipv6 disabled.
If https sites do not stall every time, then you are ok.
You can't quite disable IPv6 on a network because it's designed to not need a central server like a router (at least for link-local addresses). Also, DNS requests can be made over IPv4 or IPv6 for either an IPv4 or IPv6 answer, the protocol of the request doesn't matter.
I was struggling with intermittent slow-loading for a while too and finally found my solution.
Some sites (ex: www.googletagservices.com) are starting to use the QUIC protocol, which functions over UDP.
Blocking 80/443 UDP takes care of that, and TCP is best served with a tcp-reset.
This rule sets up on the INPUT chain, all TCP traffic on port 443 (TLS/SSL/HTTPS) will get a message that the port is not available and will be sent a reset packet. This helps with slow loading of SSL/TLS pages since the client won't be waiting for a reply, the will get an immediate closed and will not be open message.
This is another INPUT chain rule, but this is a new one. The QUIC protocol sends over UDP as opposed to what we normally see as TCP traffic. So to block the QUIC and it's DNS traffic over QUIC, this rule sets another rejection notice to the client. It tells the client that QUIC is not available and ends the process.
Are there any drawbacks (e.g. package/system updates not working)?
Could it be integrated in future releases? Because it's not obvious and really annoying if you don't know why certain sites load really slow...and took me a long time to get here.
Updates would only break if you have the repository address on your blocklist. This just adds a different response to the denied rejection. And as to inclusion on future updates, possibly. I really don't like setting firewall rules for users and getting in to their system security, then it makes us responsible for their firewalls if something should happen to their systems. I know we set firewall rules already but that's not something I really like doing. But I'm not the only developer on the team and we go by team consensus for things, so it's not outside the realm of possibility. This is already in the FAQ section but if it's something that is really useful we can see about a blog post publicizing it more.
I think you do need a blog post for these slow downs, now thinking back i've had random slow downs for at least a year.
My issue was mainly with wifi devices randomly having issues, so it took me a very long time with the process of elimination on my network gear. I didn't think it was pihole since wired devices never had issues and if they did it went unnoticed.
Anyways long story short i guess went i setup pihole i gave it a static ip outside my dhcp and then at a later date changed it, in some of the conf files it was still referencing the old ip address. Since correcting this I've not had any issues, google searches still stall a little but its not noticeable unless you really pay attention.
Thanks! I had this issue too. Weirdly, your: sudo bash -c "iptables-save > /etc/pihole/rules.v4" command works, but when I try the V6 version I get the following:
-bash: /etc/pihole/rules.v6”: Permission denied
I should note that I don't have the ULA option on my router, and I'm using PiHole as my DHCP server with IPv6 support disabled... Guess that might have something to do with it?
I also do not have IPv6 enabled and my router does not have the ULA option (infact in my router i have IPv6 disabled completely) - but I am activating the rules in order to see if it assists with the slow loading of some websites, without enabling ULA since I do not see an option for it in my router.
Great! Weirdly, I'd been trying to reply to aws1971. I realised the reason the commands I was trying weren't working was because the v6 version was getting pasted into Putty with italic quotes?! No idea how I managed that, but both now saved using aws1971's version:
and was quoted if I want to save the current settings. This was the only way I managed to get the rules persistent. You can check the currently used rules with
I'm running Pi-hole 3.3 and my router has ULA enabled however I still have this issue. I have tried the iptables solutions posted but this made no difference. In the end I just copied and pasted the ULA from my router config page into setupVars.conf which has solved it for now.