As someone with not a lot of experience regarding SSL and HTTPS, how does adding that routing rule not stop you from visiting any HTTPS site (which is bad)? To my untrained eyes, that's what it looks like. Thanks in advance for someone with more knowledge to teach me.
It only makes the connection for a blocked HTTPS site not time out. The connection is still blocked by Pi-hole. And since only blocked HTTPS connections connect to the Pi-hole, it doesn't affect unblocked HTTPS connections.
As linux N00b
When I tried this on my Raspberry install i'm getting the following error
-bash: /etc/pihole/rules.v4: Permission denied
-bash: /etc/pihole/rules.v6: Permission denied
I did some googling and found the following option working.
sudo bash -c "iptables-save > /etc/pihole/rules.v4"
sudo bash -c "iptables-save > /etc/pihole/rules.v6"
1 Like
You should just be able to append sudo the to front of the original commands.
forgot to paste that part but i used sudo in front of it and that didn't work on my Pi,
Don't know why.
when testing the 2 links
The http link says "var x = "Pi-hole: A black hole for Internet advertisements.""
The https link fails to load the page "this site cant be reached" got no block page.
is this the expected results?
http://secure.quantserve.com/quant.js
https://secure.quantserve.com/quant.js
So i would apply the iptable rules on both rapi that are used for pihole?
Those are the expected results. See that the link goes to a javascript file, so we return some valid but worthless javascript. Apply the iptables rules on your Pi-hole's ports.
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.
Hey all,
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.
iptables -A INPUT -p tcp --dport 443 -j REJECT --reject-with tcp-reset
iptables -A INPUT -p udp --dport 80 -j REJECT --reject-with icmp-port-unreachable
iptables -A INPUT -p udp --dport 443 -j REJECT --reject-with icmp-port-unreachable
If you're using IPv6, match your ip6tables.
Hope this helps someone out there!
Thanks.
2 Likes
I'm trying to understand where to apply these firewall rules. What is the source and the destination of the traffic being rejected?
Just run the commands on the Pi-hole. They apply to the Pi-hole's firewall.
iptables -A INPUT -p tcp --dport 443 -j REJECT --reject-with 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.
iptables -A INPUT -p udp --dport 80 -j REJECT --reject-with icmp-port-unreachable
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.
iptables -A INPUT -p udp --dport 443 -j REJECT --reject-with icmp-port-unreachable
That one is a combination of the two, reject QUIC TLS/SSL/HTTPS traffic.
3 Likes
To break it down a little bit further:
iptables -A INPUT -p tcp --dport 443 -j REJECT --reject-with tcp-reset
iptables is the command, so we are looking at the IPv4 firewall rules.
-A INPUT adds the following rule to the INPUT chain, if you have default settings this will affect all interfaces.
-p tcp targets the TCP protocol.
--dport 443 narrows the rule to only apply to traffic with a destination of port 443, which is the TLS port.
-j REJECT jumps the traffic to the REJECTion chain of rules.
--reject-with-tcp-reset tells the firewall to reply with a reset message instead of just the normal closed message.
2 Likes
Thanks Dan. I've installed iptables on raspbian and this solved all slow site problems for me. Everything very fast now.
1 Like
2 questions arise:
- 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.
1 Like
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.
1 Like
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.
1 Like