A local-network device should be able to connect to Pi-hole resulting in its queries being resolved and served back. A device on the Tailnet should be able to connect to Pi-hole resulting in its queries being resolved and served back. Devices should be able to connect to locally hosted services (Jellyfin) on both the local network and the Tailnet.
Ubuntu 26.04.1 LTS
Linux 7.0.0-31-generic
Linux Steam-Deck-Ubuntu 7.0.0-31-generic #31-Ubuntu SMP PREEMPT_DYNAMIC Sat Aug 1 04:26:38 UTC 2026 x86_64 (Pi-hole reported kernel)
64-bit
F7A0133 (Firmware version)
Gnome version 50
Steamdeck LCD
Valve Jupiter
AMD Custom APU 0405 × 8
AMD Custom GPU 0405
Installed bare-metal (no docker)
Core v6.4.3
FTL v6.7
Web interface v6.6
Tailscale version 1.102.4 (Pi-hole HOST device)
Android 16 (Tailscale client)
Tailscale version 1.102.3 (Tailscale client)
Additional notes: Tailscale is set to use the Pi-hole tailnet IPv4 as the only global nameserver, and is set to override local DNS and run on exit nodes. MagicDNS is enabled. Pi-hole is configured to permit all origins. The client device is configured to use TailscaleDNS. This setup was working seemingly without issue for several weeks. It was only within the past couple of days that Pi-hole stopped serving Tailscale clients. If it's relevant around this time I attempted to install nextcloud via snap, but abandoned this project and subsequently deleted nextcloud (I never made it past downloading/installing for what it's worth).
Actual Behaviour:
Local-network devices are able to connect to and use the Pi-hole for DNS with seemingly no issue. Both websites on the open internet and locally hosted services (Jellyfin) seem to work fine. Tailnet device(s) are able to ping the Pi-hole and the logs show queries being handled from said device(s) (by Tailnet IP), but only locally hosted services (Jellyfin) are reliably available.
Note from the editor: I'm sure I'm missing some info that is vital to you guys so please feel free to ask.
ETA:
Apologies for the long wait, I've been busy with work/school. I re-ran "pihole -d" and perused the generated log, where I saw that DNS traffic wasn't being allowed. I ran the following 2 commands: "sudo firewall-cmd --permanent --zone=public --add-service=DNS" & "sudo firewall-cmd --permanent --add-service=dns", along with "sudo firewall-cmd --reload" and most of my issues are resolved. I was getting a local rate-limiting issue but I'm pretty sure I've resolved that by disabling the problematic service: geoclue. I'm not sure why but it was attempting to make hundreds of queries a second, which tripped the rate-limiting protection. I'm still having an issue where no devices other than the local host itself can connect to the admin dashboard, but frankly as long as the dns is working for everyone and everything connected I'm a happy camper.
on the host, make sure FTL is actually listening on the tailscale IP, not only LAN. Listen on all interfaces / permit all origins is a start, but confirm bind:
ip -4 addr show tailscale0 ss -ulnp | grep :53
from the android client try: nslookup google.com <pihole-tailscale-100.x-ip>
if that times out its routing/ACL, not pihole lists. Tailscale ACLs need UDP/TCP 53 to the pihole node, and the android global nameserver has to be the pihole 100.x address (not the LAN IP). exit-node hairpins also break this for me when override local DNS is on.
I'm not entirely sure how to interpret the output from your first set of commands, but I am noticing a lack of the tailscale IP in the list. Output for first command as follows:
jacob-strong@Steam-Deck-Ubuntu:~$ ip -4 addr show tailscale0
ss -ulnp | grep :53
6: tailscale0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc fq_codel state UNKNOWN group default qlen 500
inet 100.69.1.109/32 scope global tailscale0
valid_lft forever preferred_lft forever
UNCONN 0 0 0.0.0.0:53 0.0.0.0:*
UNCONN 0 0 0.0.0.0:5353 0.0.0.0:*
UNCONN 0 0 [::]:53 [::]:*
UNCONN 0 0 [::]:5353 [::]:*
On Android (over cellular while connected to tailscale) the output is as follows, and if I'm reading it correctly it's a success:
yeah that output is actually fine. FTL listening on 0.0.0.0:53 covers the tailscale IP, and android resolving google.com when you point nslookup at 100.69.1.109 means the pi-hole path works.
if normal browsing on the phone still fails while that nslookup works, Tailscale is probably still handing the phone a different DNS. force Global nameservers to only 100.69.1.109, flip Override local DNS off once to test, and if you use an exit node try without it. jellyfin working while random sites fail is usually that split.
The tailnet should only be using the Pi-hole as it's DNS. I've tried on both local wifi and cellular, and when tailscale is enabled it fails in usual fashion. This is regardless of whether "Override DNS servers" is enabled or not in the admin panel.
if nslookup against 100.69.1.109 works but browsing still dies with tailscale on, check whether the browser is skipping system dns.
android firefox has its own dns over https. settings → privacy → dns over https → set it Off so it uses the tailscale/pi-hole resolver.
then try chrome or a termux dig/nslookup the same way. if those work while firefox fails, its DoH, not pi-hole.
if every app fails with DoH off, open http://100.69.1.109/admin from the phone. if that loads, routing is fine and something is still hijacking dns for browsers. also say whether the phone is on an exit node when it breaks.
