HOW TO: Lock-down firewall ports — Nest Thermostat & Nest Protect smoke detector
This is a SOLUTION posted for the benefit of others and for comments
This is a solution to place Nest devices on their own subnet and give them minimal access to your network and the cloud. If you are running a Nest Thermostat or Nest Protect smoke detector, the information here will tell you what WAN access you need to grant. Most of this information is well-known, but I've spent a good amount of time digging into details today and thought I'd share. I'd appreciate comments and criticisms as well.
Nest Thermostat E required connectivity:
- DHCP — Access to a DHCP server is, of course, required to provide an IPv4 address. I did not attempt any IPv6 connectivity. The Nest Thermostat E transmits ICMPv6 Router Solicitations, but gives up if there's no response. I also observed a few ICMPv6 Multicast Listener Report Message packets, which also ended after a few seconds.
- DNS (UDP port 53) — Many DNS requests are generated to resolve the addresses of numerous services Nest connects to.
- NTP (UDP port 123) — The Thermostat needs the time (smoke detectors do not).
- HTTPS (TCP port 443) — Comprises about half of cloud communications.
- TCP port 9543 — The other half of communications goes to the cloud here.
- OPTIONAL: HTTP (TCP port 80) — Upon connecting to WiFi, an HTTP request is sent to http://clients3.google.com/generate_204. The URL merely returns a 204 No Content HTTP status code. The purpose of this request appears to be testing to see if the WAN is actually connected to the Internet. A WiFi network behind a captive portal (password screen or similar) won't return a 204 status. You can permit TCP port 80 traffic, but I observed no problems creating a firewall "Reject" rule. The "Reject" rule returns a TCP RESET which the Nest Thermostat honors. A "Block" rule resulted in three TCP Retransmission attempts before the Thermostat gave up.
Nest Protect smoke detector required connectivity:
- DHCP — Required to obtain IPv4 address. I did not observe any IPv6 activity from the Nest Protect smoke detectors, nor did I attempt any IPv6 configurations.
- DNS (UDP port 53) — The Nest Protect makes many DNS requests.
- TCP port 11095 — Nest Protect solely uses this port for all cloud communications.
Locking it Down: Separate Nest Interface and Firewall Rules
I created a separate interface and subnet on a stand-alone VLAN for my Nest devices. My WiFi access points advertise a separate SSID for this VLAN. Traffic is not mixed with any other LAN.
Here are my firewall rules for the Nest interface—a discussion of each follows:
Nest Device LAN access firewall rules
I operate my own local DNS resolver and NTP server on my LAN. I do not want IoT devices reaching out to public servers (to minimize information leaks). Thus, the first two firewall rules permit DNS (UDP port 53) and NTP (UDP port 123) traffic from the Nest network to the router's LAN address (where DNS/NTP resides).
But the Nest devices don't automatically ask for my local DNS/NTP server address. I have to tell it where to find my DNS resolver and force it to go to my NTP server:
DNS: The Nest devices honor the Domain Name Server (DHCP Option 6) handed out by your DHCP server. Normally, this is the same as the interface gateway (router) address, but in this case, I configured DHCP to specifically hand out the address of my DNS resolver which is on a different subnet (LAN address):
Because my DNS server is on a different subnet, a firewall rule permitting DNS traffic to that LAN address is necessary.
NTP: The Nest devices do not honor the NTP server address handed out by DHCP (even though the Nest Thermostat requests it with its DHCP request). The Nest Thermostat makes NTP requests to several public IP addresses. To force network time requests to my local NTP server, I used a NAT Port Forward rule to redirect UDP port 123 packets not destined to my LAN address (
!LAN address) to instead go to my LAN address:
Again, because the NTP server is on a different subnet, a firewall rule is needed to allow traffic from the Nest network to the LAN address where the NTP server listens.
Note: I could have configured my DNS/NTP servers to also listen to the Nest gateway address. Then I wouldn't need these two LAN firewall rules. I chose not to do so, as it complicates configuration (Nest configuration isn't in one place anymore), increases attack surface, and increases the likelihood of breaking the configuration with future changes to DNS/NTP.
The third LAN access rule, is a "Reject" rule to prohibit any other traffic from the Nest network from reaching a private (RFC 1918) network address. This is just for good practice. I haven't observed the Nest devices attempting any such thing.
Nest Device WAN access firewall rules
Here are the WAN access rules:
- TCP:80 (HTTP) has a "Reject" rule. This rule isn't necessary since port 80 isn't allowed through by any later rule that follows; however, the Nest Thermostat does honor the
TCP RESETsent by this reject rule and stops trying to connect to Google's
generate_204service (see discussion of this above).
- A rule permitting NTP (UDP port 123) connectivity is disabled because I use a NAT port forward to redirect NTP requests to my local NTP server on the LAN. This rule is necessary if NTP requests need to go to the WAN.
- WAN access is permitted for each of the required protocols: TCP:443 and TCP:9543 (for the Nest Thermostat) and TCP:11095 (for the Nest Protect).
DON'T FORGET NAT TO WAN!
Don't forget to create an Outbound NAT rule to permit the Nest network traffic to actually get to the cloud:
If you are not forcing Nest to use your own local NTP server, you also need to permit UDP traffic in your Outbound NAT rule.
@kevinrice Thanks for this excellent summary!
I would like to add that as of mid-2021, it seems the thermostats also require 11095/TCP outbound, like the Protect devices. I have a 3rd-gen thermostat running software 6.2-22 that now requires this port where it previously did not.
@coredump4 Thanks for that info! I'm running the basic Thermostat E (because I don't like my thermostat trying to think for me). Perhaps 11095/TCP is new, or perhaps it's not used on the E model? I didn't observe it when I authored this anyway. But it's unimportant (to me), since that port is already open for my Nest VLAN.
I'm glad this post (and my effort) are useful to someone. Merry Xmas!
This is good info. One that could probably be used in the official documentation as an example.
good job on this.
i have graylog running so I saw the denies coming in. Your post helped confirm that I should be opening up these ports.
I saw this post while searching for google nest help.
I am trying to install a google thermostat nest 2020 version and can’t get it on my network. I have a arris surfboard sbg6900-ac gateway and iPhones. I did get it to work when I used my wife’s iPhone 8 as a hotspot and used the google home app on my iPhone 12. But I don’t want to keep it setup as a hotspot. Do you have any ideas or recommendations as to router settings that could be causing issues?
Dave, all I'm able to find on your topic appears to be your own posts elsewhere. I think ensuring both devices are on 2.4 GHz is a good path to explore—you didn't clearly indicate if your failed attempts were with the iPhone 12 or 8.
I have seen your struggle first hand. I have several WiFi SSIDs in use (as my access points can broadcast sixteen separate WiFi signals). One SSID is dedicated to Nest and it's on a dedicated VLAN. I do need to ensure my phone is connected to the Nest SSID or setup fails. My Nest SSID is 2.4 GHz only. On second thought, I don't think setup in this case, but the Nest devices get programmed with the same SSID and password the phone is using. So, I need to put the phone on the SSID I want the Nest devices to use.
HOWEVER, after setup completes, I can move my phone off the Nest SSID and the app continues to work EVEN THOUGH my phone uses 5 GHz on it's normal WiFi SSID which is completely different.
Off the top of my head, I believe my router is configured to permit the Nest VLAN and my regular phone VLAN to talk to each other (but only on the ports I mention above). If I'm wrong about that—I need to re-examine the web I created to know for sure —then the phone app doesn't communicate to the Nest devices directly, and goes through the Nest servers instead. I'm pretty sure they talk locally.
My uncertainty above isn't the point I'm trying to make, however. My point is once the devices are setup, you may not have as much trouble keeping it working. So, here's what I suggest, since you've had success with the hot spot method:
TURN OFF your router. Set your hot spot to use the exact same SSID and password that your router uses. Perform the setup. If you're successful, the Nest devices will be programmed to connect to the same SSID that your router broadcasts. Now, turn off the hotspot and turn your router back on.
See if that contorted method gets you through the setup and gets that success "transferred" over to your router.
If that succeeds, you'll at least have a work-around to get the setup done. I always have setup glitches too because of the security and VLANs I've created and that makes things more complex. But, once I get it working, I don't have troubles.
My second thought involves your WiFi settings. My access points have a setting to allow or deny devices talking to each other. The "deny" configuration would be good security in an application where you might have public users or insecure users that have no business attempting to communicate with other users on the WiFi. See if your router/WiFi has any settings that look like this one. My debugging brain always starts by turning off all security or weird settings and, if that works, turn them back on one at a time to try to narrow down the problem.
Another thought is, I know setup uses Bluetooth. It's not entirely clear to me, however, if setup requires Level 2 (Ethernet packet) communications or only requires Level 3 (IP packet) communications.
Is there a WiFi/router setting on your device that sounds anything like "Allow L2 packets" or mentions L2/L3 at all, or sounds anything like that? Chromecast requires L2, and a setting that mentions enabling Chromecast is worth trying. But I'm not certain Nest setup requires L2.
Please post back what you find.