Correct sequence to enable bridge mode on Dahue NVR to enable use with Unifi Protect?

B

blue22

n3wb
Sep 29, 2019
4
3
California
Current setup is with bridge mode disabled with Dahue NVR5216-16P-4KS2E and 10 Dahue cameras (ie I used the NVR camera auto-configure for the initial setup long ago.). Looking to switch the setup to bridge mode to allow Unifi Protect to see all of the camera’s over ONVIF. I’m thinking the correct sequence would be to first manually configure each camera to the new IP address, gateway and netmask and then configure NVR to bridge mode. (For example, cameras are currently autoconfigured by NVR to be 10.1.1.65 to 10.1.1.74 and I would change them to 192.168.0.65 to 192.168.0.74. (With matching fixed entries in the Unifi DHCP server.) and update the netmask and gateway. The cameras are physically difficult to get to, so really want to avoid needing to reset the cameras because of doing this in the wrong sequence.

Alternatively, if anyone has figured out how to select specific ONVIF feeds through the NVR when using Unifi Protect, then I could avoid doing all of this. Currently Unifi Protect shows camera #1 on the live feed and records only camera #10.
 
  • Like
Reactions: bigredfish
The method you have suggested is exactly how you need to do it.
Change the IP addresses on all of the cameras and then set the nvr switch to bridge mode.
I don't have unifi protect but I have the exact same dahua nvr as you and I have it set in bridge mode just like you are wanting to do and my second NVR can access the cameras as well.

Edit: you will of course also need to re-add the cameras to dahua the nvr once they have the new IP addresses. But that's just a simple edit update the IP address.
 
  • Like
Reactions: bigredfish
Just be aware that adding your cameras via bridge mode will expose them to the internet unless you have got them blocked by other means.
 
looktall said:
Just be aware that adding your cameras via bridge mode will expose them to the internet unless you have got them blocked by other means.
Click to expand...

this is very incorrect...
in normal mode, NVR with POE works as NAT based router/firewall.
On ONE IP address from Your local network, NVR is giving cameras FULL access to internet and your LOCAL network.
The same as any NAT router/firewall is giving all devices on local network access to internet..

the only limitation is that, You can't connect from your local network (or internet) to any camera by IP address - because they are behind NAT based router/firewall.
The same as no one from Internet can't connect to anything in Your network..
with exceptions of open ports, VPNs and some P2P techniques.

So there is no difference - both in normal and bridged mode all connected cams have FULL access to both Your local network and full internet.
In both cases the are NOT directly accessible from Internet (because of Your main NAT based router/firewall)..

The only difference are from which IP pool cameras will get addresses (NVR private IP addresses vs Your local network ones) and that in bridge mode You CAN connect to cameras directly by camera IP address from your local network.
 
steve1225 said:
this is very incorrect...
Click to expand...
On my uniarch NVR the cameras plugged into the Poe ports could not reach the internet.
I'm certain of it but I no longer use the Poe ports on that NVR at all so I can't confirm it.

On my dahua nvr I have only ever used the Poe ports in bridge mode so I couldn't say how they function.
 
steve1225 said:
if this is true, then P2P woudn't work directly on cameras... or time synchronization with NTP server.. on any notification from cameras..
Probably You had something wrong configured...
Click to expand...
I've never used p2p on a camera. Only via the NVR.
The cameras can get their time sync from the NVR.
And yes. Email notifications direct from the camera wouldn't work.
 
  • Like
Reactions: bigredfish
^^^^^
This is my experience also
I only use P2P on the NVR not on cameras .
 
bigredfish said:
^^^^^
This is my experience also
I only use P2P on the NVR not on cameras .
Click to expand...

I didn't wrote that You need P2P on cameras connected to NVR..
In 99% cases You don't need (except intercoms, where You have calling notifications over P2P)..

I denied the statement: that cameras connected to POE ports in modern NVR don't have internet access..
this is false.. they have full access to both local network and internet, because NVR works as NAT router.

NVR with internal POE switch don't blocks connected devices (cameras) in any way..
And do not protect against holes or backdoors that may be in these cameras.

The only thing they do is that they hide camera IP addresses from local network.
And block ability to directly connect with cameras using those IP addresses because of how NAT works.

This is the case in all modern NVRs from Dahua and HIK.
There can be some very old NVRs from exoteric brands, which can works in different way.
 
  • Like
Reactions: bigredfish
Thanks everyone for the suggestions/recommendations. The conversion to bridge mode went smoothly. A few minor items of note:
1) When I updated the ip config of the camera, the NVR picked this up and reported a new camera was available at the new IP address immediately. I had assumed that the NVR would not see the cameras on the new IP address because they were moved off of the 10.x subnet.
2) Access to the NVR over the web (I was doing this using NVR web interface, not console), sort of locked up after I updated the IP of each camera. Just needed to close the window and relogin and I was able to keep going.
3) As Looktail mentioned, I needed to re-add the cameras after the updated and switching to bridge mode. I re-added them in the order that I wanted the camera numbers to be assigned so that the change was "invisible".
4) I need to do some more testing, but the "initial" live view of the cameras on DMSS seems to start up much more quickly in bridge mode. (This is with the HD/4k feeds, typically with either 800kB/s or 400kB/s CBR.)
5) I added 6 cameras (in addition to the existing UniFi doorbell) on the UDM pro, so far it seems to be handle the load okay. The UDM is reporting that it's recording 2k feeds, which is odd, since the camera doesn't have any 2k feeds, but everything else seems good. Would be great if UDM could receive the IVS alerts so I could retire the Dahue NVR...

TODO: figure out what I want to do for additional security. Seems like recommendation is to isolate all IoT devices so they can't initiate connections to any other device on internal network and block the cameras from directly accessing the internet.
 
  • Like
Reactions: looktall
blue22 said:
Thanks everyone for the suggestions/recommendations. The conversion to bridge mode went smoothly. A few minor items of note:
1) When I updated the ip config of the camera, the NVR picked this up and reported a new camera was available at the new IP address immediately. I had assumed that the NVR would not see the cameras on the new IP address because they were moved off of the 10.x subnet.
2) Access to the NVR over the web (I was doing this using NVR web interface, not console), sort of locked up after I updated the IP of each camera. Just needed to close the window and relogin and I was able to keep going.
3) As Looktail mentioned, I needed to re-add the cameras after the updated and switching to bridge mode. I re-added them in the order that I wanted the camera numbers to be assigned so that the change was "invisible".
4) I need to do some more testing, but the "initial" live view of the cameras on DMSS seems to start up much more quickly in bridge mode. (This is with the HD/4k feeds, typically with either 800kB/s or 400kB/s CBR.)
5) I added 6 cameras (in addition to the existing UniFi doorbell) on the UDM pro, so far it seems to be handle the load okay. The UDM is reporting that it's recording 2k feeds, which is odd, since the camera doesn't have any 2k feeds, but everything else seems good. Would be great if UDM could receive the IVS alerts so I could retire the Dahue NVR...

TODO: figure out what I want to do for additional security. Seems like recommendation is to isolate all IoT devices so they can't initiate connections to any other device on internal network and block the cameras from directly accessing the internet.
Click to expand...

#1-3 exactly as it is supposed to work.
4- ? maybe because they are feeding from your LAN vs going through the NVR switch
 
steve1225 said:
I didn't wrote that You need P2P on cameras connected to NVR..
In 99% cases You don't need (except intercoms, where You have calling notifications over P2P)..

I denied the statement: that cameras connected to POE ports in modern NVR don't have internet access..
this is false.. they have full access to both local network and internet, because NVR works as NAT router.

NVR with internal POE switch don't blocks connected devices (cameras) in any way..
And do not protect against holes or backdoors that may be in these cameras.

The only thing they do is that they hide camera IP addresses from local network.
And block ability to directly connect with cameras using those IP addresses because of how NAT works.

This is the case in all modern NVRs from Dahua and HIK.
There can be some very old NVRs from exoteric brands, which can works in different way.
Click to expand...

If the cameras connected to the NVR do have access to the internet, why can we not access them when using SmartPSS and P2P and accessing the NVR. I can get the camera page with the Explorer e logo but then it refuses to connect?
 
Correct/.
I can open ports on the router, you can hit the NVR, but you still cant get to the cameras attached to the PoE ports on 10.1.1.x
It will only allow access from a "local" IP
 
bigredfish said:
Correct/.
I can open ports on the router, you can hit the NVR, but you still cant get to the cameras attached to the PoE ports on 10.1.1.x
It will only allow access from a "local" IP
Click to expand...

Maybe he has a trick setting within the NVR to allow it lol. Would make troubleshooting my neighbors system easier lol.
 
  • Like
Reactions: bigredfish
You must log in or register to reply here.
Top Bottom