Reply
New Member
Posts: 3
Registered: ‎12-09-2018
Kudos: 1

USG 4 Pro + Pi Hole + Family Shield DNS for Kid VLAN + redirect hardcoded DNS config.json rules

[ Edited ]

I've tried reading through every one of the dozens of USG + Pihole + redirecting hardcoded DNS servers threads, and think I have a handle on things.  Here are the relevant rules I have come up with for my config.json (my first time dealing with all of this, apologies).  Can someone double check that it will accomplish what I am hoping to do?

 

Management details:

USG Pro 4 (set to forward DNS requests to PiHole)

PiHole is 192.168.1.4

VLAN 10 is main household LAN

VLAN 20 is Kids LAN

VLAN 30 is IoT

 

Goals:

1)  Run all DNS requests, and re-route all hardcoded DNS requests, for VLAN 10 and VLAN 30 through PiHole, and masquerade the responses so the devices with a hardcoded DNS server are none the wiser

2)  Route all DNS requests, and re-route all hardcoded DNS requests, for VLAN 20 through OpenDNS family shield (I recognize it would be better to get a second PiHole dedicated to VLAN20, but for now this is my workaround), and masquerade the responses so any devices requesting a specific DNS server are none the wiser

3)  Maintain ability to keep track of which devices are pinging what DNS servers, and which devices are using PiHole ad blocking the most

 

Questions:

1)  Do I need a masquerade rule for each VLAN?

2)  I know that eth0 is the WAN port for the USG Pro, but am confused about how that translates over to the inbound/outbound interface portions of the rules.  Do I have it right (all eth0, no eth1)?

3)  What is the best method to accomplish goal 3 above?  Send VLAN10 and VLAN30 to PiHole directly for DNS queries (in the VLAN settings)?  Send VLAN10 and VLAN30 to the USG, and then the USG on to the PiHole (I believe this is how I currently have it set, though I imagine that will result in all PiHole stats being linked to the USG rather than to specific devices)? 

 

Config.json code:

 

{
	"service": {
		"nat": {
			"rule": {
				"1": {
					"description": "DNS Redirect VLAN10 to PiHole",
					"destination": {
						"address": "!192.168.1.4",
						"port": "53"
					},
					"inbound-interface": "eth0.10",
					"inside-address": {
						"address": "192.168.1.4"
					},
					"log": "disable",
					"protocol": "tcp_udp",
					"type": "destination"
				},
				"2": {
					"description": "DNS Redirect VLAN20 to OpenDNS FamilyShield",
					"destination": {
						"address": "!208.67.222.123",
						"port": "53"
					},
					"inbound-interface": "eth0.20",
					"inside-address": {
						"address": "208.67.222.123"
					},
					"log": "disable",
					"protocol": "tcp_udp",
					"type": "destination"
				},
				"3": {
					"description": "DNS Redirect VLAN30 to PiHole",
					"destination": {
						"address": "!192.168.1.4",
						"port": "53"
					},
					"inbound-interface": "eth0.30",
					"inside-address": {
						"address": "192.168.1.4"
					},
					"log": "disable",
					"protocol": "tcp_udp",
					"type": "destination"
				},
				"5001": {
					"description": "MASQ DNS requests from VLAN10",
					"destination": {
						"address": "192.168.1.4",
						"port": "53"
					},
					"log": "disable",
					"outbound-interface": "eth0.10",
					"protocol": "tcp_udp",
					"type": "masquerade"
				},
				"5002": {
					"description": "MASQ DNS requests from VLAN20",
					"destination": {
						"address": "208.67.222.123",
						"port": "53"
					},
					"log": "disable",
					"outbound-interface": "eth0.20",
					"protocol": "tcp_udp",
					"type": "masquerade"
				},
				"5003": {
					"description": "MASQ DNS requests from VLAN30",
					"destination": {
						"address": "192.168.1.4",
						"port": "53"
					},
					"log": "disable",
					"outbound-interface": "eth0.30",
					"protocol": "tcp_udp",
					"type": "masquerade"
				}
				
			}
		}
	}
}

Sorry if these are dumb questions that have been answered before---I'm just looking for confirmation that by merging all of the advice from various other threads, I have not accidentally missed something.

Reply