NVR with cameras on two subnets

Chris

I'm trying to set up a slightly advanced networking configuration for my Reolink cameras and NVR. I have a decent amount of experience with networking and router configuration, and I want to disable UID on the cameras for security purposes.

I have three RLC-410s and one R8 NVR. My site has two buildings that each have their own subnets. The NVR and two of the cameras are on subnet 192.168.1.0/24, and they are playing nicely together.

The third camera is in another building with a different subnet for security purposes. That subnet is 192.168.2.0/24. The camera's IP is 192.168.2.200.

I have configured the routers to allow traffic from the first subnet to the camera, and this appears to be working fine. Using a phone that is on the 192.168.1.0/24 subnet I am able to connect to the 192.168.2.200 camera via both browser and the ReoLink android app. Using a laptop that is on the 192.168.1.0/24 subnet I am able to connect to the 192.168.2.200 camera via both browser and the ReoLink Windows client app.

However, when I try to add this camera through the NVR console (by IP address, exactly how I added the other two cameras) it just shows up as OFFLINE.

Because I am able to access the camera from a laptop on the same subnet as the NVR without any issues, my guess is that there is some difference between how the Windows client software communicates with the camera vs how the NVR and camera communicate. For example, perhaps the camera needs to establish an outbound connection to the NVR? If so, then that would explain my issue because there may be some firewall rule in my router that is blocking this. If I know what ports it needs I can fix the router settings... but I haven't been able to find any information that indicates whether this type of outbound connection from the camera to the NVR is necessary. Clearly it is not necessary for the Windows client software to communicate with the camera.

Any help would be greatly appreciated!

Carl

Hi Chris, sorry for that the NVR could only add the camera which was on the same LAN with the NVR or connected directly to the NVR's PoE ports. So in your case, the NVR cannot add the camera.

Chris

Do you know the technical details as to why the NVR can't add it? If I configure the NVR to have a static IP address and I set the subnet mask to 255.255.0.0, then as far as it knows, it *is* on the same LAN. And the windows client software works just fine.

Is the NVR doing some kind of broadcast packet that doesn't go outside of its LAN? Or does the camera have to be able to resolve the NVR's address and make a connection back to the NVR for some reason? Otherwise I don't understand why it won't work, because I know the IP address of the camera, I know that it is accessible from the LAN, and I know that the windows client software can interact properly with the camera from the LAN.

Thanks!

Crimp On

Could you be more specific about how you "configured the routers" to allow traffic from one sub-net to the other?
(I enjoy the minutia of networking, but have not reached any significant degree of expertise.)

My naive understanding is that when a device wants to send packets to an IP address that is on the same sub-net, it does an ARP request to get the MAC address of the device. Then, it sends packets directly to that MAC address. When the IP is not on the same sub-net, it sends those packets to the MAC address of the gateway device, which then knows which router port knows where to find that IP. So, your Windows machine says, "I want 192.168.2.x, and sends that packet to 192.168.1.1, which knows where to find 192.168.2.x" If your Windows machine had a sub-net mask of 255.255.0.0, it would say, "192.168.2.x is on my sub-net, so I'll do an ARP request to find its MAC address. Once I get the MAC address, I'll address my packets to it." But, nobody answers the ARP request, because ARP requests don't go across routers.

Have you tried setting your Windows machine mask to 255.255.0.0, and you can still communicate with the camera on the other sub-net?

Or, have I just displayed horrible ignorance?

p.s. I agree that it seems reasonable that people might want to connect their NVR to cameras on a different LAN.

Chris

Crimp On,

Thanks a bunch for your reply, that's very helpful. I know just enough networking to be dangerous But I've been thinking about this problem solely from the Layer3 level. After your post, I read up on ARP and refreshed my memory on some Layer2 basics, and you're absolutely right. If I change the subnet mask on the Windows machine to 255.255.0.0 then I can no longer connect to the camera on 192.168.2.x.

So I'll change the NVR back to DHCP and that will set its subnet back to 255.255.255.0. Still need to figure out why it can't communicate with the camera. At present my only ideas are:

* Perhaps when the NVR first establishes the connection to the camera, it instructs it to make a new connection back to the NVR and they resume their communication over that socket. In that case my routing tables currently do not allow a connection to be established in this direction. Hoping to explore this by doing some wireshark with the cameras that are on the 192.168.1.x and seeing if I can determine how they interact with the NVR.
* I did some wireshark around the NVR already and I can see that it is sending out some broadcast/multicast packets. If that is an integral requirement for how the NVR and cameras communicate then it seems like I will have to make some major changes to my network topology, e.g. set up a VLAN for the NVR and cameras to share so that they can see eachother via broadcast.

Hopefully one of those two options will work; will update this post with any additional findings.

Thanks again for the pointers about ARP, Crimp On!

Carl

Hi Chris, yes, before adding the devices to the NVR, the NVR will detect the cameras on the LAN via a LAN broadcast packet. So if the camera is not on the same LAN, it cannot be detected by the NVR. Thanks in advance for your patience and understanding.

Crimp On

This is a significant difference between the Reolink NVR and Reolink client software for Windows (Mac, too?) The heart of NVR is the PoE connected cameras. The NVR "sees them" because they are directly connected. (Like the NVR's that connected cameras over coax cables) Because people have WiFi and cameras that are not PoE, the NVR broadcasts to find them.

The client software allows cameras to be added by IP address. Sort of wish that option had been programmed into the NVR. My guess it's not coming any time soon, or at all.

Putting the NVR and cameras in a VLAN is an excellent solution. I just did a quick Google search and was surprised to find how many inexpensive switches support VLAN's. That would have the benefit of isolating the NVR/camera network from the rest of the network, with only the devices you allow through having access. You never mentioned how your two building networks are connected or what kind of switches are deployed.

Chris

Carl, thanks for confirming the use of broadcast packets.

Crimp On, you are one step ahead of me again

I was able to monitor some network traffic with Wireshark and came to the same conclusions from the above posts:

* When using the windows client software, it seems that the Flash player connects to the cameras on port 9000 and gets video from that connection.
* When the NVR is successfully communicating with a camera, it appears that the camera is the "client" and the NVR is the "server". The NVR sends out some broadcast packets, and then the camera connects from its port 9000 to a random port on the NVR (which seems really weird).

The thing that was the most confusing to me about all of this is that when you are in the NVR's UI on the screen that lists out the cameras, you can click around in there and "add" a new camera, including specifying the IP address and port. However, as far as I can tell, the NVR utterly ignores this. I never witnessed the NVR even attempting to send a packet to the camera that I tried to add using that IP field. It definitely appeared that the only way to get a new camera added was to get it on the same LAN so that it would respond to broadcast packets.

Once I convinced myself that the NVR was relying on broadcast, I set out on the adventure of configuring VLANs. (I have some Ubiquiti EdgeRouter X's that are capable of handling all of the necessary VLAN config.) Once I got all three cameras and the NVR on the same VLAN, I was able to add the third camera to the NVR with no problems. So, everything is working now; hooray!

In case some future reader is battling with this, the two key discoveries that were not obvious to me were:
* The Windows Reolink client establishes an outbound connection to the cameras, but the NVR is very different, and relies on broadcasting to the LAN to tell the cameras to establish inbound connections back to it; so your network topology and firewall rules need to allow for this.
* Even though the NVR has a place in the UI where it will let you type in the IP of a new camera, it does not appear to ever attempt a direct connection to that IP; it seems like it is impossible to successfully add a camera unless the camera can see and react to the broadcast packets from the NVR.