Just got doorbell camera, weird behavior across subnets, what is the actual rule?

[user_746479291687074_746479291687074]

Just got a doorbell/wifi camera. At present it is my only reolink (having sold the house which had others). I am aware of this discussion:

https://community.reolink.com/topic/6726/unable-to-access-reolink-ip-cams-from-different-vlan

Here's the thing -- some IP goes through to another subnet, I can ping it just fine, and Home Assistant (and whatever protocols it uses) seems OK accessing it. The web gui is flakey, it will paint a login screen but not log in.

This does not SEEM to be a security feature preventing access from other subnets (if so ping would not work, for example). This just seems broken.

Is there a clear statement on what does, and does not work across subnets? On another forum it was said that broadcast traffic must flow and arrive with the same subnet, which makes no sense for a gui (and also might imply nat would not be a solution, as has been suggested).

I just got this -- I can put it back in the box and return it, and plan to if I can't get a clear understanding of this. I don't need the web gui to work across subnets, but I do need whatever integration protocols home assistant uses to work -- and continue to work. At present with this half-working-half-broken approach, it seems likely to expect some firmware update to break it entirely.

I've seen products with subnet isolation as a (bogus) security feature, but all of them (a) actually block all traffic, as any security related approach would, and (b) let the user turn it off if needed. So... what's really up with this?

Linwood

[joseph_1979]

@user_746479291687074_746479291687074 The Client broadcasts a packet with payload aaaa0000 using destination addresses 255.255.255.255.255 and 192.168.1.255 (or your configured IP subnet).

Now 255.255. 255.255 is the limited broadcast address which is only propagated within the single subnet of the interface that sent it. It is never routed to other subnets unlike the subnet directed broadcast address 192.168. 1.255 which may be routed from elsewhere, depending on router configuration. Most ISP routers won't allow this. Check yours.

[Chopstix_887064913674433]

Sounds like you are not using a Reolink Home Hub Pro. This issue goes away with the HHP as the HHP's WiFi is a private network and the HHP does it's own NAT for access to it. The HHP also has dual Ethernet ports... a LAN port which is on the same private network as the WiFi and a WAN port for connectivity to YOUR network. With this, the LAN port can be connected to it's own switch or to a Layer-2 switch with defined VLANS. With this setup, no additional routing is necessary and you can block access to the Internet to require a VPN connection to your network for remote access.

When not using a HHP, camera isolation does work as I have sandboxed it for client's evaluation (this is actually how I found out about Reolink). I used their Layer-3 switch to handle the VLAN routing, not their firewall. The two test cameras which are wired in on their own VLAN can be access from the mobile client either via their company WiFi or remotely.

So this brings up something I have not tested... turning of UID to prevent remote access without having to VPN in. Because the cameras are on on a different subnet than the mobile client, I do not know if turning off UID will prevent the client from finding the cameras. I don't believe it should as the client should have the IP addresses of the cameras. If it does not, I would think the enabling broadcast forwarding to the subnet would fix that.

Anyhow, FWIW, camera isolation does work and there are a couple different approaches.

[joseph_1979]

@chopstix_887064913674433 The client doesn't store the IPs of the cameras. It just broadcasts a packet with payload aaaa0000 on port 2000 and any Reolink device listening will respond with payload aaaa0000, IP of cam and port 9000 (if not changed by user) plus mac address, UID and camera name.

But it stores the UIDs which it forwards to the P2P relay servers for remote login.

[Chopstix_887064913674433]

@joseph_1979 that would explain then (from previous conversation) that the client and cameras need to to be on the same subnet if UID is turned off or if there is no Internet access. It also explains why in my sandbox, the cameras are accessible from different VLANs when UID is turned on. With that, I should be able to conclude that turning UID off will necessitate enabling VLAN broadcast traffic. I'll test it to confirm, but I believe based on your information, that will be the case. Thanks!