-
RLN8-410 is on office network, using 10.1.1.100 netmask 255.255.255.0. Only hosts on that subnet can connect (app/browser) to the NVR IP, as expected. Second office subnet 10.2.2.0/24 hosts can't connect, as expected. But I should be able to change NVR netmask to 255.0.0.0 to allow the second subnet to connect. This would allow office users without opening up the system to whole-internet UID access.
Why doesn't netmask 255.0.0.0 behave as it should, and allow all local LAN 10.x.x.x clients to connect to the NVR?Reply QuoteShare0- Share this Post
-
copy the link
Copied!
-
@guero-jose_338291415367917
Because changing the devices subnet does not change the routing table to the different network. That routing table is either made manually or when a device gets the information from DHCP. -
@ks But to clarify: Both office subnets are on a single VLAN, with network connectivity to each other. Other 10.2.2.0 systems can reach 10.1.1.0 systems, and vice versa. It's actually the NVR's routing table that seems to be the problem, but we aren't given the ability to examine that, ping from a CLI, etc.
Again, if the NVR is obeying the netmask that I'm defining (and the static IP address - DHCP does not enter into this), it should consider all 10.0.0.0 systems as local to its own LAN, and not be preventing connections.
P.S. Adding specific host IPs to the whitelist (not actually properly defined anywhere in the documentation) also has no effect. -
@guero-jose_338291415367917
I'll have to play with my NVR and see if I can replicate it. Shouldnt matter if it's a vlan or not, something has to update the routing table to point to the correct network.
For example:
Network A uses 10.1.1.1 /24 which has a IP range of 10.1.1.1 - 10.1.1.254
Network B uses 10.2.2.1 /24 which has a IP range of 10.2.2.1 - 10.2.2.254- Those are separate networks, they need a routing table to point to the correct location.
Now you changed Network B to 10.2.2.1 /8 which has a IP range of 10.0.0.1 - 10.255.255.254- Network A still doesn't know network B exists and it can't connect to 10.2.2.x range without routing info.
On windows you can run the CMD ( route print ) to see your current info. -
@ks @ks Yeah, I think you're getting confused with what I'm seeing. To simplify: The NVR has been given a static address and an 8-bit netmask. The only routing table that matters here is the one on the NVR: "Who's my gateway for sending packets responding to 10.2.2.200? Oh, ok, here you go.". It is the job of the other client systems to reach their own gateway vie their routing tables, which they do. It is the job of the nearest router/switch to deliver packets to the NVR, which it does. Again, other clients on both subnets can talk to each other just fine over the same network equipment, because they have a common vlan. Networks and routes on the client systems (whether Windows or Linux) are not being changed, and I can verify with Wireshark everywhere (except the NVR) that packets are routed correctly. It's the NVR that sees packets arrive from 10.2.2.200 and decides not to allow/respond, and we're not allowed to examine why not. But thanks anyway.
-
@guero-jose_338291415367917
Brother I wish you luck. If your networks are not L2 adjacent, they need a gateway and routing table. You can literally have two computers directly connected to each other via ethernet on different subnet networks and they will not communicate to each other without a L3 switch or router correctly configured.
I don't know how else to explain it. -
@ks Son, I administer networks and systems for a living. If my explanations thus far don't give you a clear picture, I don't know what else to say. But thanks again for trying. Perhaps someone knowledgeable at Reolink will offer something, or better still give the customer actual access to the device that they purchased.
-
@guero-jose_338291415367917
son, haha
Can I be frank? you are subnetting different networks within the same vlans. That kind of already says everything I need to know. 2nd, your a network admin for an office using reolink cameras... again everything I need to know.
It's extremely hard to follow when you say things like in your first post. " I changed the NVR netmask to 255.0.0.0 to allow the second subnet to connect" think about that a min. You changed it on the device you want "other" devices to connect to. That's not how routing works... you keep saying vlan; a vlan is no different than a physical connection. In reality a physical connect is vlan1 by default. I'm glad other hosts can connect to other hosts on different subnets, did you check ARP cache? what router? L3 switch? gateways? so much info is missing it's crazy.
My shit works, sorry yours doesn't. I'm done, I'm out. enjoy your life.
NVR doesn't obey subnet mask
-
RLN8-410 is on office network, using 10.1.1.100 netmask 255.255.255.0. Only hosts on that subnet can connect (app/browser) to the NVR IP, as expected. Second office subnet 10.2.2.0/24 hosts can't connect, as expected. But I should be able to change NVR netmask to 255.0.0.0 to allow the second subnet to connect. This would allow office users without opening up the system to whole-internet UID access.
Why doesn't netmask 255.0.0.0 behave as it should, and allow all local LAN 10.x.x.x clients to connect to the NVR?
All Categories