Two subnets, one pi-hole - weird behavior (Disney Circle blocking)


Please follow the below template, it will help us to help you!

Expected Behaviour:

I have two subnets on VLAN 1 and VLAN 30: which is my main LAN used for kids, tablets, general. which has a Disney Circle for content filtering. I have another subnet which is which is the “adult” network, which has a Hurricane Electric IPv6 tunnel. Both networks can talk to each other (no firewall rules between the two using an ER-4). I have built a pi-hole server running on a Pi3+ and attached it hardwired to the network. The device is assigned a static IPv4 address ( and has access to the Internet. It also has an auto assigned IPv6 address which is global. I want the pi-hole on the network to serve both subnets.

Actual Behaviour:

The pi-hole works as expected on the network and blocks ads. The pi-hole serves DNS for the network but does no ad filtering (weird). The server is visible from the network and dns lookups work as expected. I have tried expanding the subnet mask to include both networks (why the CIDR is /19 in setupvars.conf). I have also selected option 3 in the DNS settings page to accept requests from all networks and origins. nslookup queries on the network show that devices are getting DNS results from the pi-hole, just not ad filtered?

Debug Token:

[✓] Your debug token is: q66qpebipk

Thanks in advance. I have tried several solutions presented here and elsewhere. The netmask solution was the latest (changing the CIDR in setupvars.conf to /19 instead of /24, but doesn’t help). It seems like the pi-hole is refusing to block ads for devices outside of its own network, however it happily serves DNS requests.


Try to confirm these items. The devices on the main VLAN

  1. Get Pi-hole as their only DNS server via DCHP.
  2. Can resolve DNS through Pi-hole both implicitly (nslookup and explicitly (nslookup
  3. Get the Pi-hole’s IP address back when resolving blocked domains manually.
  4. Have their queries recorded in the dnsmasq log (/var/log/pihole.log, pihole -t, or the Query Log on the web interface).


Thanks for your time in helping me resolve this configuration issue. I’m sure I’m just missing something obvious.

Question 1: I had been setting the DNS entries manually to avoid borking up the network (wife and kids you know), but I went ahead and assigned the pi-hole address into the main net ( DHCP server. Then connected a laptop to do the testing. Pasted below is a snippet with output of ipconfig /all which shows it has the right address and only that address:

Question 2: Pasted below is the output of the commands you specified:


Question 3: Struggled a bit to figure out how to capture this correctly, but settled on ping -a. If I need to something else, let me know:


For validation, on the same machine, I switched over the the net and did the same thing, but had a different response:


Finally, the computer that I’m using is not showing up in the query log, at all. I do have a few entries for a phone, but they are all passed. Not nearly the traffic I would think it should be seeing, so this is likely the problem. For some reason, I can get DNS resolution, but without the pihole seeing it enough to log. When I am connected to the same network that the pihole is attached to I see query’s along with blocks in the log. I can’t figure out where it could be getting DNS from when on the main LAN. You can see there is only one listing for the DNS server in ipconfig. I also checked the EdgeOS config tree to ensure dnsmasq is NOT enabled on the router.

Thanks again,



It looks like on the main VLAN the DNS traffic is getting redirected to a different server instead of going through Pi-hole. If it had gotten any response from Pi-hole, it would have been logged.
Check if you can resolve pi.hole. If you can, then it is hitting Pi-hole correctly. Otherwise, the request is not actually going to Pi-hole.
To check if a blocked domain is blocked by Pi-hole, you can also use the same nslookup commands. You can see in the last screenshot that Pi-hole returned the null domains in response to a blocked domain.


I agree with you. I will post a question over in the Ubiquiti forums asking for insight. Sounds like the ER-4 is doing something as the traffic flows through it. I have a smart switch with port mirroring, would Wireshark be able to shed some light on the subject if I could capture a packet? I’m not familiar with how to do all that, but it may be something I try if I can’t find a solution.


Figured it out and documenting here for others. Disney Circle use ARP poisoning or spoofing to apply parental controls to all devices on the subnet. Apparently, it doesn’t matter what DNS you provide your DHCP server, as it has its own DNS-type service running. On a hunch, I disabled the Circle and immediately the pi-hole started working on the main LAN subnet. Now I have to figure out if they can co-exist, or I have to choose between parental controls and ad control.

Thank you Mcat12, appreciate your help and this awesome code you guys have developed.



Were you able to find out how to make the circle and pi-hole coexist? I am having the exact same issue and isolated it to the circle. Once I disconnect the circle DNS resolution works perfectly. The second I plug it in, DNS begins failing. It even fails if I SSH directly to the pi-hole and try nslookup.

FWIW I set the pi-hole to unmanaged within the Circle app.




Actually yes. When you unplug the circle it doesn’t turn off. When I disabled the circle via the app and then re-enabled it everything worked together. What I think was happening is the circle was using the old DNS originally given out by the router DHCP server. When I updated the router DHCP to the Pi-hole address, then re-enabled the circle, it apparently grabbed the Pi-hole DNS and started behaving.

Likely if I would have waited for the circle’s lease to expire it would have worked then.

Downside is that all of the clients that are managed by the circle show up as the circle’s IP in the Pi-hole. But, it is working!


This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.