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.
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.
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.
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
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.
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.