Hi,

I've recently been having massive problems with devices failing to connect. After running various diagnostics i've discovered there is a rogue dhcp server which according to wireshark is nestlabs. I assume it's one of my nest thermostats or smoke detectors.

It's on my network with a subnet of 192.168.0.x but is spamming the network with 192.168.168.100 ip addresses saying it is 192.168.168.1.

How is this leaking on to the 192.168.0.x subnet and how can i prevent it without isolating it totally. I obviously want to keep the nest thermostats on the same network so i can control them from my phone.

Thanks .

zebbedi wrote:
It's on my network with a subnet of 192.168.0.x but is spamming the network with 192.168.168.100? ip addresses saying it is 192.168.168.1?.

I'm not entirely clear which networks are involved here (a typo somewhere, maybe?) ... but I will assume that you've purposefully put the Google devices on their own subnet, but with the "Interlan-routing" box ticked?

Traffic for each subnet is supposed to be kept separate apart anything specifically targeted at the other subnet. Broadcasts -which DHCP uses - are not supposed to be routed , but it seems they are being ... and it seems one of your Google devices is happy to be DHCP server for all and sundry. (You've probably gathered all this already )

This Draytek feature might be a bug - or maybe they think it's helpful? (I've seen DHCP between tagged VLANs on my 2860, which isn't supposed to happen either). Or maybe you've 'accidentally' configured the DHCP Relay settings? :wink:

The answer probably, is to add some firewall rules. :idea:

My strategy, is to add a first rule, which says "Block everything unless there is a further match" - then to add a rule for each type of allowed traffic (which may just be HTTP/S and ICMP). If you implement a SYSLOG server, and tick the "Syslog" box on that first rule, you'll be able to see the requests that are initially blocked ... and you can then add exceptions for them (if appropriate).
Perhaps consider using the customisable "Objects", so you don't end up with IP addresses scattered throughout your firewall rules.

An alternative approach, is to remove that "Enable Interlan-Routing" flag and to manually connect to the SSID that you're using for the Google Devices - every time you want to access them . With some devices you have to do this anyway ... Sky Q, Tivo and Drayton's Wiser apps. all use Broadcasts to find the 'hub' and so don't work across subnets (or VPNs). (Which is what makes me think that DHCP is somehow being made an exception of...)

I don't know anything about Nest thermostats but I have a Vaillant "smart" thermostat which I can control with my phone, but that control takes place over the internet via Vaillant's servers. Hence the thermostat (and similar devices such as Kasa plugs) can be on a subnet which is completely isolated from my main network - all they need is access to the internet, which they get from the router. The point of phone control is that you can do it from anywhere....

I think i misinterpreted the wireshark logs. I disabled all wifi on the network and it continued, so then i pulled each hardwired device one by one and isolated it to a ycam cctv camera. Unplugging that everything is now working as expected.

There wasn't a typo in my original post (although my terminology may be slightly wrong). The camera does sit on the 192.168.0.xxx subnet with an IP of 192.168.0.11 and then spams DHCP issuing IP addresses of 192.168.168.xxx claiming it is 192.168.168.1.

I've had the camera for years but think it may be some kind of mechanism to allow you to 'discover' it and wondering if it's somehow lost it's settings.


That's a very good point about the thermostats. I could probably set up an alternative lan and put them all on that?

Why not? All my IOT wifi devices are on the 192.168.3.x LAN - but don't forget to untick Interlan routing :lol:

zebbedi wrote:
I could probably set up an alternative lan and put them all on that?

I obviously completely misunderstood your current configuration :shock:

You really don't want untrustworthy I.O.T. devices on your main/only network ... (while acknowledging the challenge of maintaining all their functionality)