Dahua DMSS App.

[psycik]

Yeah I was posting it in here: DMSS and DMSSHD on Ipad on iphone notifications

Mine just stopped, I hadn't played with the firewall. But I played today and made a change to allow for 2195, 443 and I finally started seeing some dropped ports to 8888 (dest ip of 18.184.87.16) which I've just allowed, an dlow and behold I've started getting alerts again....that looks like an aws ip address. (can follow up other thread rather than middy this one)

 

[Tomycrosound]

Greeting!
I have a Dahua VTO2211G-WP intercom.
On android I added locally (I think) and the notification works!
On iOS, iphone 12, main account, notifications do not work. The port is open. I have access to the camera when I'm not on the local network. There is no notification even when I am at the local and when I am not.
Tool manager in dmss application gives error 21. Some of the attached images.
Please help, how to enable notifications on iPhone?

 

[catcamstar]

Greeting!
I have a Dahua VTO2211G-WP intercom.
On android I added locally (I think) and the notification works!
On iOS, iphone 12, main account, notifications do not work. The port is open. I have access to the camera when I'm not on the local network. There is no notification even when I am at the local and when I am not.
Tool manager in dmss application gives error 21. Some of the attached images.
Please help, how to enable notifications on iPhone?

In your main screen, press "door" at the top, press the top right screw (settings) icon, pick second menu (Activate notifications) and make sure that twitch is active.

Good luck!
CC

 

[Tomycrosound]

Suddenly it worked. I opened another different port, maybe because ... It works on the local iPhone, it definitely works on my account, and it doesn't work on the iPad I shared it on.
I have another problem, there is no voltage on the lock, and while I was testing the device it was. (orange, blue-white) The image freezes when you try to unlock, and the bell says “unlocked”.
I use Wifi, voltage 12V rectifier, 2A.

 

[Mlda]

First of all, sorry for my ignorance in these matters.


PROBLEM: DMSS fails connection outside my LAN.

• I have OpenVPN Server in Asus Router (with Merlin) and it is working, because I can login my router Administration WEB UI page through OpenVPN and 4G cell phone (Router has administration from WAN blocked).
• DMSS is working inside my LAN, because I can access NVR and live view cameras with it when I am inside my LAN.
• DMSS failed connection to NVR with OpenVPN and 4G cell phone (Android).

I had NVR access to internet blocked in router, as mentioned here

Within ASUS you have "parental controls" which is one way to "block" the NVR/cams from phoning home. Or you work directly in the iptables and block (all) access (except NTP for example).

Good Luck!
CC

but DMSS failed connection to NVR with OpenVPN, I believe because of this

On the Asus you can't access a blocked device over the VPN. When on the VPN you don't truly have a local IP. You have a (usually) 10.10.x.x external address that is routed to a local address. The router sees that as coming from outside and blocks it. So, no, don't block the NVR. You can block the cams. If you need to access one directly for some reason from outside, then you can access the router, unblock it temporarily, do whatever, then block it again. (Technically you can access blocked devices but it requires some non-trivial command lines changes so not as normally done using the router's web interface).

So I unblocked the NVR access to internet in the router. Now I need to create some Firewall rules. I've been reading about iptables in Asus-Merlin SNBForums, only to conclude that it is to much load for my truck. It really looks complex.

Can somebody confirm if it is possible to achieve that goal using firewall rules in my router (Firewall Network Services Filter, LAN to WAN filters), to block all NVR internet access except NTP Server, Push Notifications and OpenVPN access to my NVR?

I can use Black Lists and White Lists, such as

Source IP	Port Range	Destination IP	Port Range	Protocol

but they are LAN to WAN filters, so I'm not sure I will be able to allow OpenVPN access to NVR.

Thanks.

 

[catcamstar]

Can somebody confirm if it is possible to achieve that goal using firewall rules in my router (Firewall Network Services Filter, LAN to WAN filters), to block all NVR internet access except NTP Server, Push Notifications and OpenVPN access to my NVR?

Indeed, "Parental" controls on Asus do block VPN access too (because you're coming from outside). I personally never messed with these LAN/WAN filters, but worked hardcore in iptables on my asus. The only drawback is (was?) that changing iptables was not persistent - after every reboot, you need(ed) to script somewhere in init.d the reload of these firewall rules. So clumsy and especially the lack of vlan support made me throw the ASUS over the (h)edge.

Better ask this question on the SNBforum.

Good luck!
CC

 

[Mike A.]

It's been forever since I played with the firewall rules on the Asus. They were kind of flaky at the time sometimes working opposite of how you'd think, not working even though seemingly right, letting traffic through when it should be blocked, etc. Anyway...

OpenVPN access will be easy. As long as the VPN connection is good and the NVR isn't completely blocked from Internet access (as above) then it should work. That's incoming to the network/NVR so not affected by the out-going LAN > WAN firewall rules. Incoming traffic to the NVR otherwise will be blocked unless you somehow open up things beyond the VPN. So you don't have to worry about someone accessing the NVR from outside, you're just left with keeping the NVR from phoning home or doing whatever else like P2P connections originating from within.

For the others it will be more complicated since I think both will use random out-going ports within some range on the client (NVR) to access the remote service. So the Asus firewall rule would need to support a range of possible ports in the out-going direction or an "ANY" type entry. Might try testing a Whitelist rule with the IP of the NVR as the source IP, Port Range blank (for "ANY" as it works for IPs at least), a known NTP server as the destination IP (or maybe also blank for "ANY", Port Range 123, Protocol UDP. If that doesn't work, then try specifying a large port range for the out-going port.

Not sure what ports the NVR uses for notifications but the approach would be the same. You'd need to only permit some range of ports out to whatever port on whatever server(s) handles the notifications.

The above would be with the NVR not blocked from Internet access.

 

[Mlda]

Better ask this question on the SNBforum.

Good luck!
CC

Thank you @catcamstar. Already wasted hours google searching and reading SNBForums. Similar questions have been asked there, with scarse or no response. Guys there have no experience with this simple approach of using Network Services Filter, they are mostly using iptables behind it. Or they advise using iptables, skynet or other ways that seem much to difficult for me.

I'll try and err. My problem is how to test if it is working. You wrote that I can ping from the NVR Network, but I just can´t find that feature (my Fw v. 3.216.x) ?

 

[Mlda]

Thank you @Mike A..

It's been forever since I played with the firewall rules on the Asus. They were kind of flaky at the time sometimes working opposite of how you'd think, not working even though seemingly right, letting traffic through when it should be blocked, etc. Anyway...

Yes, I've learned that from SNBForums.

Might try testing a Whitelist rule with the IP of the NVR as the source IP, Port Range blank (for "ANY" as it works for IPs at least), a known NTP server as the destination IP (or maybe also blank for "ANY", Port Range 123, Protocol UDP. If that doesn't work, then try specifying a large port range for the out-going port.

If I understood it right, if I use a WhiteList everything else that is not in the list will be blocked, meaning that every other devices will be blocked from internet.
So, I'm thinking more in using a BlackList (everything else will be allowed).

I'm going to ask you guys this: can you please just read if the following rules do not seem foolish? You're knowledge and sensitivity will be light-years ahead of mine.

Anyway this is much time consuming. I just need a basic protection to ease my mind and I'm already following the basic advice in this forum:

• using OpenVPN client on my phone;
• now using the NTP server in Asus Merlin, so one less thing to worry, but still considering NVR accessing NTP server outside in the BlackList;
• just need to block everything else except NTP Server and PushNotifications.

BlackList

Source IP	Port Range	Destination IP	Port Range	Protocol
NVR IP	1:122	Blank (= Any)	Blank (= Any)	UDP
NVR IP	124:65535	Blank (= Any)	Blank (= Any)	UDP
NVR IP	1:2194	Blank (= Any)	Blank (= Any)	TCP
NVR IP	2196:65535	Blank (= Any)	Blank (= Any)	TCP

Note: NVR uses port 123 UDP for NTP server and port 2195 TCP for push notifications

Thanks in advance.

 

[DavidDavid]

At this point, could it be worth trying a new VPN host? If using a dedicated machine with blue iris, you could use that computer, or maybe drop $50 on a raspberry pi? There are some good and easy options to set up a VPN service on a PI. Then you can block the NVR from access to the outside and still access on VPN.

It's been a while since I messed with mine (I'm running a VPN server on my NAS, but have set up a VPN server on a PI at another location) but I think for my phone to receive IVS alerts I had to allow one port BEFORE the rule to block the NVR from full outside access. I did NOT open that port in the firewall, just didn't block it if that makes sense.

 

[Mike A.]

The NTP server will be hosted on port 123. Typically, the NTP client (whatever device is accessing the server, e.g., NVR) will use some random available port above 1023 to access the server. And that port is assigned dynamically so it may change.

So if blacklisting, I think that you'd want to reverse the rule. That is, only port 123 at the destination is not blacklisted/blocked. The source range would be < 1023 if you wanted to specify a range for the source IP ports to be blacklisted. In English, any port above 1023 from the NVR cannot access ports below or above 123 on any outside server.

Same for notifications I'd assume.

I think that's right but it's late here and I've had a couple of beers so... ; )

 

[Mlda]

At this point, could it be worth trying a new VPN host? If using a dedicated machine with blue iris, you could use that computer, or maybe drop $50 on a raspberry pi? There are some good and easy options to set up a VPN service on a PI. Then you can block the NVR from access to the outside and still access on VPN.

It's been a while since I messed with mine (I'm running a VPN server on my NAS, but have set up a VPN server on a PI at another location) but I think for my phone to receive IVS alerts I had to allow one port BEFORE the rule to block the NVR from full outside access. I did NOT open that port in the firewall, just didn't block it if that makes sense.

Yes, I think it makes sense, thank you. It's just that I just want to take the easiest approach with the NVR and the Asus router, even if it isn't the safest. As safe as possible.

 

[Mlda]

The NTP server will be hosted on port 123. Typically, the NTP client (whatever device is accessing the server, e.g., NVR) will use some random available port above 1023 to access the server. And that port is assigned dynamically so it may change.

So if blacklisting, I think that you'd want to reverse the rule. That is, only port 123 at the destination is not blacklisted/blocked. The source range would be < 1023 if you wanted to specify a range for the source IP ports to be blacklisted. In English, any port above 1023 from the NVR cannot access ports below or above 123 on any outside server.

Same for notifications I'd assume.

I think that's right but it's late here and I've had a couple of beers so... ; )

Thanks @Mike A..

When you say "the NTP client (whatever device is accessing the server, e.g., NVR) will use some random available port above 1023 to access the server" (1st paragraph), isn't that the opposite of "In English, any port above 1023 from the NVR cannot access ports below or above 123 on any outside server. (2nd paragraph)? You meant "below" where I underlined? Or am I misunderstanding this?

Anyway, something like this

BlackList

Source IP	Port Range	Destination IP	Port Range	Protocol
NVR IP	1:1022	Blank (= Any)	Blank (= Any)	UDP
NVR IP	1023:65535	Blank (= Any)	1:122	UDP
NVR IP	1023:65535	Blank (= Any)	124:65535	UDP
NVR IP	1:1022	Blank (= Any)	Blank (= Any)	TCP
NVR IP	1023:65535	Blank (= Any)	1:2194	TCP
NVR IP	1023:65535	Blank (= Any)	2196:65535	TCP

Note: NVR uses port 123 UDP for NTP server and port 2195 TCP for push notifications

would be in line with what you wrote?

Even if it is and it works I would still be allowing the NVR to access port 123 UDP of any Destination IP, not only the NTP Server, and port 2195 TCP of any Destination IP, not only the Push Notification Server. But that's fine, if this works, I'm happy.

Thanks for taking your time with this.

 

[Mike A.]

It's what I intended to say but maybe not clear.

I was ignoring the NVR ports below 1023 when writing there. Those would be blacklisted completely as you have above. That's easy.

I was only addressing those above. For those, you'd need the conditionals to only permit access to port 123 on whatever server, blacklisting below and above. And it looks like you've done that.

That's for NTP. I don't know how the NVR does it for notifications or if the same range applies.

You could specify server(s) if you know which NTP and notification servers. Better to start with it more open to test.

Whether any of this will actually work on the Asus... shrug. ; )

Try it, see how it goes. I don't know what you have on the NVR to see how/whether things are working or not. If there's a test-type button on the screen where you specify the NTP server, that would work. If not much of a way to see things, then maybe as a way to test you could substitute another computer on your network as the source and use port 80 to try to hit a web page instead of 123. Just as a way to see if the rules are working as you have them structured.

 

[Holbs]

Is P2P on the VTO itself required to get push notifications from a "call" button press? @catcamstar says no, p2p is not required to do push notifications. I gots some troubleshooting to do then.

 

[catcamstar]

Is P2P on the VTO itself required to get push notifications from a "call" button press? @catcamstar says no, p2p is not required to do push notifications. I gots some troubleshooting to do then.

More than 3y after my first deployment ([Review] VTO2000A & VTH1550CH & VTNS1060A Intercom Kit), and still not using any form of p2p, not on the VTO2000, not on my IPC/HDW, nor on my NVR. Push notifications do work once they work. Mind if you are on iOS, that specific port forward 2195 did require a port change to outbound 8888. The latter happened somewhere in March this year, but I saw another user complaining it happened right now.

My advice: put some tcpdump/wireshark on the line and have a look at the outbound chatter when pushing the button.

Good luck!
CC

 

[Holbs]

More than 3y after my first deployment ([Review] VTO2000A & VTH1550CH & VTNS1060A Intercom Kit), and still not using any form of p2p, not on the VTO2000, not on my IPC/HDW, nor on my NVR. Push notifications do work once they work. Mind if you are on iOS, that specific port forward 2195 did require a port change to outbound 8888. The latter happened somewhere in March this year, but I saw another user complaining it happened right now.

My advice: put some tcpdump/wireshark on the line and have a look at the outbound chatter when pushing the button.

Good luck!
CC

yea...I gots wireshark on my tech laptop at work. I'll dabble over the weekend. I suspect firewall issues since it's on a different vlan subnet (thought I allowed the VTO to talk to my main network...but eh....).
but I gotta admit... using WiFi or cellular internet with p2p enabled, it did work super nice and fast for voice & video. Not shabby.

 

[catcamstar]

yea...I gots wireshark on my tech laptop at work. I'll dabble over the weekend. I suspect firewall issues since it's on a different vlan subnet (thought I allowed the VTO to talk to my main network...but eh....).
but I gotta admit... using WiFi or cellular internet with p2p enabled, it did work super nice and fast for voice & video. Not shabby.

Indeed, P2P is fancy for the non tech savvy who buys this set.

Mine is also hidden behind a complex rule based vlan setup, with one (cool) advantage that I can immediately see which vlan is doing crazy things (eg broadcasts to other subnets, or capture that button-push outbount call). Then it's a matter of allowing that particular communication (to WAN OUT interface that is) and hoppa.

But all the feeds and admin are only reachable when openvpn tunnel into the vpn vlan is opened.

Good luck this weekend!
CC

 

[nbstl68]

Do you have to have a Dahua NVR to be able to use this to view your cameras? I have Dahua cameras but only running through BI on my PC. The BI phone app is great but just curious if this is another option to view the cameras on my phone or remote desktop connection.

 

[Holbs]

Do you have to have a Dahua NVR to be able to use this to view your cameras? I have Dahua cameras but only running through BI on my PC. The BI phone app is great but just curious if this is another option to view the cameras on my phone or remote desktop connection.

you do know about UI3, correct? Can view on smartphone via VPN, or local on any device.