I present an alternative way to use Pi-hole outside the home network by leveraging Encrypted DNS (aka DNS-over-TLS and DNS-over-HTTPS) instead of the usual VPN.
For me its been wireguard with split tunnel but that had a glaring issue with my home IP change (running 2 Pi-hole+unbound instances on separate network segments and hardware).
Some time ago I switched to tailscale and added a Pi-hole on a VPS. Closed system, nothing exposed to the wide internet, works 99.99…% of the time, whole family protected against low hanging fruit attacks and adds.
I do exactly this as well. Works great! Dynamic DNS is kind of a hilarious hack.
Quick question: since I use wireguard, do I need to use DNS-over-HTTPS for security? My assumption is that my entire session is already encrypted with my wireguard keys, so it doesn’t matter. But I figured I should double check.
Depends, do you have pihole/unbound setup to only recursively resolve? Or do you forward requests to an upstream (either as a fallback or just as a primary). If that’s the case, and depending on your threat model, you’ll want to set up DoH or DoT as your DNS requests will be forwarded in plaintext
Fortunately I set up unbound ages ago, and disabled every other upstream option in my pi.hole. However, I imagine that still “leaks” some information about my DNS queries, just indirectly – it’s not like my pi.hole has every domain mapped all the time!
Excellent to have confirmation, thanks. What about the VPN connection handshake? I always assumed it was OK over non-SSL, because the exchange should use signed keys. But that is quite an assumption on my part.
Wireguard uses public and private keys which are designed from the ground up to be used over plain text to establish the handshake so it isn’t an issue. Same idea with ssh keys and ssl keys
I have ddns on Cloudflare.
It works great, until your home IP changes.
After that wireguard will happily hammer the old IP, till something breaks the tunnel and it reestablishes it to the new IP.
Working as intended.
My workaround was forcing the IP change over night while everyone was home.
It may since have been fixed, but the Android client didn’t handle IP changes well in my experience. From my understanding, it only checks DNS when it initially connects, and so if the public IP changes the connection just stops working. This might be fine if the public ip changes infrequently or if you frequently connect and disconnect rather than leave the client always on, but not so much otherwise.
Tailscale (and headscale) handles this gracefully, and you also get the nice NAT traversal features so no need to worry about CGNATs which are becoming more common.
From my understanding, it only checks DNS when it initially connects, and so if the public IP changes the connection just stops working.
This is pretty standard TCP network behavior for long duration connections. The client queries dns for the IP address, opens a socket, and leaves it open as long as needed.
One thing that would help here is some kind of keepalive feature, like a client to server TCP connect or SYN, or better yet a higher level protocol signal. Check your client to see if there is some tunable keepalive. It may be set so something long like 1h.
For me its been wireguard with split tunnel but that had a glaring issue with my home IP change (running 2 Pi-hole+unbound instances on separate network segments and hardware). Some time ago I switched to tailscale and added a Pi-hole on a VPS. Closed system, nothing exposed to the wide internet, works 99.99…% of the time, whole family protected against low hanging fruit attacks and adds.
Use ddns on your router with a domain so you can then get something like wireguard.example.com and then use that as the endpoint in your wireguard.
Set the wireguard DNS as your pihole.
To make life easier set your home network IP space to something that another WiFi would never use, ie 192.168.46.xx
That way it will never conflict if you are on a public WiFi and you can access anything on your home lab when you need.
I’ve been using this setup for years on laptop, phone etc
I do exactly this as well. Works great! Dynamic DNS is kind of a hilarious hack.
Quick question: since I use wireguard, do I need to use DNS-over-HTTPS for security? My assumption is that my entire session is already encrypted with my wireguard keys, so it doesn’t matter. But I figured I should double check.
Depends, do you have pihole/unbound setup to only recursively resolve? Or do you forward requests to an upstream (either as a fallback or just as a primary). If that’s the case, and depending on your threat model, you’ll want to set up DoH or DoT as your DNS requests will be forwarded in plaintext
Fortunately I set up unbound ages ago, and disabled every other upstream option in my pi.hole. However, I imagine that still “leaks” some information about my DNS queries, just indirectly – it’s not like my pi.hole has every domain mapped all the time!
You do not need anything else. DNS requests are all sent over Wireguard with encryption
Excellent to have confirmation, thanks. What about the VPN connection handshake? I always assumed it was OK over non-SSL, because the exchange should use signed keys. But that is quite an assumption on my part.
Wireguard uses public and private keys which are designed from the ground up to be used over plain text to establish the handshake so it isn’t an issue. Same idea with ssh keys and ssl keys
Thanks. Wild that folks build SSH and HTTP around the same time without realising that HTTP could benefit from some of that same tech!
At the time, everything HTTP was supposed to be public.
I have ddns on Cloudflare. It works great, until your home IP changes. After that wireguard will happily hammer the old IP, till something breaks the tunnel and it reestablishes it to the new IP. Working as intended. My workaround was forcing the IP change over night while everyone was home.
Tailscale sorts all the issues I had.
Whats the issue with the Home IP changing? - Have you setup a DynDns hostname?
It may since have been fixed, but the Android client didn’t handle IP changes well in my experience. From my understanding, it only checks DNS when it initially connects, and so if the public IP changes the connection just stops working. This might be fine if the public ip changes infrequently or if you frequently connect and disconnect rather than leave the client always on, but not so much otherwise.
Tailscale (and headscale) handles this gracefully, and you also get the nice NAT traversal features so no need to worry about CGNATs which are becoming more common.
This is pretty standard TCP network behavior for long duration connections. The client queries dns for the IP address, opens a socket, and leaves it open as long as needed.
One thing that would help here is some kind of keepalive feature, like a client to server TCP connect or SYN, or better yet a higher level protocol signal. Check your client to see if there is some tunable keepalive. It may be set so something long like 1h.
Wireguard uses UDP, by the way.
https://www.wireguard.com/protocol/
Wireguard does have a KeepAlive option, but I found it didn’t seem to help in practice.
Could be bugs with the client, which is pretty barebones.
that’s how it works on desktop too regarding DNS, but when it receives a response from a new IP, it should send future traffic there as I know
It will resolve the IP from the domain when the tunnel goes up and will keep using that one. Working as intended.
Overlay networks solve that issue.