Configuration of devices behind NAT and port forwarding

For the ONVIF driver it does not matter if it is connecting directly to a device or through a NAT. One exception is the GetStreamUri command. When a device is behind a NAT it usually does not know this so when it is sending the URL for connecting to a media stream, the device sends it with its own IP address and the port on which it is listening. When such device is behind a NAT, the IP address and port through which the media stream is accessible from outside may be different.

The ONVIF driver ignores the IP address returned in the GetStreamUri response and always uses the IP address with which the device was added in XProtect. The RTSP, HTTP or HTTPS port returned in GetStreamUri is handled differently. If the port is not explicitly specified, the ONVIF driver will use the default port for the protocol. In the case of RTSP this will be 554. For HTTP this will be the port with which the device was added in XProtect (might be different from 80). For HTTPS, the port that is specified in the device settings in XProtect will be used. When the port is explicitly specified in the URL returned in GetStreamUri response, the ONVIF driver will always use that port.

For example, if the device is added with port 8081, but GetStreamUri response returns the URL as follows:

http://192.168.10.50:80/stream1

the ONVIF driver will try to connect on port 80 instead of port 8081.

Here are some possible scenarios for setting up the ONVIF driver to work with devices behind NAT.

Currently it is not possible to use UDP streaming with devices behind NAT (RTP/UDP and RTP/UDP multicast).

Scenario 1: Unsecure, easy setup, everything over HTTP

Streaming Mode: RTP/RTSP/HTTP/TCP

HTTPS: OFF

Device on default port 80.

Forward any port from outside to port 80 on device.

This will work on most devices and is the easiest to setup. This will not work when the HTTP port on the device is different from the default port 80 and the forwarded port is different from it. Also, this will not work on devices that explicitly state the HTTP port in the URL even if it is the default port 80. For the above cases use Scenario 1A.

Scenario 1A: Unsecure, medium setup, everything over HTTP

Streaming Mode: RTP/RTSP/HTTP/TCP

HTTPS: OFF

Device HTTP port must be set to forwarded port.

Forward same port number as HTTP port on device.

This will work on all devices that support RTSP over HTTP streaming. One inconvenience is that the HTTP port on all devices must be changed to a unique value.

Scenario 2: Secure, everything over HTTPS

Streaming Mode: RTP/RTSP/HTTP/TCP

HTTPS: ON

Device HTTPS port must be set to forwarded port.

Forward same port number as HTTPS port on device.

This is the most robust and secure way of adding devices behind NAT in XProtect.

For more information about HTTPS and Media over HTTPS refer to section HTTPS.

Scenario 3: Unsecure, HTTP and RTSP

Streaming Mode: RTSP/RTP/TCP

HTTPS: OFF

Device RTSP port must be set to forwarded port.

Forward same port number as RTSP port on device.

Forward any port number to device HTTP port.