I am having trouble connecting my Nest cameras to my network.
I am running Aruba 300 series Access Points and a Fortinet firewall (which is doing the routing).
The Nest cameras never connect, and there is no real way to get input on what is happening.
How do I solve this problem? How do I determine if it is the Aruba AP or the Fortinet router that is assigning the IPs?
I just spent an hour trying to figure this out. No one had discussed in any forum, so this is the best place to put what I figured out so that it's internet-searchable for the next guy.
If you want to downvote me to oblivion for posting like this, go ahead. But from one IT person to another, I'd ask you to just ignore this, let it archive, and let the next guy banging his head have a chance to stumble across it.
We run Aruba Access Points, and those are managed by a Fortinet Firewall.
We could not get Nest Cameras to connect. I originally thought this was going to be a 2.4GHz vs 5.0GHz issue, as that is often a problem. But after watching syslog of both the Arubas and the Fortinet, I could see the Nests were getting an IP. That let me know the Arubas were working fine.
So the question is why the Nest app says it wasn't connecting.
After digging, I saw that there were blocks in the Web Filter on the Fortinet. The blocks were for oculus1390-us1.dropcam.com, or so I thought.
In the Web Filter (Log & Report -> Web Filter), I could see these blocks taking place because oculus1390-us1.dropcam.com was in the 'UnRated' category, and we have that blocked. So I tried creating a Web Rating Override (Security Profiles -> Web Rating Overrides), but it was telling me that the dropcam domain was a recognized domain (General Business -> Information Technology).
So why is the Web Filter telling me that this is UnRated, but Fortinet (FortiGate on the intelligence side) is saying it's legit?
Because I wasn't looking at the right column. The Web Filter log view was doing some intelligence for me, and was resolving the IP 104.155.137.34 to the domain oculus1390-us1.dropcam.com for me. The Nest camera was actually trying to hit that IP, not the domain to which it resolves. When I look up that IP in the rating (either on their ratings site, or within the Web Rating Override tool, which has a ratings lookup on the page that connects to the Fortigate site), it obviously comes back as 'UnRated'. So there was my problem.
Google, in its infinite wisdom, has done one of two things: either hardcoded the IP of a dropcam site into the Nest itself, or the Nest is reaching out to a separate (legit) domain, and the Nest camera is being issued an IP for lookups (rather than a domain name). I didn't go back and see what domains the Nest is hitting, to see if it's pulling other data from another domain before trying to hit the hard IP.
So Google has DNS names for these IPs, but it's choosing not to use them. It's just trying to hit the specific IPs, which may fall into the 'UnRated' category on your Firewall, or may be blocked by another policy.
So I created a Web Ratings Override for the IP, set it to the same rating as the DNS name provided, and the camera connected.
But the next camera did not connect. After looking at the Web Filter log again, I could see that this camera was trying to hit 35.221.16.97.
Oh boy. Another specific IP.
So if you are connecting a plethora of Nest cameras, you have the potential of needing to override a ton of IP address space, because Google is not actually using the DNS names tied to the IP (which would allow for a convenient wildcard web filter Allow statement).
So if you run a firewall, and you are having trouble connecting a Nest to your campus APs, check your firewall policy and see if you are blocking UnRated websites. If so, you're going to need to do some IP whitelisting to get the Nests to work.
This is obviously an oversight by Google, and it makes life difficult for those who want to run a modest firewall policy and protect against malware drive-by DNS names. It's as aggravating as the fact that they hardcode their Google DNS server IPs into their devices, instead of taking DNS via DHCP.
Here are the two IPs my sample Nests were hitting, and here's where they should've been pointing to (fortunately, my Fortinet was doing some of this lookup already, which is what was confusing me).
35.221.16.97 - oculus5699-us1.dropcam.com
104.155.137.34 - oculus1390-us1.dropcam.com
