@mniswonger 

Thank you for the detailed suggestion.

I know that our devs are always open to features and suggestions so I will make sure to forward this thread.

@Tony 

I spent more time looking at this over the weekend and after doing some Wireshark captures it looks like it is an ARP problem.  I'm assuming on the main Deco there is just a L3 switch separating the networks, which makes sense given they share the same subnet and DHCP lease settings.  I'm not sure what complications this would present to the dev team for providing a way to have a separate subnet for guest.  Do you get feedback from the dev team at all to know if they'll even consider this?  I'm curious since I need to explore other options if it isn't going to happen.  Perhaps instead of a separate subnet they can just have 2 DHCP daemons running, each bound to their own network rather than 1 bound to both.

Thanks.

@mniswonger 

There is no immediate feedback.

If I was looking for a solution now I would probably go for the alternative.

I found somewhat of a workaround I wanted to mention in case anyone else was wanting to use Pi-Hole or AdGuard Home.  Rather than modify the DHCP lease settings to specify DNS servers, leave them blank and instead go to More - Advanced - IPv4 and there specify your internal IP of your Pi-Hole server for the primary DNS server.  The steps to do this will vary depending on whether you have a static/dynamic IP, use PPPoE, etc., and I have not tested it with IPv6.  This seems to work except that for me, my Lancache server can't be reached by devices on the guest vlan, so if they try to download any games from Steam, etc., it fails b/c my DNS server resolves the domains to an internal IP.

Do not make the change I previously mentioned.  It will cause the main Deco to completely change the subnet (it's LAN IP) on reboot.  When I had made the change I could see in the Deco logs that an iptables rule was created and I could then see requests coming from my WAN IP to the Adguard server, which is odd, but I guess that was based on the iptables rule and how the traffic had to route.  I confirmed that port 53 was not open from outside.  This was all working great until I rebooted, and boom, the Deco decided to change it's IP to 172.16.0.1, and the only way I was able to get the app to allow me to change it back was to remove the DHCP server settings for the WAN.  I was able to reproduce this scenario 3 times to be sure this was in fact the cause and it wasn't something else going on (I had seen the Deco change it's IP before because of a bad network device poisoning the ARP table).

Also worth noting, if you don't specify a secondary DNS server for the WAN that resolves to a public DNS server, and you run into this scenario, the Deco will connect to the internet but it won't be able to resolve names, so the "cloud" app won't connect.  You'll basically be forced to do a factory reset.

@mniswonger 

Any updates on this?

@jacazzopardi 

No.  I ended up selling my Decos and getting some Omada access points and a controller.