PiHole with Recursive DNS not Handshaking with Wireguard setup via PiVPN

PiHole with Recursive DNS fails to handshake with Wireguard via PiVPN when the DNS resolver is bound only to the local interface or when firewall rules block UDP port 53 traffic from the tunnel. This guide resolves the connection issue by configuring PiHole to listen on all interfaces, adjusting iptables rules for the wg0 subnet, and verifying routing tables to ensure seamless encrypted DNS resolution.

Understanding the Network Topology

To troubleshoot this issue effectively, it is crucial to understand how data flows between your devices. When you connect to a Wireguard VPN established by PiVPN, your client device receives an IP address from the wg0 subnet (typically 10.8.0.x). By default, PiHole often runs in a Docker container or as a service bound strictly to the host’s physical network interface, such as eth0 or wlan0.

If PiHole is not listening on the loopback interface (127.0.0.1) or the specific Wireguard interface IP, it will drop incoming DNS queries from VPN clients. Furthermore, recursive DNS lookups require significant bandwidth and low latency. If the handshake fails, it is rarely a TLS certificate issue but rather a fundamental connectivity problem where packets are being dropped before they reach the DNS resolver. You must ensure that the PiHole instance accepts connections from the virtual network created by Wireguard.

Configuring PiHole to Listen on All Interfaces

The most common cause of this failure is the DNSMASQ_LISTENING setting within PiHole. By default, many installations restrict DNS services to the LAN interface to prevent external exposure. However, for a VPN setup, you need to allow traffic from the wg0 interface.

1. Access your PiHole admin interface via the web browser using the host's local IP address.
2. Navigate to Settings and then select DNS.
3. Look for the option labeled "Listen to all available networks" or check if there is a configuration file override.
4. If using the command line, edit the /etc/pihole/setupVars.conf file.
5. Ensure the variable DNSMASQ_LISTENING=all is set. If it is set to local or single, change it to all.

After making this change, restart the PiHole service to apply the new binding settings. This allows the DNS resolver to accept queries not just from your home Wi-Fi, but also from any interface that has traffic routed through it, including the Wireguard tunnel.

Adjusting Firewall Rules for the WG0 Interface

Even if PiHole is listening correctly, the Linux kernel firewall (iptables or nftables) may be blocking UDP port 53 traffic originating from the Wireguard subnet. PiVPN usually configures masquerading for internet traffic, but it does not always permit return traffic for specific services like DNS unless explicitly allowed.

You need to verify that the firewall allows inbound UDP traffic on port 53 from the 10.8.0.0/24 range. If you are using ufw (Uncomplicated Firewall), which is common on Raspberry Pi OS, you can add a rule to allow DNS from the VPN subnet:

sudo ufw allow from 10.8.0.0/24 to any port 53 proto udp

If you are managing iptables directly, ensure there is a rule in the INPUT chain that permits UDP 53 from the source network of the Wireguard peers. After adding the rule, reload the firewall service. It is also important to check that the Wireguard interface itself is not blocked by any custom scripts that might restrict access to sensitive ports.

Verifying Routing and Recursive DNS Settings

Once the listener and firewall are configured, you must ensure that PiHole can actually perform recursive lookups. If PiHole is configured to use upstream servers that are unreachable from the VPN context, the handshake may appear to hang. Check your upstream DNS providers in the PiHole dashboard. Standard providers like Google (8.8.8.8) or Cloudflare (1.1.1.1) should work seamlessly.

Additionally, verify the routing table on the PiHole host. Run ip route show to ensure that traffic destined for the VPN clients is correctly routed back through the wg0 interface. If you have multiple network interfaces, asymmetric routing can cause packets to leave via one interface and return via another, leading to dropped connections. For more details on complex routing scenarios, see our guide on Routing Internet-Bound Traffic Between Two WireGuard Peers. This ensures that the path for DNS responses is symmetric and reliable.

Testing the Connection

After applying these changes, test the connection from a device connected via Wireguard. Use a tool like dig or nslookup targeting the PiHole IP address directly. For example, run dig @10.8.0.1 example.com from a VPN-connected client. If you receive a valid answer with an ANSWER SECTION, the handshake is successful. If you receive a timeout, re-check the firewall logs for dropped packets. You can monitor these logs in real-time using sudo tail -f /var/log/syslog while attempting the query.

Frequently Asked Questions

Why does my DNS work on LAN but fail over Wireguard?

This occurs because PiHole is typically bound to the local network interface by default for security reasons. Changing the DNSMASQ_LISTENING setting to all in the configuration file allows the service to accept queries from the virtual Wireguard interface as well.

Can I use DoT or DoH with PiHole over Wireguard?

Yes, but you must ensure that the upstream TLS/HTTPS ports are open in your firewall. While standard DNS uses UDP/TCP 53, DoT uses TCP 853 and DoH uses TCP 443. Verify that your Wireguard configuration and host firewall allow these specific ports for the VPN subnet.

What if I am using Docker for PiHole?

If PiHole is running in Docker, you must map the DNS port to the host and ensure the container network mode allows access from the Wireguard bridge. You may need to adjust the docker-compose.yml file to expose port 53 to the host network or create a shared network bridge that includes both the Docker container and the wg0 interface.

Does PiVPN automatically configure DNS forwarding?

PiVPN primarily handles the tunnel establishment and IP assignment. It does not automatically configure PiHole to listen on the tunnel interface. You must manually adjust PiHole settings and firewall rules to permit DNS traffic from the 10.8.0.0/24 subnet, as described in this guide.

How do I check if my firewall is blocking DNS?

You can check active firewall rules using sudo iptables -L -n -v or sudo ufw status verbose. Look for rules that deny or reject UDP port 53 from the source IP range of your Wireguard clients. If no explicit allow rule exists, the default policy will likely drop the packets.