Skip to content

NAT traversal

Martin Pulec edited this page Jun 16, 2021 · 30 revisions

There are multiple options how to traverse NAT depending on NAT type and whether or not one of endpoint has public IP address. Some of the techniques is implemented in UltraGrid (see below) but most aren't and need to be handled manually. The list below is incomplete, feel free to contact us for details.

Table of contents

UltraGrid options

UltraGrid currently implements PCP and NAT PMP which can be triggered by -N option for the host behind NAT. If you see something like this:

$ uv -N -d gl -r portaudio
[NAT PMP] Public IP address: 93.184.216.34
Successfully set NAT traversal with NAT PMP. Sender can send to external IP address.

It means that UltraGrid ports (UDP 5004 and 5006 by default) are forwarded. Remote peer may send to the external IP address. The -N/--nat-traversal parameter also accepts some options, see uv -Nhelp.

UDP hole punching

In this scenario, we assume one host has a public IP while the other doesn't. We are assuming that the side behind NAT is a receiver. If it were a sender only, the situation is trivial and doesn't need any workaround.

The idea behind the approach described below is that the computer behind NAT initializes the connection. It is analogous to TCP in a sense that the NAT keeps track of the "connection" state even for UDP. Client behind the NAT is required to send keepalive data to keep the UDP hole open the whole time (even if it acts as a receiver only).

In easiest scenario, we create an UDP hole from inside and send to it from outside. We are assuming use of default ports (5004 for video, 5006 for audio). Assuming that A has public IP while B is behind NAT (doesn't have a public IP address).

A ---------------- B NAT --- B
^                     ^      ^
|                     |       \
A IP (pub)      NAT IP (pub)   B IP (private)

This approach utilizes a concept of UDP hole punching. Follows the setup of both machines.

Behind NAT (host B)

If we act in a full-duplex way (both sender and receiver), you can use simply:

uv -t decklink -c JPEG -d gl A

Please note that both -t and -d are required.

If you want to receive only, use something like:

uv -t testcard:32:32:10:UYVY -d gl A

to generate a dummy keepalive traffic (to keep the connection open).

Outside NAT (host A)

In easiest case you can run UltraGrid as usual (assuming you now B's NAT IP address):

uv -t decklink -d gl B_NAT

This is sufficient if you send and receive, if outside UltraGrid is sender only, use:

uv -t decklink -c JPEG -P 5004:5004

This is because if UltraGrid acts as a sender only, it uses random source port which may confuse NAT.

This works as long as you know the NAT address and NAT keeps port numbers unchanged. If not, you may obtain the address of the B's NAT and source port by running:

sudo tcpdump udp port 5004 2>/dev/null | head -n 1
16:24:25.346523 IP receiver_ip.57278 > sender_ip.5004: UDP, length 68

There you should see address and src port of the NAT.

With this knowledge, you can send to B using the NAT address and port:

uv -t decklink -P 5004:57278 receiver_ip

Audio

Audio setup is not described to details for simplicity but is analogous to video - we need always send data from inside the NAT (host B) to keep the UDP hole opened.

If the NAT changes port numbers you will also need to obtain the audio source port used by NAT (can be done by jnettop - see above). Full commands may look like:

B$ uv -t decklink -s analog A

A$ uv -t decklink -s alsa -P 5004:NAT_VID_RX:5006:NAT_AUD_RX NAT_IP

or simply (if NAT keeps port numbers):

A$ uv -t decklink -s alsa NAT_IP

Both hosts private address

In this setup either one of techniques bellow may be used.

Another option is to host a relay/translator on some third party host with public IP address. To realize such a scenario, you can use reflectors.

STUN

Note: Not tested

STUN can be used to discover external address and port mapping that can be subsequently used by other side to send to.

With STUN you can traverse several NAT types. First you need to check your NAT type, you can issue:

hostA$ stun -p 5004 stun.sonetel.net
STUN client version 0.97
Primary: Independent Mapping, Port Dependent Filter, preserves ports, no hairpin
Return value is 0x000017

Then match your NAT type according to this page. If your NAT is (address-) restricted cone NAT or full cone NAT (see also here and here), you may be able to send to port opend by STUN:

hostB$ uv -t testcard -c libavcodec -P 3478:5004 <hostA_external_IP>

NAT PMP

NAT PMP is a signalization technique to instruct gateway to forward ports, sample usage using libnatpmp:

natpmpc -a 5004 5004 UDP 7200
natpmpc -a 5006 5006 UDP 7200

adds forwarding of UDP ports 5004 and 5006 to current host for 7200 seconds.

Note: NAT PMP is supported natively by UltraGrid.

UPnP IGP

You can use MiniUPnP tool, first check status:

upnpc -s

If your router accepts IGP, you can set forwarding:

upnpc -a <IP> 5004 5004 UDP [duration]
upnpc -a <IP> 5006 5006 UDP [duration]

PCP

PCP is a evolution of NAT PMP. A working implementation can be found here. Simple use for UltraGrid would be:

pcp -u -i <IP>:5004
pcp -u -i <IP>:5006

where <IP> is machine LAN IP address.

Note: PCP is supported natively by UltraGrid.

Clone this wiki locally