Access 10.x.x.x subnet from 192.x.x.x
- Thread starter whobutni
- Start date
So are you saying you cannot use the camera Web UI with a Hikvision camera connected directly to your router LAN with no NVR involved?
My first post is below.
Another method to use camera Web UI:
Use a switch to connect your cameras to the same LAN that your NVR is connected to. Then add the cameras to NVR using Manual Add. Then you can use the camera Web UI without the NVR being involved. See Description section in
DahuaWiki
dahuawiki.com
Camera via LAN directly into router no issues.
However when the camera is connected to NVR, I cannot access the web GUI over wifi or even with lan to my router.
SouthernYankee
IPCT Contributor
Provide a screen shot of the full browser windo when trying to access the camera ?
Again need a diagram of your network with IP addresses ?
Again need a diagram of your network with IP addresses ?
That sounds like the NVR isn't routing traffic from the LAN through it to your camera segment.
SouthernYankee
IPCT Contributor
The nvr is NOT suppose to route traffic. That is a major security risk. You must login to the nvr to access the cameras pulled into the nvr, subnet.
alastairstevenson
Staff member
Hikvision's 'Virtual Host' and Dahua's 'e' link equivalent do route traffic between the NVR LAN interface and the PoE interface.
How else can attached cameras be accessed via the NVR web GUI?
It's a kernel facility called ip_forward that does it (not to be confused with port forwarding) in conjunction with the NAT facility of iptables.
How else can attached cameras be accessed via the NVR web GUI?
It's a kernel facility called ip_forward that does it (not to be confused with port forwarding) in conjunction with the NAT facility of iptables.
I didn't read every word in this post, so sorry if this repeats what others have said. Oh and I'm kinda late to the discussion, but maybe this info will help someone else.
Sounds you have a double-NAT issue. Basically your router isn't aware of the subnet that your NVR is hosting (10.x.x.x). The router only knows that the NVR exists, because the NVR is assigned a 192.x.x.x address from the router (and its now in the routers routing table). Since the router doesn't assign the 10.x.x.x IPs, the router doesn't know where to look to find a 10.x.x.x address. Thus why you get a timeout when browsing to a 10.x.x.x IP address. Solving double-NATs can be difficult.
Here are a few options I can think of of the top of my head:
Boy, I really rambled on. Sorry. Hopefully you can get (or already got) it working how you wanted.
Sounds you have a double-NAT issue. Basically your router isn't aware of the subnet that your NVR is hosting (10.x.x.x). The router only knows that the NVR exists, because the NVR is assigned a 192.x.x.x address from the router (and its now in the routers routing table). Since the router doesn't assign the 10.x.x.x IPs, the router doesn't know where to look to find a 10.x.x.x address. Thus why you get a timeout when browsing to a 10.x.x.x IP address. Solving double-NATs can be difficult.
Here are a few options I can think of of the top of my head:
- Add Camera's to NVR by IP, not direct connect.
- I'm not too familiar with physical NVRs (as I run BlueIris on a machine on my network), but I believe some will allow you to add cameras via an IP Address (the camera doesn't need to be physically connected to the NVR).
- If your NVR allows for that, try putting all your camera's on the 192.x.x.x network. Then add each to the NVR by the IP assigned by the router.
Note: You'd want to assign static IPs for the cameras in your router (by each cameras MAC address) so their IPs don't change when the DHCP leases expire. - This should allow you to connect directly to the cameras from your laptops browser or via the NVRs web interface.
- Run a flat network
- Basically, have everything on the 192.x.x.x network. Have both your router and NVR assign 192.x.x.x IPs (which can cause issues, see next bullet).
- But you need to be careful, as you could have an IP conflict if both your router and NVR are assigning IPs in the 192.x.x.x subnet.
- To get around this, you could configure the router to only assign IPs from 192.x.x.1-192.x.x.200. Then your NVR to only assign IPs from 192.x.x201-192.x.x.255.
Or put your NVR in a bridge-like mode (which should avoid IP conflicts all together, since the router is the only thing issuing IPs) - Note: This isn't the most secure as the cameras can still "phone home" or snoop on what else is on the network (can you tell I don't trust the camera manufactures
)
- Setup multiple VLANS in the router or firewall
- This is how I do it. I use a fanless mini PC which has 5 NICs (allowing up to 4 VLANS and 1 WAN) running pfSense.
- Create a VLAN is for the computers and one the camera's and put your NVR (in bridge mode, if possible) on the camera VLAN.
- Since the firewall knows of all the VLANs, it's able to route traffic between them.
- It also allows for network isolation, as rules can be applied to the VLANs. For example:
- My camera VLAN has no access to the WAN (internet) or the other VLANs, so the cameras can't "phone home" or snoop my network.
- I have outdoor PoE cameras, so one could in theory plug a laptop in outside and try to gain access to my network.
- The rule about not having access to other VLANs or the WAN would prevent this. As they would only see the other outdoor cameras I have (since they're on the same VLAN). Unless of course, they are REALLY motivated and can hack through my firewall.
- My computer VLAN has access to the WAN (internet) and the camera VLAN, so I can access all the cameras from any of my devices.
- My camera VLAN has no access to the WAN (internet) or the other VLANs, so the cameras can't "phone home" or snoop my network.
- Note: This is a an advanced setup, but it does allow for fine grain control over what's happening on your network.
Boy, I really rambled on. Sorry. Hopefully you can get (or already got) it working how you wanted.
alastairstevenson, what SouthernYankee says is correct, security camera's need to be secure and so NVRs are typically designed to act as a firewall between cameras and the 'public' side. They provide all the tools necessary to make use of the cameras once the cameras have been appropriately configured. This means that NVRs do not provide routing functionality between the camera LAN and the public LAN.
EXPLANATION: Routing functionality is required when you need to change one IP address to another. In order for, say, a PC connected to one LAN subnet (e.g. 198.168.1.0/24) to communicate with a device that is connected to a different LAN subnet (e.g. 10.1.1.0/24 – the camera subnet), a routing capable device must be connected between the two subnets, ie., the NVR. The NVR belongs to both subnets, its router has one IP address in the subnet associated with the public LAN port and another in the subnet that is associated with the camera LAN ports. If you have an Internet gateway router connected to the PC's subnet, then the default gateway address of the PC would be the address of the internet gateway router. In order for the PC to get through to addresses in the camera subnet, the subnet address information would need to be present in either the internet gateway router's route table or in the PC's route table. The only way it would get into that table is if it was advertised by the NVR using a protocol such as RIP or if a static route had been configured. (e.g. PC on 192.168.1.2 wants 10.1.1.1, doesn't have that subnet range in it's route table so sends it to default gateway, 192.168.1.1 which is the internet router. Internet router sees it has a route table entry that directs it to send all 10.1.1.0/24 addresses to 192.168.1.3, the address of the NVR. NVR receives packet for 10.0.0.1 and checks its route table, finds a match to the camera subnet then sends the packet to the appropriate camera (or broadcasts it to all cameras if it doesn't already have an IP address to MAC address mapping.
POSSIBLE WORKAROUND: Connect the cameras to an IP switch, the public LAN that fed the NVR to the switch, the public LAN port of the NVR to the switch and one of the camera LAN ports to the switch. Configure the network adapter of the PC to have two IP addresses, one on each subnet. The camera subnet config should not be assigned a default gateway address. Note that static IP addressing will need to be configured for devices in both networks in place of DHCP. It would be possible to leave DHCP enabled in the Internet gateway router for convenience but it should be disabled in the NVR. The cameras would need to be configured with static addresses belonging to the camera subnet of the NVR before they are connected to combined LAN.
Of course, getting PoE to the cameras then presents a different issue, but there is nothing stopping you from connecting cameras to the remaining NVR ports as the IP addressing workaround should permit communication with all cameras.
EXPLANATION: Routing functionality is required when you need to change one IP address to another. In order for, say, a PC connected to one LAN subnet (e.g. 198.168.1.0/24) to communicate with a device that is connected to a different LAN subnet (e.g. 10.1.1.0/24 – the camera subnet), a routing capable device must be connected between the two subnets, ie., the NVR. The NVR belongs to both subnets, its router has one IP address in the subnet associated with the public LAN port and another in the subnet that is associated with the camera LAN ports. If you have an Internet gateway router connected to the PC's subnet, then the default gateway address of the PC would be the address of the internet gateway router. In order for the PC to get through to addresses in the camera subnet, the subnet address information would need to be present in either the internet gateway router's route table or in the PC's route table. The only way it would get into that table is if it was advertised by the NVR using a protocol such as RIP or if a static route had been configured. (e.g. PC on 192.168.1.2 wants 10.1.1.1, doesn't have that subnet range in it's route table so sends it to default gateway, 192.168.1.1 which is the internet router. Internet router sees it has a route table entry that directs it to send all 10.1.1.0/24 addresses to 192.168.1.3, the address of the NVR. NVR receives packet for 10.0.0.1 and checks its route table, finds a match to the camera subnet then sends the packet to the appropriate camera (or broadcasts it to all cameras if it doesn't already have an IP address to MAC address mapping.
POSSIBLE WORKAROUND: Connect the cameras to an IP switch, the public LAN that fed the NVR to the switch, the public LAN port of the NVR to the switch and one of the camera LAN ports to the switch. Configure the network adapter of the PC to have two IP addresses, one on each subnet. The camera subnet config should not be assigned a default gateway address. Note that static IP addressing will need to be configured for devices in both networks in place of DHCP. It would be possible to leave DHCP enabled in the Internet gateway router for convenience but it should be disabled in the NVR. The cameras would need to be configured with static addresses belonging to the camera subnet of the NVR before they are connected to combined LAN.
Of course, getting PoE to the cameras then presents a different issue, but there is nothing stopping you from connecting cameras to the remaining NVR ports as the IP addressing workaround should permit communication with all cameras.
Last edited:
alastairstevenson
Staff member
To be brutally honest - security has not been a strong point in the design of most NVR or camera firmware.
Check out the many vulnerabilities that have been discovered and continue to be exploited across many brands and models.
Actually they do. Which you confirm below :
When you say 'Public LAN' I presume you mean the LAN that the NVR LAN interface is connected to.
That's the Private LAN.
The Public LAN is the internet.
How do you think Hikvision's 'Virtual Host', or Dahua's equivalent work?
How is the camera web GUI reached via the NVR LAN interface?
The Linux kernel provides a routing capability between the camera and NVR interfaces.
Yes, that's mostly all correct.
All you need to do to access cameras on an NVR PoE interface network is to tell the LAN default gateway how to route the traffic.
And have ip_forward enabled (ie Virtual Host or equivalent) on the NVR.
And as this can be done on any device on the LAN, not just on the LAN gateway, there is no security, certainly no 'firewall' in the NVR.
Here is a Hikvsion NVR with Virtual Host enabled :
Code:
alastair@PC-I5 ~ $ ssh root@192.168.1.213
root@192.168.1.213's password:
[root@dvrdvs /root] # cat /proc/sys/net/ipv4/ip_forward
1
[root@dvrdvs /root]
# exit
Connection to 192.168.1.213 closed.
alastair@PC-I5 ~ $
Dahua NVR's indeed used to support the /proc/sys/net/ipv4/ip_forward method the problem is you cannot set it as you've got no telnet or SSH access any more.
When we did have it, I used it a fair bit - as you could also set it via serial at the time too.
If you can find a way to inject it into a startup script then it could work again.
The IE port method is controlled by the Challenge app so not directly exposed. but it seems odd not to work with Hik cams, it works fine with ONIVF ones ?!
Its' just mapping port 80 from the cam to a random higher port.
If you are missing the IE button, the RPC call is:
{"method":"VirtualHostProxy.getHttpProxyPort","params":{"Channel":0,"IPAddress":"NVR IP"},"id":NUM,"session":"SESSION ID"}:
Channel mapping starts from 0 for cam 1, NVR IP, NUM and SESSION ID need inputting correctly. Will return:
{"result":true,"params":{"ProxyPort":TCP,"ProxyHttps":false},"session":"SESSION ID","id":NUM}
then you go: http://NVR IP:TCP
When we did have it, I used it a fair bit - as you could also set it via serial at the time too.
If you can find a way to inject it into a startup script then it could work again.
The IE port method is controlled by the Challenge app so not directly exposed. but it seems odd not to work with Hik cams, it works fine with ONIVF ones ?!
Its' just mapping port 80 from the cam to a random higher port.
If you are missing the IE button, the RPC call is:
{"method":"VirtualHostProxy.getHttpProxyPort","params":{"Channel":0,"IPAddress":"NVR IP"},"id":NUM,"session":"SESSION ID"}:
Channel mapping starts from 0 for cam 1, NVR IP, NUM and SESSION ID need inputting correctly. Will return:
{"result":true,"params":{"ProxyPort":TCP,"ProxyHttps":false},"session":"SESSION ID","id":NUM}
then you go: http://NVR IP:TCP
Last edited: