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.
This is actually what you are supposed to do, but I see that bit of information is difficult to discern from the OP. I will update that. When you add it to your setupVars.conf, that address will be used next time you update the ad lists, and thus used by your Pi-hole, preventing the timeouts.