Will the base adjust if I change subnet of wired network

[akno]

I'm changing the subnet of the wired network. Is the base station intelligent enough to pull a new DHCP configuration and reconnect? Or do I have to go through a re-initialization of the base station? It's a PITA that the base station can only be set up by a browser (app) on the same subnet. For security reasons, I don't want the base station separated from my home network by a firewall. I don't trust Arlo's IOT security and want to put the base station in an isolated network.

[akno]

What additional services beyond http (yuck) and https are required through the firewall in order to initialize the base station. DHCP, DNS and NTP are provided in the local networks? This is what I am seeing on the firewall:

192.168.35.226 -> dns.google ICMP Echo request (ID: 28162 Sequence number: 512)
192.168.35.226 -> dns.google ICMP Echo request (ID: 28162 Sequence number: 768)
192.168.35.226 -> dns.google ICMP Echo request (ID: 28162 Sequence number: 1024)
192.168.35.226 -> dns.google ICMP Echo request (ID: 28162 Sequence number: 1280)
192.168.35.226 -> dns.google ICMP Echo request (ID: 28162 Sequence number: 1536)
192.168.35.226 -> dns.google ICMP Echo request (ID: 28162 Sequence number: 1792)
192.168.35.226 -> dns.google ICMP Echo request (ID: 28162 Sequence number: 2048)
192.168.35.226 -> dns.google ICMP Echo request (ID: 28162 Sequence number: 2304)
192.168.35.226 -> dns.google ICMP Echo request (ID: 28162 Sequence number: 2560)
192.168.35.226 -> dns.google ICMP Echo request (ID: 28162 Sequence number: 2816)

ICMP Echo (Ping) should not be a requirement for this device to function.

[StephenB]

---

@akno wrote:

ICMP Echo (Ping) should not be a requirement for this device to function.

---

Actually it's not a bad way for the base system to confirm internet connectivity, and it could also be useful in determining the path MTU.  Though the use should be documented somewhere (and as far as I know it isn't).

As far as the rest goes, ports 80, 443, and 123 need to be open, but I think you already know that.  You can't configure the NTP server, so you have no ability to shift it to the local network.  DNS is of course picked up through DHCP.

I don't know of any others - if you do see uncover them in your firewall logs it'd be useful if you post them on this thread.

[akno]

From a security perspective allowing ping is a liability. Viruses and malware have been programmed to place C&C in ICMP payloads, knowing that ICMP is likely to be given a pass at the firewall. Any non-standard MTU should be addressed through DHCP option 26. And DHCP option 42 should be used for NTP settings, with fallback to the firmware-defined settings. IOT devices need to start following the standards and making use of local resources, when available. It rubs me the wrong way that the Arlo base station requires its own Wifi. It should be able to use an existing Wifi on the same bridged network. Every vendor wants to have their own AP. In some instances, there isn't enough bandwidth.

You are right that HTTP (80/tcp) and HTTPS (443/tcp) are needed. But, I am finding that NTP (123/udp) is wanted, but not required. And ICMP echo to 8.8.8.8 is also wanted, but not required. I still want to get a list of CIDR blocks that will be used by the Arlo base station. It's professional in today's internet to have that information published. Claiming that this information shouldn't be published because it is proprietary and can change is hogwash. The first excuse is a smoke screen. And the second excuse is addressed through updates to documentation. Yes, documentation is part of the product release cycle.

[StephenB]

---

@akno wrote:

You are right that HTTP (80/tcp) and HTTPS (443/tcp) are needed. But, I am finding that NTP (123/udp) is wanted, but not required. And ICMP echo to 8.8.8.8 is also wanted, but not required. I still want to get a list of CIDR blocks that will be used by the Arlo base station. It's professional in today's internet to have that information published. Claiming that this information shouldn't be published because it is proprietary and can change is hogwash. The first excuse is a smoke screen. And the second excuse is addressed through updates to documentation. Yes, documentation is part of the product release cycle.

---

I fully agree that such information should be published.  Though they are using the Amazon cloud, so providing specific IP addresses might not be the best approach (as they will change, and might well depend on geography).

While there are attacks that use ICMP,  there of course are benefits in using it also.  DHCP options aren't necessarily deployed on all networks,  so depending on them might not be a good strategy for Arlo.  We can just agree to disagree on that.  In any event, it appears to work without ICMP, so you can of course just continue to block it.

On NTP, there could be some side effects to not using it.  One obvious one is that epoch time is used as the file name, and that time won't be correct if NTP isn't used to keep the base station synced with true time.  There could be other more substantial issues that turn up as the local clock drifts.   Personally I'd allow it (not wanting to risk a lost recording or notification later on).  Up to you of course.

Overall, I think there is a much bigger attack surface in the Arlo Cloud than there is in the base station, and a compromised cloud could access my cameras even if the base station is isolated.  Since I have to depend on Arlo to keep the cloud secure, I don't see much point in spending a lot of effort isolating the bases on my home network.  If I wasn't willing to trust their security I'd use a different kind of system that didn't require a cloud service.  Again, just my view, and you obviously disagree.

[akno]

File name? Is there some way to see the file name for each of the captures? Do you have some intimate knowledge of an access that allows me to see what is stored on the local device? Share that with us all!

I did figure out how to redirect the NTP client to my NTP server. I also noticed that the NTP server is contacted only once during boot. I'm sure that the internal clock on this cheap device is accurate over long periods so the continual time synchronization that is built into NTP (which you don't use) would be superfluous. This is yet another example of incomplete (flawed) software from Arlo/Netgear.

I agree with you that it would be nice if Arlo published how their devices use the internet so that when the devices get compromised (not if) their usage signature will change and the device can be removed from the network. But "woulda," "coulda," and "shoulda" don't get the job done. The plebes down here in consumerland are waiting for the next update from the ivory tower. @StephenB, are you in the ivory tower?

[StephenB]

---

@akno wrote:

The plebes down here in consumerland are waiting for the next update from the ivory tower. @StephenB, are you in the ivory tower?

---

No, I'm just one of those plebes in consumerland. FWIW I don't work for Arlo.

---

@akno wrote:

File name? Is there some way to see the file name for each of the captures? Do you have some intimate knowledge of an access that allows me to see what is stored on the local device?

Why so snarky?

Local Files can be accessed if you connect USB storage (or microSD in the case of the VMB5000).

Files downloaded from the cloud are named with epoch time.  Though I have no secret knowledge of the internals, I believe that time is derived in the base when the capture was made..  For instance, a recent download from my Ultra is 1579218441576.mp4.  That is 17 January 2020, 12:43:19 AM GMT