Ad blocking on your home network works well until you leave the house. Pi-hole filters DNS queries for devices on your local network, but that filtering disappears the moment a phone or laptop switches to a different network at a coffee shop, airport, or hotel. Tailscale solves this by creating a private mesh network between your devices and your homelab, allowing remote devices to continue routing DNS queries through your Pi-hole node.

Running pi-hole tailscale on turing pi turns an RK1 node into a lightweight always-on network service handling both DNS filtering and secure remote access. If your cluster is not set up yet, the complete Turing Pi 2.5 setup guide walks through the full process from first boot to a working ARM64 cluster.

Why Pi-hole and Tailscale Work Better Together

Pi-hole operates as a DNS sinkhole. Devices on your local network send DNS queries through it, and requests to domains on Pi-hole’s blocklists are filtered before they resolve. Phones, laptops, smart TVs, and other devices all benefit automatically as long as they use the Pi-hole node as their DNS server. No client-side software or browser extensions are required.

The limitation is network scope. Pi-hole only filters queries that reach your local network. Once a device leaves home and starts using DNS servers assigned by another router or public network, Pi-hole is bypassed. Tailscale solves this by creating an encrypted mesh network between your devices and the homelab. By setting the Pi-hole node’s Tailscale IP as the global DNS server in Tailscale, connected devices continue routing DNS queries back through your homelab even when they are away from home.

The privacy benefit is practical rather than absolute: DNS queries are routed through infrastructure you control instead of whatever resolver a hotel, airport, or public Wi-Fi network assigns by default. If you’re exploring the broader networking and infrastructure capabilities of the platform, the Turing Pi 2.5 use cases overview covers additional homelab workloads that fit well on RK1 nodes.

Quick Overview: Pi-hole + Tailscale on Turing Pi 2.5

  • What this guide covers: Deploying Pi-hole on an ARM64 RK1 node for network-wide DNS filtering, then extending that filtering to remote devices using Tailscale’s private mesh network, with optional exit node configuration and AdGuard Home as an alternative
  • ARM64 compatibility note: Pi-hole and Tailscale both provide official ARM64-compatible packages and Docker images with full feature parity on RK3588 hardware.
  • Deployment approach: Both services run as lightweight always-on infrastructure on a single RK1 node, leaving the remaining nodes free for heavier homelab workloads
  • How to use this guide: Follow Parts 1–3 for the core Pi-hole and Tailscale setup, refer to Part 4 only if full traffic tunneling is needed, and use the troubleshooting and practical notes sections to handle common DNS and Tailscale failure modes

Part 1: Deploying Pi-hole on an RK1 Node

Pi-hole publishes an official Docker image with ARM64 support, making Docker one of the simplest deployment paths for RK1 nodes. Containerizing the service isolates dependencies, simplifies updates, and avoids conflicts with other infrastructure workloads running on the same system. If you’re building a broader ARM64 homelab stack, the self-hosted apps catalog covers additional lightweight network services that pair well with Pi-hole deployments.

Create a working directory and add the following docker-compose.yml:

services:
  pihole:
    image: pihole/pihole:latest
    container_name: pihole
    restart: unless-stopped
    network_mode: host
    
    environment:
      TZ: "your_timezone"
      FTLCONF_dns_upstreams: "1.1.1.1;9.9.9.9"
      
    volumes:
      - ./etc-pihole:/etc/pihole
      - ./etc-dnsmasq.d:/etc/dnsmasq.d
      
    cap_add:
      - NET_ADMIN

Replace your_timezone with your local timezone string.

Free Port 53 Before Starting Pi-hole

Ubuntu 22.04 runs systemd-resolved with a stub listener on port 53 by default. Pi-hole with network_mode: host needs full ownership of that port. If systemd-resolved is still holding it, Pi-hole will appear to start correctly but DNS routing through Tailscale will fail later when Override DNS servers is enabled.

Confirm the conflict before proceeding:

sudo ss -tulpn | grep :53

If the output shows systemd-resolve listening on 127.0.0.53:53, port 53 is occupied and needs to be freed before starting the container.

Open the resolved configuration file:

sudo nano /etc/systemd/resolved.conf

Find the DNSStubListener line and set it to no:

DNSStubListener=no

Save the file, then apply the change and fix the symlink:

sudo systemctl restart systemd-resolved
sudo rm /etc/resolv.conf
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

Confirm port 53 is now free:

sudo ss -tulpn | grep :53

The command should return no output. Pi-hole can now bind to port 53 cleanly when the container starts.

Start the container:

docker compose up -d

Web UI Access

After the container starts, set a password for the Pi-hole web interface:

docker exec -it pihole pihole setpassword

The Pi-hole web interface is available at:

http://<node-ip>/admin

Verify Upstream Resolvers

Pi-hole v6 uses FTLCONF_dns_upstreams to set upstream resolvers at container startup. To confirm the setting applied correctly, navigate to Settings > DNS in the web interface and verify that Cloudflare (DNSSEC) and Quad9 (filtered, DNSSEC) are checked under Upstream DNS Servers and Google is unchecked. Hit Save & Apply if any changes are needed.

Router DNS Configuration

Configure your router’s primary DNS server to use the static IP address of the Pi-hole node, and set the secondary DNS server to 9.9.9.9 as a fallback. Some homelab users prefer leaving the secondary DNS field empty to avoid devices bypassing Pi-hole when fallback resolvers respond faster. The exact location of these settings varies between router vendors, but they are typically found under LAN, DNS or DHCP settings. Once applied, devices on the network will automatically use the Pi-hole node for DNS resolution while still retaining a backup resolver if the node becomes unavailable.

Verify DNS Resolution

From another device on the network, confirm DNS resolution is working through the Pi-hole node:

dig @<pihole-node-ip> example.com

A successful response confirms the node is receiving and answering DNS queries correctly. The Pi-hole query log in the web interface should also begin showing activity from devices on the network.

Part 2: Installing and Configuring Tailscale

Installing Tailscale on the RK1 Node

Tailscale provides an official installation script for Debian and Ubuntu systems, including Ubuntu 22.04 ARM64 on RK1 nodes. Run the following command on the node hosting Pi-hole:

curl -fsSL https://tailscale.com/install.sh | sh

The installer automatically detects the system architecture and installs the appropriate package for the RK3588 environment.

Authenticating and Verifying

After installation, authenticate the node with your Tailscale account:

sudo tailscale up

The command outputs a login URL. Open it in a browser, authenticate with your Tailscale account, and approve the node. Once connected, the RK1 system appears in the Tailscale admin console under:

https://login.tailscale.com/admin/machines

Record the Tailscale IP assigned to the node. It will typically fall within the 100.x.x.x CGNAT range and will be used as the DNS endpoint in the next section.

Part 3: Routing Remote DNS Through Pi-hole via Tailscale

Pi-hole and Tailscale DNS Configuration

This is the central part of the setup. Tailscale will be configured to use the RK1 node running Pi-hole as the DNS resolver for devices connected to the private mesh network.

In the Tailscale admin console:

  1. Navigate to DNS in the left sidebar
  2. Under Global nameservers, click Add nameserver and select Custom
  3. Enter the Tailscale IP assigned to the Pi-hole node Retrieve the Tailscale IP of the Pi-hole node: tailscale ip -4 This returns the 100.x.x.x address assigned to the node within your tailnet. Use this address as the custom nameserver.
  4. Enable Override DNS servers so connected devices use Pi-hole instead of DNS servers assigned by the local network

Allow Queries from Tailscale Clients

By default, Pi-hole is configured to allow queries only from devices directly connected to the same network. Tailscale clients querying through the 100.x.x.x address do not meet this criterion, so their DNS queries get dropped silently.

Update the listening mode using the FTL config command:

docker exec -it pihole pihole-FTL --config dns.listeningMode all

This takes effect immediately without a container restart. In the Pi-hole web UI under Settings > DNS > Interface settings, the selection will update to Listen on all interfaces, permit all origins.

If MagicDNS or other custom DNS settings are already enabled in Tailscale, verify that the Pi-hole node remains configured as the active global nameserver after applying the changes.

What This Changes

Devices connected to Tailscale now send DNS queries back through the Pi-hole node regardless of their physical location or local network. Phones, laptops, and tablets continue using the same filtering behavior whether they are connected to home Wi-Fi, public hotspots, hotel networks, or cellular data.

Only DNS traffic is routed through the Pi-hole node in this configuration. General browsing and application traffic continue using the device’s normal network connection unless the RK1 node is later configured as a full Tailscale exit node.

Verifying on a Remote Device

Any device that joins your Tailscale network automatically inherits the Pi-hole DNS configuration set in the admin console. Install the Tailscale app on the device, sign in with the same account used during node setup, and enable the connection. No additional DNS configuration is required on the device itself.

To confirm filtering is active on a connected device:

  1. Enable Tailscale on a phone or laptop
  2. Disconnect from the home Wi-Fi network
  3. Browse normally or open sites known to contain advertising
  4. Check the Pi-hole query log in the web interface

Queries from the remote Tailscale client should begin appearing in the query log. If ads are being filtered and DNS activity is visible in Pi-hole, the remote DNS routing is functioning correctly.

Part 4: Optional: Enabling a Tailscale Exit Node

A Tailscale exit node routes all network traffic through the Turing Pi 2.5 node rather than routing only DNS queries through Pi-hole. Web browsing, application traffic, downloads, and API requests all exit through the home network connection before reaching the public internet.

This is useful on untrusted public networks or whenever a consistent outbound IP address is desirable. The tradeoff is bandwidth and latency: traffic throughput becomes limited by the home connection’s upstream capacity and the RK1 node handling the encrypted traffic path.

To advertise the Pi-hole node as a Tailscale exit node:

sudo tailscale up --advertise-exit-node

After running the command, open the Tailscale admin console and approve the exit node capability under Machines. On client devices, select the RK1 node as the active exit node within the Tailscale application settings.

This step is optional. Readers who only want remote DNS filtering through Pi-hole do not need to enable an exit node because the DNS routing configured earlier operates independently of full traffic tunneling.

Part 5: AdGuard Home as an Alternative to Pi-hole

AdGuard Home provides DNS-level filtering similar to Pi-hole with a more feature-rich web UI and native support for encrypted upstream DNS protocols including DNS-over-HTTPS, DNS-over-TLS, and DNS-over-QUIC. These require no additional configuration in AdGuard Home, making it a strong choice if encrypted upstream DNS matters to your setup.

Official ARM64-compatible Docker images are available, and deployment on RK1 follows the same pattern as Pi-hole. Port 3000 is used for the initial setup UI, after which the service moves to port 80 by default.

The Tailscale DNS routing configuration in Section 3 works identically with AdGuard Home. Set the AdGuard Home node’s Tailscale IP as the global nameserver in the Tailscale admin console the same way. Both Pi-hole and AdGuard Home are covered in the self-hosted apps catalog alongside other services suited to RK1 nodes.

Part 6: Resource Usage on RK1

Pi-hole and Tailscale are among the lowest-overhead services you can run on an RK1 node. Pi-hole’s baseline memory usage is typically under 100 MB, while Tailscale consumes minimal CPU resources at idle. Under normal DNS query volumes, neither service places meaningful load on the RK3588 SoC.

Both are well suited for always-on infrastructure roles such as DNS filtering and remote network access. An 8 GB RK1 node can comfortably run Pi-hole and Tailscale alongside monitoring agents, reverse proxies, dashboards, or similar low-resource services without noticeable contention. The RK1 benchmarks provide additional context for how the RK3588 behaves under sustained and concurrent workloads.

CPU and network utilization increase primarily when the node is operating as a Tailscale exit node and routing larger volumes of traffic through the home connection. For DNS-only routing through Pi-hole, resource usage remains very low.

Part 7: Practical Notes and Considerations

Running both services on one node: Pi-hole and Tailscale comfortably share an 8 GB RK1 node alongside other low-resource infrastructure services. Separating them onto different nodes is possible but usually unnecessary for typical homelab deployments.

Updating blocklists: DNS blocklists need periodic updates as ad and tracking domains change over time. Pi-hole includes an Update Gravity option under Tools in the web UI. Running updates regularly helps maintain filtering effectiveness.

Tailscale key expiry: Tailscale node keys expire after 180 days by default and require re-authentication. For long-lived homelab infrastructure nodes, either set a reminder to reauthorize the machine or disable key expiry in the Tailscale admin console under Machines.

DNS failures after reboots or container restarts: If DNS resolution stops working after the node reboots or the Pi-hole container restarts, confirm the container is running before troubleshooting the Tailscale configuration. In most cases, the issue originates from the DNS service itself rather than the mesh network routing.

Query log retention: Pi-hole logs every DNS query, which is useful for debugging and visibility but accumulates over time. Configure an appropriate retention limit under Settings > Privacy to avoid unnecessary disk usage on the RK1 node.

Behavior after node or network restarts: With restart: unless-stopped enabled in the Docker Compose configuration, Pi-hole automatically starts again after the RK1 node reboots. Tailscale also runs as a system service and reconnects automatically after network recovery or system startup. In most cases, DNS filtering resumes without manual intervention once the node regains network connectivity.

After router reboots or DHCP renewals, some client devices may temporarily continue using cached DNS entries until their leases refresh. If DNS filtering does not appear immediately after a network restart, reconnecting the device to Wi-Fi or toggling Tailscale usually forces DNS settings to refresh.

Part 8: Troubleshooting

DNS Not Resolving on Tailscale Clients

Verify Pi-hole is running:

docker ps

Test that port 53 is reachable on the Pi-hole node’s Tailscale IP:

dig @<pihole-tailscale-ip> example.com

If this fails, check the Tailscale admin console to confirm the DNS nameserver is pointing to the correct 100.x.x.x address.

Pi-hole Not Blocking Ads After Setup

Confirm your router’s DNS is set to the Pi-hole node’s local IP, not a public DNS server. Flush the DNS cache on the client device (on macOS: sudo dscacheutil -flushcache; on Windows: ipconfig /flushdns). Check the Pi-hole query log to confirm queries are arriving, if no queries appear, the router or client is using a different DNS server.

Tailscale Not Connecting

Check Tailscale status:

sudo tailscale status

If the key has expired, re-authenticate:

sudo tailscale up

Related Articles

What You’ve Set Up

At this point, your Turing Pi 2.5 is running Pi-hole on an ARM64 RK1 node handling DNS-level filtering for devices across your local network. Tailscale extends that filtering beyond the home network by routing DNS queries from remote devices back through the same Pi-hole node over a private mesh connection. The combination of Pi-hole and Tailscale on Turing Pi provides consistent DNS filtering across both local and remote environments without relying on browser extensions or third-party DNS infrastructure.

This setup also fits naturally into a broader ARM64 homelab stack. The same RK1 nodes and Tailscale mesh used for DNS filtering can later support monitoring services, reverse proxies, dashboards, and additional self-hosted infrastructure workloads as the cluster expands. The self-hosted apps catalog covers additional services that integrate well into this type of always-on ARM64 environment.

FAQ

Does Pi-hole work on ARM64 RK3588 systems?

Yes. Pi-hole runs reliably on ARM64 RK3588 systems using the official pihole/pihole:latest Docker image, which includes ARM64 support. DNS filtering workloads are lightweight relative to the RK3588’s processing capacity, so an RK1 node handles typical homelab query volumes comfortably without architecture-specific tuning.

Can I use Tailscale to access Pi-hole remotely on Turing Pi 2.5?

Yes. Tailscale allows remote devices to route DNS queries back through the Pi-hole node on your Turing Pi 2.5 over a private mesh network. After configuring the Pi-hole node’s Tailscale IP as the global DNS server in the Tailscale admin console, connected devices continue using Pi-hole even when they leave the home network.

What is the difference between Pi-hole DNS routing and a Tailscale exit node?

Pi-hole DNS routing sends only DNS queries through the Turing Pi 2.5 node while other traffic continues using the local network connection normally. A Tailscale exit node routes all traffic through the homelab node, including browsing, downloads, and application traffic. DNS-only routing is lighter and sufficient for remote ad blocking, while exit node routing is better suited to situations where all traffic should pass through the home connection.

Does this setup block ads on mobile devices outside the home network?

Yes. Devices connected to Tailscale continue sending DNS queries through the Pi-hole node even when using mobile data or public Wi-Fi networks. As long as Tailscale is connected and DNS override is enabled in the Tailscale admin console, ad blocking behavior remains consistent away from home.

Can Pi-hole and Tailscale run on the same Turing Pi 2.5 node?

Yes. Pi-hole and Tailscale are both lightweight services with minimal baseline resource usage. An 8 GB RK1 node running Ubuntu 22.04 ARM64 can comfortably handle both alongside other low-resource infrastructure services commonly found in homelab environments.