https://jeff.vtkellers.com/posts/technology/force-all-dns-queries-through-pihole-with-openwrt

https://web.archive.org/web/20250514042532/https://jeff.vtkellers.com/posts/technology/force-all-dns-queries-through-pihole-with-openwrt/

Force All DNS Queries Through Pi-hole with OpenWRT

DNS Leaks

I’ve run Pi-hole on a Raspberry Pi 3 Model B as my local DNS server for a couple of years. Once configured, it noticeably trims page-load times when multiple devices on the LAN visit the same sites.

A recent LabZilla article, Your Smart TV is probably ignoring your Pi-hole, reminded me that any device on the network can simply ignore the DNS server advertised by the router. Many “smart” TVs hard-code public resolvers such as 1.1.1.1 or 8.8.8.8. LabZilla showed how to intercept that traffic with pfSense; below is how to do the same on OpenWRT.

My LG B9 TV is air-gapped (its Wi-Fi module was surgically removed), but other gadgets—a Chromecast and a Windows laptop—could still bypass Pi-hole. Time to do some firewall tinkering.

Intercept and Redirect DNS Queries

DNS usually happens over port 53, so we’ll:

1. Create a port-forward that grabs all outbound traffic on port 53 and sends it to the Pi-hole.
2. Add a NAT rule so replies appear to come from the hard-coded resolver the client asked for; otherwise the client complains about an unexpected source.

Port Forward Rule

In Network → Firewall → Port Forwards add:

• Protocol: TCP, UDP
• Source zone: lan
• External port: 53
• Destination zone: lan
• Internal IP: 192.168.1.101 (your Pi-hole)
• Internal port: 53

We must exempt Pi-hole itself or it would loop back on its own queries. Under Advanced Settings add:

Source IP: !192.168.1.101

Quick Test

In Pi-hole → Local DNS → DNS Records add a fake entry:

• Domain: piholetest.example.com
• IP: 10.0.1.1

dig piholetest.example.com @1.1.1.1

At this point dig complains that the reply comes from 192.168.1.101 instead of 1.1.1.1. That means interception works; now we’ll fix masquerading.

NAT Rule

Navigate to Network → Firewall → NAT Rules and add:

• Protocol: TCP, UDP
• Outbound zone: lan
• Destination address: 192.168.1.101
• Destination port: 53
• Action: MASQUERADE

Testing

dig piholetest.example.com @1.1.1.1

You should now receive:

;; ANSWER SECTION:
piholetest.example.com. 2 IN A 10.0.1.1
...
;; SERVER: 1.1.1.1#53 (1.1.1.1)

The reply appears to come from 1.1.1.1 even though Pi-hole actually answered. Success!

Final Thoughts

With these two firewall rules, every DNS query on port 53—hard-coded or not—is filtered through Pi-hole, letting its blocklists protect even the sneakiest devices and trimming bandwidth usage.

A determined device could still bypass this by sending DNS over a non-standard port or encapsulating it in HTTPS (DoH/DoT). Catching that traffic would require deeper packet inspection, which is outside the scope of lightweight home routers.