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.