Your Smart TV is probably ignoring your PiHole

If you’re using PiHole on your network to block ads and prevent your various smart devices from sending tracking information to their manufacturers, you might be surprised to find out that some of these devices are using a sneaky tactic to bypass your PiHole entirely.

Smart devices manufacturers often “hard-code” in a public DNS server, like Google’s 8.8.8.8, and their devices ignore whatever DNS server is assigned by your router - such as your PiHole.

Nearly 70% of smart TVs and 46% of game consoles were found to contain hardcoded DNS settings - allowing them to simply ignore your local network’s DNS server entirely. On average, Smart TVs generate an average of 60 megabytes of outgoing Internet traffic per day, all the while bypassing tools like PiHole.

Force all DNS queries through PiHole

Fortunately, with a few simple firewall rules, you can intercept these hardcoded DNS queries and redirect them to your PiHole. These instructions are for pfSense, however you should be able to adapt them for Sophos XG, Ubiquiti EdgeRouter, etc.

Create NAT Rules

Log in to your pfSense admin interface, and navigate to Firewall > NAT > Port Forward.

We’re going to create two Port Forward NAT rules - one to redirect any DNS queries originating from devices on the LAN to PiHole, and another to allow PiHole to commmunicate with external DNS servers. We will also create an additional outbound NAT rule that will make this process invisible to any clients on the network with hardcoded DNS.

NAT Rule 1: Redirect DNS queries to PiHole

Click the Add button to create your first new NAT Port Forward rule.

  • Interface: LAN
  • Protcol: TCP/UDP
  • Source: LAN net (you may need to click the blue show advanced button to see this option)
  • Destination - Invert match: Checked
  • Destination - Type: Single host or alias
  • Destination - Address/mask: Your PiHole’s IP address
  • Destination Port Range - From: DNS
  • Destination Port Range - To: DNS
  • Redirect Target IP: Your PiHole’s IP address
  • Redirect Target Port: DNS
  • Description: Intercept any outgoing DNS queries and redirect them to PiHole.

NAT Rule 2: Exempt PiHole from DNS query redirects

Click the Add button to create your second new NAT Port Forward rule.

  • No RDR (NOT): Checked
  • Interface: LAN
  • Protcol: TCP/UDP
  • Source - Type: Single host or alias
  • Source - Address/Mask: Your PiHole’s IP address
  • Destination: Any
  • Destination Port Range - From: DNS
  • Destination Port Range - From: DNS
  • Description: Allow PiHole to reach external DNS servers

Note: pfSense (and most other firewalls) process rules from top to bottom. Make sure you drag the second rule exempting PiHole from DNS query redirects above the first rule we created - otherwise PiHole will not be able to contact external DNS servers.

NAT Rule 3: Prevent clients from giving unexpected source errors

Finally, we need to create an outbound NAT rule. Navigate to Firewall > NAT > Outbound.

  • Interface: LAN
  • Address Family: IPv4+IPv6
  • Protocol: any
  • Source - Type: Network
  • Source - Network for the outbound NAT mapping: Your internal LAN network
  • Destination - Type: Network
  • Destination - Network for the outbound NAT Mappings: Your PiHole’s IP Address
  • Destination Port Range: 53
  • Translation: Interface Address
  • Description: Prevents hardcoded DNS clients from giving unexpected source error after DNS redirected to PiHole.

Test it out

You can easily test to make sure your DNS redirection is working properly.

  1. Create a new, temporary internal DNS entry on your network (“piholetest.example.com”), and point it to 10.0.1.1. You can do this right from PiHole under Local DNS Records.
  2. Manually set your computer’s DNS server to 1.1.1.1.
  3. Open a terminal window (or command promt on Windows), and run nslookup piholetest.example.com
  4. If you set this up correctly, nslookup should return 10.0.1.1. Your computer thinks it’s receiving DNS records from 1.1.1.1, while in reality they are coming from your PiHole.

     macbookpro:~ labzilla$ nslookup piholetest.example.com
     Server:		1.1.1.1
     Address:	1.1.1.1#53
    	
     Name:	piholetest.example.com
     Address: 10.0.1.1
    
  5. You can further demonstate this by temporarily disabling the first NAT rule we created, and running the same nslookup piholetest.example.com command:

     macbookpro:~ labzilla$ nslookup piholetest.example.com
     Server:		1.1.1.1
     Address:	1.1.1.1#53
    	
     ** server can't find piholetest.example.com: NXDOMAIN 
    

    As “piholetest.example.com” doesn’t exist on the public Internet, the real 1.1.1.1 server has no record to provide - resulting in your nslookup request returning a NXDOMAIN error.

Don’t forget to revert your computer’s DNS settings back to their original value, and reenable any firewall rules you temporary disabled while testing.