Arlo And Arlo Pro base station not discovered behind SonicWALL firewall

[GBMaryland]

I recently upgraded my internal firewall to a sonic wall TZ470.

while everything else in the house appears to work, the Arlo bass stations no longer appear to connect to the Internet.

A previous thread also asked why this would be. The response from the forum administrator was that it’s likely that Arlo uses non-standard traffic over standard ports.

What that really means is “ Arlo operates outside of standard security practices making the devices impossible to properly install behind a firewall without excessive reconfiguration.”

My question is: is anyone running an Arlo behind a firewall,  and what did you have to do in order to get Arlo traffic properly allowed by next generation firewalls?

GB

[GBMaryland]

What it’s worth there is this thread, and not to be mean but it’s pretty much worthless (in so far as how the form administrator answered the question in the last message):

https://community.arlo.com/t5/Arlo-Pro/Arlo-Pro-base-station-not-discovered-behind-SonicWALL-firewal...

[StephenB]

---

@GBMaryland wrote:

 (in so far as how the forum administrator answered the question in the last message):

---

@jguerdat is not (and never has been) the forum administrator.  We are both customers, and do not work for Arlo.

On your main question, I suggest asking Sonicwall how to set up the firewall to allow all traffic through to the base station in both directions (maintaining NAT).  The relevant ports are 80, 443, and 123.  You don't need to forward those ports to the base, but you do need to ensure that the base can connect outbound on all three ports, and that the firewall will not filter the traffic between the base and the arlo cloud.

[GBMaryland]

I suspect port 123 is the actual problem.

I’ll look at that and see about assigning specific IP addresses to the Arlo devices so that we can allow only those devices to get out on the indicated ports.

inspection of the traffic is relegated to non-standard traffic over standard ports and outdated SSL or TLS protocols.

i’ll also attempt to set up a filter to find out if the Arlo devices are using antiquated encryption protocols which would also be blocked.

[StephenB]

---

@GBMaryland wrote:

I suspect port 123 is the actual problem.

That is used for NTP, so I doubt it.

[GBMaryland]

True.... but considering that 80 and 443 are not blocked, then 123 is all I can think of.

Unless the Arlo system is attempting to connect to a country other than the United States or Europe.  In which case, the cameras are being blocked because they are attempting to go somewhere they shouldn't be.

Does Arlo use cloud providers outside of the USA or EU?  If so, do they have a list of providers?

The other possibility would be non-standard traffic over 80/443/123... it's not HTTP/HTTPS/NTP over those three ports, then the devices may be being blocked because they are acting sketchy.

[StephenB]

---

@GBMaryland wrote:

Unless the Arlo system is attempting to connect to a country other than the United States or Europe.  In which case, the cameras are being blocked because they are attempting to go somewhere they shouldn't be.

---

my.arlo.com is hosted by cloudflare, though of course they could have back-end services that use other providers.

---

@GBMaryland wrote:

The other possibility would be non-standard traffic over 80/443/123... it's not HTTP/HTTPS/NTP over those three ports, then the devices may be being blocked because they are acting sketchy.

---

I haven't tried to analyze the traffic. I'd be very surprised if 123 isn't normal NTP, but 80/443 is another matter.  Of course the base is not a browser, so even if the traffic is compliant to https, its traffic still wouldn't look like normal web traffic to the firewall.

[GBMaryland]

---

@StephenB wrote:I haven't tried to analyze the traffic. I'd be very surprised if 123 isn't normal NTP, but 80/443 is another matter.  Of course the base is not a browser, so even if the traffic is compliant to https, its traffic still wouldn't look like normal web traffic to the firewall.

---

Still working to analyze the Arlo base stations IP traffic…

It is absolutely not normal for the ports its using. 

[StephenB]

---

@GBMaryland wrote:

---

Still working to analyze the Arlo base stations IP traffic… It is absolutely not normal for the ports its using. 

---

It's hard to get much when the traffic is encrypted.  Arlo might simply be using port 80/443 because they are normally open.  Or they could be using http methods (get, put, etc) in a way that isn't typical for a web app or a browser connection.

The net is that you'll need to somehow whitelist the base if you want it to work.

[GBMaryland]

The packet capture shows all the packets going through the firewall, with nothing being dropped.

Also, that everything is being forwarded.

This is a real brain teaser.

[StephenB]

---

@GBMaryland wrote:

The packet capture shows all the packets going through the firewall, with nothing being dropped.

Also, that everything is being forwarded.

This is a real brain teaser.

---

Agreed.  Does it work correctly if you put the base in front of the firewall?

[GBMaryland]

I would do that if I could give the basestations static IP addresses in the DMZ, but that doesn't seem to be possible.

[GBMaryland]

Is Arlo trying to use IPv6?

Those red blocks are IPv6 and malformed VLAN tags...  They always coincide with the base stations attempts to communicate.

[GBMaryland]

It appears you can't attach pictures... joy.

[StephenB]

---

@GBMaryland wrote:

It appears you can't attach pictures... joy.

---

You can (either jpg or png).

ipv6 is turned off in my router, and my base stations do connect.

[GBMaryland]

As an update:  Called Arlo support, that was worthless.  When you tell them specifically what the topology is, they seem to have issues grasping network equipment terminology, etc.

They asked for the equipment setup and then go confused when I gave it to them:

ISP: Verizon

Speed: 1Gbit

How are the base stations connected: Hardwired, 24 port switch, IoT VLAN, ports 80, 443, 123 out to internet

Firewall: Sonicwall TZ470

They seemed to really harp on the 1Gbit Verizon connection... and couldn't grasp that I actually have a 1Gbit connection to the internet.  No idea why.

Anyway, the PCAP is showing alot of dropped packets by not related to a IP address.  I find that confusing.

Arlo support is staying that the cameras are talking, but neither the web browser or app based versions are showing an video captures or allowing connections to cameras.  So that's a Red Herring....

[StephenB]

---

@GBMaryland wrote:

They seemed to really harp on the 1Gbit Verizon connection... and couldn't grasp that I actually have a 1Gbit connection to the internet.  No idea why.

---

FWIW, I also have gigabit Verizon Fios service.  You'd think support would be aware of it, as it's been out there for some years.

---

@GBMaryland wrote:

Anyway, the PCAP is showing alot of dropped packets by not related to a IP address.  I find that confusing.

---

Not sure what you mean by that. 

Are you saying that there are a lot of dropped packets to various IP addresses?  Is it possible that the SonicWall isn't fast enough to keep up with your traffic?

Or are you saying that there are broadcast packets being dropped?

Overall - is your topology Verizon ONT -> Verizon Router -> SonicWall?  If so, are you using the Verizon Router for WiFi or do you have access points behind the SonicWall? 

[GBMaryland]

Arlo continues to get even more interesting:

- Moved the cameras to the DMZ,  and only the Arlo Ultra base station connects via the internet

- The Arlo Pro base station is not properly communicating

This is VERY odd, as they both worked behind an older Sonicwall SonicOS.  The fact that the ARLO PRO is not working now, but continues to update the camera statuses, tells me there is something FUBAR with the Arlo service.

Especially given that the Ultra base station works now...

[GBMaryland]

@StephenB wrote:

---

@GBMaryland wrote:

Anyway, the PCAP is showing alot of dropped packets by not related to a IP address.  I find that confusing.

---

Not sure what you mean by that. 

Are you saying that there are a lot of dropped packets to various IP addresses?  Is it possible that the SonicWall isn't fast enough to keep up with your traffic?

Or are you saying that there are broadcast packets being dropped?

Overall - is your topology Verizon ONT -> Verizon Router -> SonicWall?  If so, are you using the Verizon Router for WiFi or do you have access points behind the SonicWall? 

---

The TZ470 is absolutely fast enough to keep up with the traffic.  That's actually why I have that sucker.

Nope, my network is:  Verizon ONT -> UDM-PRO -> Sonicwall TZ470 -> Switch fabric

My installation doesn't use any of the Verizon equipment except the ONT.

I moved the base stations to the UMD-Pro, and the ULTRA started working.  The PRO base station is still hosed, which was NOT the case with the prior Sonicwall TZ400.

[StephenB]

---

@GBMaryland wrote:

my network is:  Verizon ONT -> UDM-PRO -> Sonicwall TZ470 -> Switch fabric

I moved the base stations to the UMD-Pro, and the ULTRA started working.  The PRO base station is still hosed, which was NOT the case with the prior Sonicwall TZ400.

---

The UDM-PRO has its own network security, correct?  Has anything changed there (new config, or software update)?

You could try removing the pro base and re-adding it to the account (though it might fail, which would add to nuisance).  What status are you seeing on the old base LEDS?  Also, which base station is it?