WireGuard is designed to be simple, but making it the gateway for all your VPN traffic, including ad blocking, requires a surprisingly nuanced approach to DNS resolution.
Let’s see this in action. Imagine you’ve got a WireGuard server set up and clients connecting. You want those clients to use Pi-hole for DNS, so ads get blocked even when they’re not on your home network.
Here’s a common wg0.conf on the server side:
[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY
[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.0.0.2/32
And on the client side:
[Interface]
Address = 10.0.0.2/24
PrivateKey = CLIENT_PRIVATE_KEY
[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = YOUR_SERVER_IP:51820
AllowedIPs = 0.0.0.0/0
The AllowedIPs = 0.0.0.0/0 on the client is the key here – it means all traffic from the client goes through the VPN. Now, how do we point that traffic to Pi-hole?
The most straightforward way is to configure the client’s DNS setting within its WireGuard configuration to point directly to your Pi-hole’s IP address. If your Pi-hole is at 192.168.1.10, the client’s wg0.conf would look like this:
[Interface]
Address = 10.0.0.2/24
PrivateKey = CLIENT_PRIVATE_KEY
DNS = 192.168.1.10
When the client connects, WireGuard tells the operating system to use 192.168.1.10 as the DNS server for all traffic routed through the wg0 interface. Pi-hole then receives these DNS requests, filters them, and forwards legitimate ones to an upstream DNS provider.
This setup works because WireGuard, by setting the DNS directive in the client’s configuration, instructs the OS to reroute DNS queries. Your Pi-hole, listening on its configured IP and port (typically UDP 53), receives these requests. If the domain is on Pi-hole’s blocklist, it returns a null-routed IP (like 0.0.0.0 or 127.0.0.1); otherwise, it forwards the request to its configured upstream DNS server (e.g., 1.1.1.1 or 8.8.8.8). The client then receives the response and proceeds to connect to the requested IP, or not, depending on whether it was blocked.
The core problem this solves is extending your network’s ad-blocking capabilities beyond your home Wi-Fi. Without this, VPN clients would bypass Pi-hole entirely, and ads would appear as if they were on your local network. By making Pi-hole the DNS resolver for the VPN tunnel, you ensure that all DNS lookups originating from connected clients are subject to your ad-blocking rules.
A common pitfall is assuming the server’s wg0.conf needs to point to Pi-hole. While you can configure the server to use Pi-hole for its own DNS, it doesn’t automatically redirect client DNS requests. The DNS setting in the client’s [Interface] section is the direct mechanism for telling the client OS which DNS server to use for traffic routed through that specific VPN interface.
Furthermore, ensure your Pi-hole is accessible from the VPN subnet. If your WireGuard tunnel uses 10.0.0.0/24 and your Pi-hole is on 192.168.1.10, you need to make sure your Pi-hole’s firewall or network configuration allows inbound UDP traffic on port 53 from the 10.0.0.0/24 network. You might also need to adjust Pi-hole’s DNS settings to listen on all interfaces, not just the LAN interface, if it’s not already configured that way.
The AllowedIPs on the server’s peer configuration is crucial. If you set it to 10.0.0.2/32 (for a single client), it means only traffic destined for that client’s IP address within the tunnel will be routed to that client. For the client to send all its traffic through the tunnel, AllowedIPs = 0.0.0.0/0 on the client’s peer configuration tells the client to route everything via the VPN.
The surprising thing is that the DNS directive in WireGuard’s client configuration is not a WireGuard-specific protocol for DNS forwarding; it’s a simple instruction to the client’s operating system to update its DNS resolver settings for the active network interface. The OS then handles the routing of those DNS queries.
When you configure DNS = <Pi-hole_IP> in the client’s wg0.conf, you are essentially telling your client machine, "For any network traffic coming through this WireGuard tunnel, use <Pi-hole_IP> to resolve domain names." The WireGuard client software on your device then makes the necessary OS calls to update the DNS settings. This means that every DNS lookup initiated by an application on your client device, when the VPN is active, will first go to your Pi-hole.
You might encounter issues if your Pi-hole is configured to only listen on a specific IP address (e.g., its LAN IP) and not on the IP address assigned to the WireGuard server’s interface within the tunnel. In such cases, Pi-hole won’t see the DNS requests coming from the VPN clients.
If you have multiple WireGuard tunnels or complex routing, you might find yourself needing to manage DNS settings more granularly. However, for the common use case of blocking ads for all VPN traffic, setting the client’s DNS to your Pi-hole IP is the most direct and effective method.
The next challenge you’ll likely face is handling DNS requests for local network resources if you’re routing all traffic through the VPN, as 0.0.0.0/0 will send even local DNS lookups over the tunnel.