bigredfish
Known around here
FYI - Those “abnormal upload” alerts are likely your NVR sending emails with images. Worth verifying g but I’ll bet that’s what they are. I see them and traced to my mail host
Multiple Dahua locations trying to gain access to NVR
- Thread starter Nick70068
- Start date
FYI - Those “abnormal upload” alerts are likely your NVR sending emails with images. Worth verifying g but I’ll bet that’s what they are. I see them and traced to my mail host
A non-technical description about what has been said about UDP hole punching. With no ports open, your system will not accept any unsolicited incoming connection requests. It will only accept replies to requests originated from your network. With P2P on, your NVR occasionally sends "I'm here, and this is who I am" outgoing messages to Dahua servers. When a remote client wants to connect, it contacts the same servers, asking "Is the NVR I want to connect to here?". If it is, enough info is sent to the remote client and NVR so they can communicate directly using requests and responses. I don't know offhand how the very first message gets through the firewall.
bigredfish
Known around here
TCP/IP connections are always state-full & connection-full.. They have always static ends (ip/ports numbers) and when internal client open connection to some external server, firewall remembers this pair (client ip/port)<>(server ip/port) and allows only that server to send back a reply to that client..
UDP/IP is state-less. And can be connected to one server ip/port or works connection-less. In second case one internal client ip/port pair can sends many UDP packets to many different servers represented by different server ip/port pairs. And in this case firewall must allow to receive replies from many servers sources - so in most cases they simply open UDP port for some time which redirects to that UDP client.
This is used to traverse NAT firewalls. Opening that UDP port is called UDP hole punching.
Client send two UDP packets to two different STUN servers from the same client ip & UDP port. Because data were sent to two different servers (ip/port pairs), firewall can't create strict pair (client ip/port)<>(server ip/port) so they simply open UDP port on public ip address for any source.
Client by sending query to STUN servers, are asking for public IP/port address from which STUN servers received query (public IP/port translated by NAT in firewall). Both STUN servers sends reply with that public IP/port address and if they are the same it means that firewall simply fully opened UDP port for that client and will accept data from any source (works in state-less and connection-less way).
And anyone who knowns that public IP/port pair can send any UDP data to that client even if the client is behind a firewall.
This operation is done on server (camera, NVR) side and client side (DMSS, SmartPSS). And both sides sends each other by cloud proxy server information about public ip/port combination for opened UDP port by using UDP hole punching. And then they start transmitting directly to other side using that public ip/port of other side.
This process is prone to errors & sometimes need to be repeated a few times to get stable connection (this require time)..
And is very depended on firewall technology (some better corporate firewalls have options to block it).
Also require sending data every 30 seconds even when is no data to send - if there will be no fresh data for some time, firewalls will close this mappings (open port).
And only works on UDP connections - so Dahua private protocol (which is based on TCP/IP) must be encapsulated by some UDP NAT traversal protocol, which works here as VPN.
ps. I wonder how many people on this forum understand my technical answers / descriptions
written in non-native English
Last edited:
