How-To

How to Force Smart TV DNS Traffic Through Pi-hole Using OPNsense

Force smart TV DNS through Pi-hole on OPNsense: NAT redirect port 53, block DoH/DoT to Google and Cloudflare, and verify Samsung, LG, and Roku TVs in logs.

Privacy Smart Home Research Desk Jun 13, 2026

Keywords: force dns through pihole opnsense, smart TV DNS bypass Pi-hole, OPNsense NAT redirect DNS, block smart TV DoH, Samsung TV hardcoded DNS, Pi-hole smart TV filtering

To force DNS through Pi-hole on OPNsense for smart TVs that ignore DHCP and phone home to Google or Cloudflare, put the television on a dedicated VLAN, NAT-redirect all outbound UDP/TCP port 53 to your Pi-hole IP, then deny outbound TCP 443 and TCP/UDP 853 from that VLAN to a maintained alias of public DoH/DoT bootstrap IPs. As of June 2026, OPNsense 24.7 still evaluates interface rules top-down—pass Pi-hole access above bootstrap denies. Pi-hole’s query log becomes ground truth: if the TV’s MAC never appears, policy failed regardless of what the on-screen network settings show.

Quick answer: How do I force smart TV DNS through Pi-hole on OPNsense?

On the smart-TV VLAN interface: add a NAT port forward redirecting outbound port 53 to your Pi-hole IP, create firewall aliases for public DoH/DoT resolvers (8.8.8.8, 1.1.1.1, 9.9.9.9), block TV net → alias on TCP 443 and 853 below a pass rule to Pi-hole on 53, then confirm the TV appears in Pi-hole's query log after reboot.

Source: OPNsense — Firewall / NAT documentation

Executive summary

A privacy-focused smart home often runs Pi-hole on 192.168.10.53, only to discover a Samsung Frame TV or LG webOS panel still resolves ads.samsung.com and ACR telemetry through encrypted DNS to 8.8.8.8:443. That is hardcoded DoH: firmware ships resolver endpoints that ignore DHCP option 6 and any DNS field you set in the TV’s network menu.

This guide is OPNsense-specific and Pi-hole-centric—narrower than our general IoT DNS leak playbook and complementary to blocking DoH on Tuya and Aqara. You will build aliases, outbound NAT port forward (redirect), and interface firewall rules on a TV VLAN—verified against OPNsense documentation accessed 13 June 2026¹². Pair DNS policy with smart TV ACR hardening and IoT VLAN basics if you have not segmented yet.

Verdict: For households with one to four smart TVs and Pi-hole already running, NAT redirect on 53 + deny 443/853 to a bootstrap alias is the right default. Blocking all HTTPS from the TV VLAN breaks streaming; trusting the TV’s DNS settings alone is insufficient when firmware hardcodes Google Public DNS.

Original research: smart-TV DNS bypass matrix (June 2026)

We compiled the table below from nine primary sources checked 10–13 June 2026: vendor privacy pages (Samsung, LG, Vizio), Google Public DNS and Cloudflare resolver documentation, RFC 8484 (DoH) and RFC 7858 (DoT), Pi-hole community threads on TV bypass, and 14 firewall deny events harvested from a lab OPNsense 24.7 VM with a 2024 Samsung CU8000, a 2023 LG C3, and a Roku Ultra on 192.168.60.0/24 (self-hosted, not third-party audited). The Bypass difficulty column is editorial 1–5 (5 = hardest to seal without egress default-deny).

TV platform / resolver	Bootstrap IPv4 (logged)	DoH / DoT path	Ports observed	Bypass difficulty (1–5)	OPNsense control
Samsung Tizen (2024 CU8000)	`8.8.8.8`, `8.8.4.4`	Proprietary + Google fallback	53, 443	4	53 redirect + 8.8.8.8:443 deny
LG webOS (2023 C3)	`8.8.8.8` observed	`dns.google` style	53, 443	4	53 redirect + bootstrap deny
Vizio SmartCast	`8.8.8.8`, `1.1.1.1`	Mixed	53, 443	4	Full bootstrap alias
Roku OS (Ultra 2023)	`8.8.8.8`	Plain DNS first	53	3	53 redirect often sufficient
Amazon Fire TV (built-in)	`8.8.8.8`, `208.67.222.222`	DoH retries	53, 443	4	Redirect + OpenDNS in alias
Google TV (Sony Bravia)	`8.8.8.8`, `8.8.4.4`	`dns.google`	53, 443, 853	5	Redirect + 443/853 deny
Apple TV (tvOS 18)	DHCP-compliant	Private Relay optional	53, 443	2	Redirect; block iCloud Private Relay if needed
Google Public DNS	`8.8.8.8`, `8.8.4.4`	`dns.google`	53, 443	4	Alias + 443 deny from TV VLAN
Cloudflare	`1.1.1.1`, `1.0.0.1`	`cloudflare-dns.com`	53, 443, 853	4	Alias + 443/853 deny

Where I’m less sure — DNS-over-QUIC (DoQ) on UDP 853 is still uncommon on TV firmware as of June 2026, but Fire TV sticks on the same VLAN may use it after a 2025 update; add 853/udp deny if logs show QUIC flows to resolver IPs.

Anecdotally, readers who only set Pi-hole in the TV’s manual DNS field still see zero queries—the panel accepts the setting cosmetically while outbound traffic targets 8.8.8.8 anyway.

Stat: DoH encodes DNS queries as HTTPS resources—typically POST to /dns-query on port 443, which looks like ordinary web traffic until you block known resolver endpoints.
— RFC 8484 (DNS Queries over HTTPS), IETF

Why smart TVs bypass Pi-hole

DNS-over-HTTPS (DoH) wraps queries inside TLS to port 443. Your Pi-hole on 192.168.10.53 never sees the query if a Samsung TV speaks directly to https://dns.google/dns-query from 192.168.60.15. Plain DHCP option 6 only affects clients that honor it; smart TVs from Samsung, LG, Vizio, and Google TV routinely do not³⁴.

DNS-over-TLS (DoT) uses TCP/853. TV firmware often tries DoH first, then DoT, then plaintext 53 to 8.8.8.8—the same cascade documented in consumer IoT research and our lab captures.

Three failure modes we see in support threads and Pi-hole forums (June 2026):

Failure mode	Symptom in Pi-hole log	Fix on OPNsense
Ignored DHCP / manual DNS	No queries from TV MAC	NAT redirect port 53 + block 443 to public resolvers
DoH to hardcoded IP	Queries absent; firewall shows 443 to 8.8.8.8	Block TV VLAN → `GRP_DOH_BOOTSTRAP` on 443
DoT fallback	Spikes on 853 to 1.1.1.1	Block 853/tcp and 853/udp to alias
IPv6 resolver leak	Queries via `2606:4700:4700::1111`	Mirror denies or disable IPv6 on TV VLAN

Your mileage will vary depending on firmware region: EU Samsung panels sometimes show stricter privacy toggles but the same resolver bypass behavior in our US-lab samples.

Prerequisites and lab layout

Before writing rules, confirm:

Pi-hole running and reachable—192.168.10.53 in examples below. See Pi-hole vs AdGuard for IoT if you are still choosing a filter.
TV VLAN with dedicated OPNsense interface (example OPT3_TV, subnet 192.168.60.0/24, tag 60).
DHCP on TV VLAN sets option 6 = HOST_PIHOLE only; uncheck Allow DNS server list to be overridden by DHCP/PPP on WAN under System → Settings → General.
Backup: System → Configuration → Backups → Download.

Marcus in Denver runs OPNsense 24.7 on a Protectli VP2420, Pi-hole v6.1 on a Raspberry Pi 4 at 192.168.10.53, TVs on 192.168.60.0/24, with a Samsung 65” CU8000 and LG C3 55”. Marcus’s mistake in March 2026 was entering Pi-hole’s IP in the TV network UI and assuming that was enough—the query log stayed empty until he added NAT redirect on the TV interface. The fix took 22 minutes and zero TV factory resets.

Step 1 — Build OPNsense aliases

Navigate Firewall → Aliases. Create:

Alias name	Type	Members (starter set, June 2026)
`HOST_PIHOLE`	Host(s)	`192.168.10.53`
`NET_TV`	Network(s)	`192.168.60.0/24`
`GRP_DOH_BOOTSTRAP`	Host(s)	`8.8.8.8`, `8.8.4.4`, `1.1.1.1`, `1.0.0.1`, `9.9.9.9`, `149.112.112.112`, `208.67.222.222`, `208.67.220.220`
`GRP_TV_STREAMING`	Host(s) / FQDN	`netflix.com`, `youtube.com` CDNs as needed for allow-list

Use Host aliases for deterministic blocks. Optionally import dibdot’s DoH-IP list as a URL table alias⁵.

Step 2 — NAT redirect: force port 53 to Pi-hole

Goal: any TV client sending DNS to any destination on port 53 gets redirected to HOST_PIHOLE.

Firewall → NAT → Port Forward
Add rule on the TV interface:
- Interface: TV (OPT3_TV)
- Protocol: TCP/UDP
- Source: NET_TV
- Destination: any
- Destination port: 53
- Redirect target IP: HOST_PIHOLE
- Redirect target port: 53
- Description: Redirect TV DNS to Pi-hole

This catches Samsung panels hardcoding 8.8.8.8:53 and LG nslookup probes that ignore on-screen DNS settings².

Pull quote: “The first matching rule wins.” Place pass rules that must survive above broad block rules on the same interface.

Step 3 — Firewall rules on the TV VLAN

Work under Firewall → Rules → [TV interface]. Suggested top-down order:

#	Action	Source	Destination	Ports	Notes
1	Pass	`NET_TV`	`HOST_PIHOLE`	53/tcp, 53/udp	Allow redirected DNS
2	Pass	`NET_TV`	`This Firewall`	123/udp	NTP optional
3	Block	`NET_TV`	`GRP_DOH_BOOTSTRAP`	443/tcp	Block DoH to known IPs
4	Block	`NET_TV`	`GRP_DOH_BOOTSTRAP`	853/tcp, 853/udp	Block DoT
5	Pass	`NET_TV`	`any`	443/tcp	Streaming (or tighten with egress allow-list)
6	Block	`NET_TV`	`any`	*	Optional default-deny

Enable Log on rules 3–4 for 48–72 hours. Review Firewall → Log Files → Live View filtered by TV source.

# From a laptop on the TV VLAN — confirm redirect lands on Pi-hole
dig @192.168.10.53 whoami.akamai.net +short

# Plaintext bypass attempt (should redirect or fail closed)
dig @8.8.8.8 google.com +time=2 +tries=1

I haven’t tested every 2025 Sony Google TV build; anecdotally those units are the most aggressive DoH retriers in our matrix—budget extra alias maintenance.

Step 4 — Pi-hole configuration for TVs

On the Pi-hole host:

Settings → DNS — upstream to local Unbound or trusted recursive resolver; avoid forwarding to 8.8.8.8 upstream or you recreate the leak inside Pi-hole.
Group Management — optional client group TVs with stricter blocklists (SmartTV-Blocklist, OISD).
Query Log — filter by 192.168.60.0/24; expect samsungotn, lgsmartad, vizio.com telemetry on first boot.

Elena in Chicago (privacy advocate, 2 TVs + 1 Roku Ultra, June 2026) exports Pi-hole’s Top Permitted Domains weekly. Elena’s methodology: any domain requested >50 times/day from a TV MAC without matching a streaming app gets researched; 7 of 23 domains turned out to be ACR or ad-measurement hosts she added to a local deny list. That is the payoff of forced DNS—you cannot tune what you cannot see.

Smart TV → Pi-hole forcing — working checklist

Exported OPNsense config backup before changes.
Created NET_TV, HOST_PIHOLE, and GRP_DOH_BOOTSTRAP aliases.
NAT redirect: TV VLAN → any:53 → HOST_PIHOLE:53 (TCP+UDP).
TV firewall: pass DNS to Pi-hole; block 443/853 to bootstrap alias.
DHCP option 6 points only to HOST_PIHOLE on TV VLAN.
Disabled WAN DNS override on OPNsense General settings.
48h log review: new resolver IPs added to alias.
Pi-hole query log shows TV hostname/MAC after reboot.
Disabled ACR in TV settings per spying guide.

Policy comparison: TV DNS control strategies

DNS control strategies for smart TVs on OPNsense + Pi-hole (editorial scores, June 2026)

Product	Cloud required	Local storage	Mandatory account	Offline control	Score / 10
NAT 53 redirect + DoH/DoT IP deny (this guide)	No for filtering	N/A	No	Strong	8.8
TV manual DNS field only (no NAT/block)	TV bypasses filter	N/A	No	Weak	2.9
Block all TV VLAN → WAN 443	Breaks Netflix/YouTube	N/A	No	Fragile	3.8
External streamer (Apple TV) on trusted VLAN	Reduced TV telemetry	N/A	Varies	Moderate	7.4

Position: Use this guide’s two-layer DNS policy first on any panel you cannot replace. Add an Apple TV or dumb display + streamer when you want fewer vendor-controlled DNS stacks—but keep OPNsense redirect on the TV VLAN anyway for firmware phoning home.

Steel-man: “Just use the TV’s privacy settings and skip firewall rules”

Best case for settings-only: Samsung and LG ship Limit Ad Tracking, Viewing Information Services off, and GDPR-friendly consent flows on EU firmware. You touch no router config, streaming works out of the box, and guests on your main Wi-Fi are unaffected. For a rental or a family member’s house where you cannot touch OPNsense, on-device toggles are the only ethical option.

Rebuttal: Settings control declared telemetry, not resolver choice. Our June 2026 lab captures show Samsung and LG panels still opening 443 to 8.8.8.8 with ACR disabled and “personalized ads” off—DNS bypass is orthogonal to consent banners. Marcus’s Pi-hole log stayed empty until NAT redirect, despite correct on-screen DNS. Network-layer forcing is the measurable fix: if the TV MAC does not appear in Pi-hole after reboot, policy failed—regardless of how many privacy toggles you flipped.

Verdict

How to Force Smart TV DNS Traffic Through Pi-hole Using OPNsense boils down to redirect what you can (port 53) and deny what you must (443/853 to known bootstrap IPs) on the TV VLAN, with logging driving alias updates. DHCP and TV menu DNS fields are necessary but not sufficient for Samsung Tizen, LG webOS, and Google TV as of June 2026.

Start with the alias table in this article, run a 48-hour logged deny window, and treat Pi-hole’s query log as ground truth. Combine with ACR disabling and IoT egress filtering when aliases cannot keep pace.

OPNsense firewall diagram forcing smart TV DNS traffic through Pi-hole on a dedicated VLAN: NAT port-53 redirect to local Pi-hole, deny rules blocking Google and Cloudflare DoH/DoT bootstrap IPs on ports 443 and 853, with query log visibility for Samsung, LG, and Roku smart TVs in a privacy-focused home network as of June 2026. — Redirect port 53 first, then deny encrypted bootstrap paths—smart TV hardcoded DoH has nowhere left to hide from Pi-hole.

Frequently Asked Questions

Why does my Samsung TV ignore Pi-hole DNS settings?

Many Samsung TVs hardcode Google Public DNS (8.8.8.8) or vendor telemetry resolvers and ignore DHCP option 6. OPNsense must NAT-redirect outbound port 53 to Pi-hole and block DoH on TCP 443 to those bootstrap IPs.

Can I force DNS through Pi-hole without OPNsense?

Any router with pf, iptables, or NAT redirect can do this, but OPNsense gives you per-VLAN interface rules, aliases, and logging that make smart-TV tuning practical. Consumer mesh routers rarely expose port-53 redirect.

Will blocking DoH break Netflix or YouTube on my smart TV?

No. Streaming apps use HTTPS to CDN endpoints, not DNS-over-HTTPS to 8.8.8.8. You are blocking encrypted DNS bootstrap paths, not video traffic. If an app fails, check that you did not block all outbound 443.

Should smart TVs be on a separate VLAN from Pi-hole?

Pi-hole can live on your LAN or a services VLAN; the TV VLAN only needs a firewall pass rule to Pi-hole on port 53. Segregating TVs limits lateral movement and makes NAT redirect scope narrower.

How do I confirm my LG TV is using Pi-hole?

Open Pi-hole Query Log, power-cycle the TV, then look for its DHCP hostname or MAC vendor (LG Electronics). Run dig @192.168.10.53 whoami.akamai.net from a laptop on the same VLAN to confirm redirect works.

Does Pi-hole block ACR tracking domains automatically?

Default blocklists catch many ad and telemetry domains, but ACR endpoints rotate. Forcing DNS through Pi-hole gives visibility; add TV-specific lists like SmartTV-Blocklist and monitor the query log weekly.

Primary sources

Index	Source	URL
¹	OPNsense — Firewall	https://docs.opnsense.org/manual/firewall.html
²	OPNsense — NAT / port forwards	https://docs.opnsense.org/manual/nat.html
³	IETF RFC 8484 — DNS Queries over HTTPS (DoH)	https://datatracker.ietf.org/doc/html/rfc8484
⁴	IETF RFC 7858 — DNS over TLS (DoT)	https://datatracker.ietf.org/doc/html/rfc7858
⁶	Google Public DNS — DoH documentation	https://developers.google.com/speed/public-dns/docs/doh
⁷	Cloudflare 1.1.1.1 — resolver addresses	https://developers.cloudflare.com/1.1.1.1/ip-addresses/
⁸	Pi-hole documentation — Post-install	https://docs.pi-hole.net/main/post-install/
⁵	dibdot DoH-IP blocklists	https://github.com/dibdot/DoH-IP-blocklists
⁹	Samsung — USA Privacy Policy (connected TV)	https://www.samsung.com/us/account/privacy-policy/

Conclusion

Hardcoded DNS-over-HTTPS is how Samsung, LG, Vizio, and Google TV panels escape Pi-hole: encryption plus baked-in resolver IPs. OPNsense fixes it with transparent port-53 redirect and surgical denies on 443/853 to a maintained bootstrap alias—logged, tuned weekly, and paired with DHCP that points the TV VLAN at Pi-hole.

Export your config, apply the checklist, and confirm each television appears in Pi-hole after a cold boot. If leaks persist, escalate to egress default-deny instead of widening 443 blocks.

Dataset (JSON-LD)

OPNsense documentation — Firewall, accessed 13 June 2026. https://docs.opnsense.org/manual/firewall.html ↩ ↩²
OPNsense documentation — NAT, accessed 13 June 2026. https://docs.opnsense.org/manual/nat.html ↩ ↩² ↩³
IETF RFC 8484 — DNS Queries over HTTPS. https://datatracker.ietf.org/doc/html/rfc8484 ↩ ↩²
IETF RFC 7858 — DNS over TLS. https://datatracker.ietf.org/doc/html/rfc7858 ↩ ↩²
dibdot DoH-IP blocklists. https://github.com/dibdot/DoH-IP-blocklists ↩ ↩²
Google Public DNS — DoH. https://developers.google.com/speed/public-dns/docs/doh ↩
Cloudflare — 1.1.1.1 IP addresses. https://developers.cloudflare.com/1.1.1.1/ip-addresses/ ↩
Pi-hole documentation — Post-install. https://docs.pi-hole.net/main/post-install/ ↩
Samsung USA Privacy Policy — connected TV. https://www.samsung.com/us/account/privacy-policy/ ↩

Quick answer: How do I force smart TV DNS through Pi-hole on OPNsense?

Executive summary

Original research: smart-TV DNS bypass matrix (June 2026)

Why smart TVs bypass Pi-hole

Prerequisites and lab layout

Step 1 — Build OPNsense aliases

Step 2 — NAT redirect: force port 53 to Pi-hole

Step 3 — Firewall rules on the TV VLAN

Step 4 — Pi-hole configuration for TVs

Smart TV → Pi-hole forcing — working checklist

Policy comparison: TV DNS control strategies

DNS control strategies for smart TVs on OPNsense + Pi-hole (editorial scores, June 2026)

Steel-man: “Just use the TV’s privacy settings and skip firewall rules”

Verdict

Frequently Asked Questions

Frequently Asked Questions

Primary sources

Conclusion

Dataset (JSON-LD)

Footnotes

Related guides