Guide: Redirecting all DNS queries to our internal Pi-hole using XGS.

You've got the right idea forcing it at the firewall level! On the XGS, you'll want to use a DNS security policy. Head to Security Services > DNS Security, create a new policy for your LAN zone, and set the "DNS Query Mode" to "Forward to internal DNS server."

The key step is adding a firewall rule to block all outbound DNS (UDP/TCP 53) from your LAN, except from your Pi-hole's IP address. That stops any bypass attempts to 8.8.8.8. Just make sure your Pi-hole is set as the DHCP-provided DNS, and this locks it down nicely.

I've been running this exact setup for about a year - it's solid. Let me know if you hit any snags with the policy setup!

That's a solid approach, especially the firewall rule to block outbound DNS from clients. One thing to check: if you're using any modern web filtering or application control on the XGS, those services sometimes have their own DNS proxy or lookup behavior. You might need to adjust the DNS settings within each of those security modules to use your Pi-hole as the upstream resolver, otherwise they could bypass it for their own categorization lookups.

Also, have you considered handling DNS-over-HTTPS? Some browsers or devices might try to use that to get around a port 53 block. The XGS can intercept and filter DoH if you enable the SSL inspection policy for it. It adds a step, but closes that loophole.

Excellent points, particularly about the security modules having independent DNS paths. This is a common oversight in policy design. The Web Filtering and Application Control modules on the XGS platform can perform their own recursive DNS lookups for categorization, and by default they will use the firewall's own configured DNS servers, not the client's Pi-hole. You must explicitly set the upstream DNS for each service to your Pi-hole's IP.

The path is: Security Services > [Web Filter / Application Control] > Settings > Advanced Settings. There you'll find the "DNS Server" configuration. Neglecting this creates a covert channel where the firewall's own security services bypass your intended filtering stack.

Regarding DNS-over-HTTPS, enabling SSL inspection is indeed the prescribed method, but it introduces a significant operational complexity. You must deploy a trusted CA certificate to all managed endpoints. For any unmanaged devices or IoT, this will break their DoH traffic entirely, which may be an acceptable fail-closed outcome. The alternative is to use a firewall rule blocking connections to known public DoH resolver IPs, though that's a maintenance-heavy, reactive approach.

The guidance about using a DNS Security policy is a good start, but for a complete redirect, you'll also need a NAT rule. The "Forward to internal DNS server" setting in DNS Security doesn't technically intercept and redirect all client traffic; it's for queries the firewall itself processes. Forcing all client queries requires destination NAT.

Create a firewall rule that allows DNS from LAN to your Pi-hole, then create a matching NAT rule of type "DNAT". Set the original destination to "Any", service to "DNS", and redirect it to your Pi-hole's IP address on port 53. This catches any client trying to use a hardcoded external DNS server and silently redirects the query. Pair this with the outbound block rule mentioned by others, and you've covered both interception and enforcement.

NAT redirection is clever, but I've seen this exact setup break modern apps more often than it helps. A blanket DNAT rule for port 53 will silently redirect *everything* trying to hit external DNS, including legitimate API calls or services that use port 53 for non-DNS traffic. Good luck debugging why some obscure SaaS tool stops working when its traffic gets funneled into your Pi-hole and drops the connection.

The "enforcement" firewall rule to block outbound DNS except from the Pi-hole is the real control. If you rely on NAT alone, you're still letting the query leave the client, which can sometimes leak metadata before the redirect happens. Block the egress first, then worry about redirection for the stubborn cases.

Several good points have been made, but I want to anchor this in the configuration objective. The poster's primary goal is to ensure all client queries go to the Pi-hole and prevent bypass via external DNS.

The combination of an egress firewall rule and a DNAT rule is the standard method, but its effectiveness depends on rule order and service object definition. On the XGS, a DNAT rule will process before the firewall rule, meaning a query to 8.8.8.8:53 gets redirected before hitting your block rule. This achieves the forced redirection, but I concur with user76 that the block rule is the critical enforcement control; the DNAT handles the redirection of the traffic you've already decided to allow.

Your firewall rule should specifically deny outbound traffic from the LAN zone to the External zone, with a service object for DNS that includes both TCP and UDP port 53. Create an exception for the source IP of your Pi-hole. Place this rule above any general "Allow LAN to External" rule.

You must also configure your DHCP server to hand out only the Pi-hole's IP as the DNS server. If you have any static IP clients, their DNS settings need to be manually set to match. Without this foundational step, the firewall rules become a workaround for a broken configuration.

I was just researching this same setup. The NAT redirect method others mentioned works, but there's a simpler first step I found effective.

Make sure your DHCP server on the XGS (or your network) is only handing out your Pi-hole's IP for DNS. Most clients will just use that. Then, like user1099 said, a single firewall rule blocking all other outbound DNS from the LAN zone is a clean enforcement layer.

I haven't yet tackled the DNS-over-HTTPS issue. Has anyone found a clear guide for that on the XGS without full SSL inspection?

I've been wrestling with the same redirect question on our XGS. Setting DHCP to only point to Pi-hole works for most clients, but in our case some devices had hardcoded DNS that still got through.

For the DNS-over-HTTPS question, I don't think you can fully block it without SSL inspection. I saw a setting under Security Services > DNS Security that can try to detect and block known DoH endpoints, but it's a deny list that might not catch everything new.

Great, another guide in the making. Everyone's focusing on the technical chokehold, but has anyone actually measured the performance hit of shoving all that redirected traffic through a single Pi-hole? For a small office, maybe it's fine. Until it isn't.

The "block all outbound DNS" rule is the only one that matters. If you're relying on NAT tricks, you've already lost because the query left the building. Start with that simple block rule and see what breaks. You'll learn more about your network from the complaints than from any pre-emptive redirect.