The Tech Pulse

February 3, 2026•9 min read•
Tags ▼
  • Hole
  • Tailnet
  • Tailscale
  • Pihole
  • Devices
  • Https
  • Technitium
  • Based
  • Today
  • Video
•
Share ▼

Adblock for your Tailnet with Pihole anywhere you go!

One Sentence Summary

How to set up Pi Hole behind TailNet for global ad-blocking, with per-client metrics and flexible deployment options.

Main Points

  • Use Pi Hole inside a VM or VM on Proxmox for TailNet DNS.
  • Pi Hole blocks ads at DNS level via known domain lists.
  • Static IP in DHCP is crucial for reliable Pi Hole access.
  • Upstream DNS can be Cloudflare; any provider works, based on comfort.
  • Enable Pi Hole DNS to listen on TailScale interfaces (expert mode, permit all origins).
  • Add Pi Hole as a TailNet device; optional DNS tag and ACL workflow.
  • Set a strong Pi Hole password for admin access.
  • Override TailScale DNS servers to route all queries through Pi Hole.
  • DNS queries map TailNet clients to specific TailScale IPs for visibility.
  • Alternatives exist (Adguard Home, Technitium) with pros/cons; Pi Hole remains proven.

Takeaways

  • Start with a simple Pi Hole VM setup and connect it to TailNet for global ad-blocking.
  • Ensure Pi Hole has a static IP within your LAN for stable DHCP mapping.
  • Use TailScale DNS override to force all devices to use your Pi Hole as the resolver.
  • Be aware of potential security trade-offs when enabling “permit all origins” in Pi Hole.
  • Consider alternative DNS blockers (Adguard Home, Technitium) for redundancy or clustering.

SUMMARY

This video shows how to deploy Pi-hole as a private, always-on DNS ad blocker for your Tailscale tailnet so every connected device gets ad-blocking anywhere. The main skill is installing Pi-hole on a Linux host (VM/physical/VPS), then configuring Pi-hole to accept requests over the Tailscale interface and setting it as a custom nameserver in the Tailscale admin console. The primary tools are Pi-hole (DNS sinkhole) and Tailscale (mesh VPN + centralized DNS configuration). (Tailscale)

DETAILED STEP-BY-STEP BREAKDOWN (chronological, reproducible)

Prerequisites (hardware/software)

  • A host to run Pi-hole:
    • VM on Proxmox (as shown), or
    • Raspberry Pi Zero 2 W, or
    • VPS locked down to private access via Tailscale.
  • A Linux server VM (the video uses Linux; examples imply Ubuntu).
  • Network access to the Pi-hole admin UI (local LAN).
  • A working Tailscale tailnet and access to the Tailscale admin console.

Step 1 — Create/choose the Pi-hole host and assign a static LAN IP

  1. Create a VM (or pick hardware) that will act as your DNS node.
  2. Assign it a static LAN IP (video example: 192.168.1.53).

Why this matters

  • Pi-hole must not change IP on your LAN, or devices won’t reliably find your DNS server.

Common mistakes

  • Leaving DHCP defaults → the Pi-hole IP changes after reboot and DNS breaks.
  • Choosing an IP that conflicts with another device.

Step 2 — Install Pi-hole on the host (SSH in)

  1. SSH into the DNS node.
  2. Run the Pi-hole installer (video says “copy one command from docs”).

Typical official install method is the Pi-hole installer script (commonly “curl pipe to bash”). This approach is widely used but has security tradeoffs; review before running. (GitHub)

During installer configuration

  • Confirm your server has a static IP (LAN).
  • Choose an upstream DNS provider (video picks Cloudflare).
  • Enable query logging (video chooses “Yes” to show metrics).
  • Keep default blocklists initially.

Common mistakes / challenges

  • Installing without sudo access.
  • Skipping the static-IP requirement.
  • Picking an upstream DNS provider you can’t reach due to firewall rules.

Step 3 — Log into the Pi-hole Admin UI

Open:

  • http://192.168.1.53/admin (replace with your LAN IP)

You should see the Pi-hole dashboard after installation.

Common mistakes

  • Using HTTPS when not configured.
  • Trying to access the UI from outside the LAN before routing is configured.

Step 4 — Install and connect Tailscale on the Pi-hole host

  1. In the Tailscale admin console, go to Add device and generate the Linux install script.
  2. Run the script on the Pi-hole host.
  3. Verify:
tailscale status

Common mistakes

  • Forgetting to authenticate the node (device never appears in tailnet).
  • Installing Tailscale but leaving it disconnected/offline.

Step 5 — Set (or reset) the Pi-hole admin password

Pi-hole prints a password at install time. If you missed it, set a new one:

pihole -a -p

The video uses a “set password” command concept; the standard Pi-hole CLI uses pihole -a -p for password set.

Shell shortcut shown

  • sudo !! re-runs the previous command with sudo prepended.
    • Helpful when you forgot sudo.

Common mistakes

  • Trying to log in with the wrong password.
  • Not running the password command with required privileges.

Step 6 — Allow Pi-hole to listen on the Tailscale interface (critical)

By default, Pi-hole may only listen on the LAN interface. To accept DNS queries from tailnet devices:

  1. Pi-hole Admin → Settings → DNS
  2. Switch from Basic to Expert mode
  3. Set listening behavior to Permit all origins (wording varies by Pi-hole version)

Why

  • Tailnet traffic arrives on the Tailscale interface, not your LAN interface.

Warning

  • “Permit all origins” can be risky on internet-exposed hosts. It’s safer when the machine is only reachable via LAN + Tailscale (no public DNS exposure).

Common mistakes

  • Forgetting this step → tailnet clients won’t resolve via Pi-hole.
  • Exposing the Pi-hole DNS port publicly on a VPS while permitting all origins.

Step 7 — Add Pi-hole as the tailnet DNS nameserver in Tailscale

  1. In Tailscale admin console → DNS page. (Tailscale)
  2. Under Nameservers, choose Add nameserver → Custom
  3. Paste the Pi-hole Tailscale IP (not the 192.168.x.x LAN IP)
  4. Save
  5. Enable Override DNS servers (forces tailnet clients to use your Pi-hole)

Common mistakes

  • Using the LAN IP instead of the Tailscale IP.
  • Not enabling Override DNS servers → some clients keep using their prior DNS.

Step 8 — Refresh clients and validate traffic

  1. Toggle Tailscale off/on on a client (forces it to fetch updated DNS config).
  2. Run a DNS leak test or simply browse and watch the Pi-hole dashboard.
  3. In Pi-hole, confirm queries appear and are attributed per client (tailnet IPs).

Common mistakes

  • Testing from a device not connected to Tailscale.
  • Client DNS caching makes it look like nothing changed—wait or flush DNS cache.

Step 9 (optional/advanced) — Lock down access with tags + ACLs

The video mentions tagging the DNS node (e.g., tag: dns) and using Tailscale ACLs so all devices can reach DNS while restricting other ports.

  • Tailscale device tags documentation: (Tailscale)
  • Example policy patterns (“grants” examples): (Tailscale)

KEY TECHNICAL DETAILS

Brands / software / tools mentioned

  • Pi-hole (DNS ad blocking / sinkhole)
  • Tailscale (tailnet, admin console, DNS override, ACLs, tags, exit nodes, subnet routers) (Tailscale)
  • Proxmox (VM host)
  • Raspberry Pi Zero 2 W
  • Cloudflare (upstream DNS choice)
  • AdGuard Home (alternative DNS adblocker)
  • Technitium DNS Server (alternative DNS; clustering mentioned) (technitium.com)
  • Mentioned ecosystem items:
    • Pi-hole sync / AdGuard sync (syncing multiple instances—video references this concept)
    • Exit node (Tailscale feature)
    • Subnet router (Tailscale feature)

Versions / editions

  • No explicit versions in the transcript.
  • Tailscale tags page shows it was last validated Dec 4, 2025. (Tailscale)

Installation / sources

PRO TIPS (3–5)

  • Use the Pi-hole host’s Tailscale IP for the tailnet nameserver, not the LAN IP.
  • Turn on Pi-hole query logging so you can verify ad-blocking and see per-client metrics immediately.
  • Enable Override DNS servers in Tailscale to avoid “some devices still using old DNS” confusion. (Tailscale)
  • If you run Pi-hole on a VPS, keep UDP/TCP 53 closed to the public internet; rely on Tailscale-only access.
  • For larger setups, consider tags + ACLs to guarantee DNS reachability while restricting Pi-hole admin ports. (Tailscale)

POTENTIAL LIMITATIONS / WARNINGS

  • Security risk: Pi-hole “Permit all origins” binds wider than LAN-only. Safe only if you’re not exposing DNS publicly.
  • Single point of failure: One Pi-hole node means DNS goes down if the VM/host goes down.
  • Tailnet-wide DNS override is broad: If you override DNS for the tailnet, it affects many devices; per-device granularity can be limited depending on your setup. (Workarounds include client-side configuration or policy patterns.)
  • Docker edge cases: Some containers/apps may behave oddly with overridden DNS; recent reports show interactions where Tailscale DNS override can affect internal name resolution in certain setups. (GitHub)
  • Performance/latency: When you’re traveling, DNS queries traverse the tailnet back home (or to your VPS). Usually fine, but it’s extra hops.

RECOMMENDED FOLLOW-UP RESOURCES

  • Tailscale DNS documentation (Nameservers, override, MagicDNS): (Tailscale)
  • Tailscale tags (group devices) and ACL/access control docs: (Tailscale)
  • Tailscale grant/policy examples (for DNS tag patterns): (Tailscale)
  • Technitium DNS Server (overview) + clustering explanation/releases: (technitium.com)

If you tell me where you’re running Pi-hole (Proxmox VM vs Raspberry Pi vs VPS), I can provide a hardened checklist (firewall rules, Tailscale ACL snippet, and a quick validation script).

Related reading

Get New Posts

Follow on your preferred channel for new articles, notes, and experiments.

Related Posts