Pi Hole - network-wide ad blocking
-
Pi-Hole on Cloudron is useless IMHO for only internal "filtering".
Only in combination with a VPN like WireGuard it's a perfect combination to be online, outside of your 'safe home wifi', without sniffing of mobile providers proxies and "free open wifi", and with a kind of safetynet by Pi-Hole.
@luckow yes I do have a RaspberryPi with Wireguard AND Pi-Hole at home, but as an extra "external" backup its very welcome (and very easy) to have Pi-Hole+WireGuard in a Cloudron app.
-
Actually, one could do this (if you know what you're doing) by offering the pihole externally. In order to be safe, you would want to make sure to whitelist ONLY the IPs coming in to connect to it you intend to allow, otherwise you open your self up to DNS hijacking. I do this now by exposing a pihole on Azure that only my home router can connect to. Works great. FWIW, I took a look at packaging pihole the other day, cause of my use case. It looks...possible, but there are a LOT of moving parts and it really wants some pretty low level access, so, challenges will persist.
-
Pi-Hole on Cloudron is useless IMHO for only internal "filtering".
Only in combination with a VPN like WireGuard it's a perfect combination to be online, outside of your 'safe home wifi', without sniffing of mobile providers proxies and "free open wifi", and with a kind of safetynet by Pi-Hole.
@luckow yes I do have a RaspberryPi with Wireguard AND Pi-Hole at home, but as an extra "external" backup its very welcome (and very easy) to have Pi-Hole+WireGuard in a Cloudron app.
@imc67 @doodlemania2 Right now I am using this setup on a separate, cloud hosted VM. Wireguard and Pihole, configured so that the system can only be accessed over VPN, not by external parties. Works beautifully and would be so cool, if this was working on Cloudron.
Excellent idea and request. Thanks for bringing this up.
-
Currently, what is holding back pi-hole is a couple of Cloudron limitations:
-
Cloudron reserves port 53 (dns) on the server. Have to fix unbound to listen only on internal interfaces (we listen on 0.0.0.0 and rely on firewall and access control policies to block requests).
-
Some IP based firewall as @savity has been requesting in another thread. This is required to block requests to pi-hole to just your machines/network.
-
-
Currently, what is holding back pi-hole is a couple of Cloudron limitations:
-
Cloudron reserves port 53 (dns) on the server. Have to fix unbound to listen only on internal interfaces (we listen on 0.0.0.0 and rely on firewall and access control policies to block requests).
-
Some IP based firewall as @savity has been requesting in another thread. This is required to block requests to pi-hole to just your machines/network.
-
-
yeah i mean it would be for me
i would never create pihole acessable for others its for private reasons vpn+pihole. So pihole would be listening, lets say on 10.9.0.0Maybe in the future the idea could to configure other apps only availaie in the same VPN Network
-
@imc67 indeed. If we bundle them together, it's not a problem. Is this the "preferred" way to package pi-hole?
-
-
@savity couldn’t agree more. For me it would be a killer feature. And would make for a nice campaign on Twitter, Reddit et. all. Just look how many people google this and try to establish it manually....this is a mainstream feature, that would be appreciated by the entire user base, much more than specific applications that appeal only to certain users.... my opinion
-
@imc67 indeed. If we bundle them together, it's not a problem. Is this the "preferred" way to package pi-hole?
-
Haha, Pie Hole / Cake Hole is British for your mouth, as in; shut your pie hole
-
Haha, Pie Hole / Cake Hole is British for your mouth, as in; shut your pie hole
-
@marcusquinn
Pi-hole, not Pie hole@Hillside502 3.14159265359... hole
-
How is the progress here?
-
How is the progress here?
-
Last I checked it was quite tricky to deploy pi-hole with docker. Does anyone have experience with this style of deployment? It was really made like a "distribution"/"OS" instead of a separate app.
@girish It's pretty straightforward as far as I can tell. I've got two instances hosted via Docker on Raspberry Pis at my home.
I agree with folks above suggesting though that it'd be best to expose only to internal services and likely inside a VPN. There is probably a decent way to do this in a single app, but I wonder if there is value in creating a new way to expose particular Apps to other apps via a shared network.
This would allow exposing a Pi-Hole app that has no "public" ports to any VPN app (OpenVPN, Wireguard, etc) with an internal hostname (app name?).
-
@iamthefij So, let's say the VPN app had a way to set a custom name server and one could just edit some file and set it to the pi-hole app, would this be good enough already? Given that the OpenVPN app is custom anyway, we can even add a simple UI that allows a user to set the DNS server IP (as you say, this might be the internal host name since IP might be dynamic actually).
This seems quite doable.
