Honeywell wifi thermostats have a bit of a reputation when it comes to playing nice with even the simplest home network. It only gets worse on slightly more sophisticated environments. But I wanted to put all my IOT devices on their own VLAN for security, so it was time to face the angry bear.
Note that many hours were wasted due to my own ignorance, and a remarkable lack of practical examples in product documentation. Sometimes I thought that the manufacturers really didn't want anyone to succeed at this. Having said that, it's clear from the many responses to questions in customer forums that isn't actually the case. It's just the operation of the old adage, "Those who can, can't teach".
- Hardware: An EdgeRouter 4 router with intervening Netgear "smart" switches (GS308T, GS308E) and a Netgear WAC505 AP.
- Network: 3 VLANs: VLAN1 ("default" or "management") for most of the computers at home; VLAN7 for guests; and VLAN8 for IOT devices (not my actual VLAN names).
- SSIDs: 3, one each for home, guest and IOT.
I'm not going to discuss how I set up that environment here, except to say that when creating VLANs you should pay attention to the examples (if any) given by your device manufacturers. The only VLAN on my switches having untagged ports is VLAN1, with tagged ports connecting to other network devices. For the remaining two VLANs I'm currently only using tagged ports to other network devices, as the wifi AP has the ability to designate a specific VLAN for an SSID.
The firewall rules around my IOT VLAN are described in this gist. The key for me was discovering that a stateful (accept established/related) rule with my default network as the destination would grant access to my IOT devices, but not the other way around (i.e., clients on the IOT network can't access the default or guest networks). The rules do allow IOT network devices to make DHCP and DNS connections to the router.
Someone once quipped, "I'm not saying the problem is DNS. But it's DNS"
Although the DHCP server for my IOT VLAN was configured to pass 8.8.8.8 and 8.8.4.4 to clients as their primary and secondary DNS servers, word in the forums was that some Honeywell thermostats would still make their DNS queries directly to the network gateway. As a result, I also configured the router to forward DNS requests coming into 192.168.8.1 (not my real IOT network gateway).
Configuring the Wifi AP was pretty straightforward, once I had experimented with it for awhile. Unfortunately, as with most things, I didn't take detailed notes on all the wrong paths I wandered down to share as a warning to others. But then, the real fun is in the journey, isn't it?
Although I'm using a Netgear AP, its configuration should not be too different, at least conceptually, for any other AP.
My IOT SSID has a strong password, of course, is visible and operates on both 2.4 and 5 GHz. The 5 GHz part may be wishful thinking, since every IOT devices I have seen so far only has a 2.4 GHz radio. Previous rumors that these thermostats require a 2.4 GHz only SSID appear to no longer be true.
As I stated above, the ethernet cable feeding the AP comes from a switch port that passes 3 different VLANs to it. It is an untagged port for VLAN1 and a tagged port for VLANs 7 (guest) and 8 (IOT).
I selected 8 as the VLAN ID for the iot SSID, left "client isolation" disabled, and otherwise kept the defaults.
In contrast to previous failed attempts, the above configuration finally allowed my thermostats to grab IP addresses from the IOT network DHCP server and phone home to Honeywell's servers. The three most important changes I made along the way that allowed this were:
- Allowing DHCP and DNS access through the IOT network gateway
- Enabling DNS forwarding from the IOT network gateway by the router
- Disabling wifi client isolation on the IOT network