Being in 2021 does not mean using IPv6 in LAN, WAN, or for Internet reachability. We are still in the IPv4 world for 90% of use-cases and desperately looking for available public IPv4 addresses. We have to use NAT mechanisms to preserve IPv4 addresses and somehow manage a huge misbalance between the number of IP addresses consumers and available address space. While the NAT is proofed workaround for the IP address exhaustion issue, it is causing a significant problem for protocols and applications that are point-to-point by nature. In this set of articles, I am going to describe different NAT bypass methods, their use-cases and give you an idea of their current usage in the real world.
Let’s start with the most common problem definition.
Imagine, we have host A that sits behind NAT gateway R1 (usually physical or virtual router or firewall). It is worth mentioning that R1 is performing dynamic port address translation (PAT) for traffic initiated by A (host in LAN) to B (host in WAN) and not vice-versa. This is a very popular scenario for a small office/branch connection to the Internet and this is the only available option in our home networks. When A needs to communicate with B, we do not have any problem with it and 100% of PAT-compatible gateway will be able to provide the required translation ‘private IP:private port’ pair to ‘public IP:public port’ pair. However, what will happen when B requires to initiate a connection to A? Depending on NAT implementation on R1 and type of traffic (ICMP, UDP, TCP, IPsec, etc) the result can be different but in the most common case, the communication will be simply rejected. Even if B knows A public IP address, it may be not aware of the correct transport level port to establish the connection. TCP session initiated by outside host may be blocked by firewall (SYN-packet arriving on outside interface can be dropped due to PAT unidirectional principle). Eventually, these and some other factors most likely would prevent B from communicating with A, especially if B also sits behind another NAT gateway(s).
Universal Plug And Play or UPnP is a set of protocols that allows NAT gateway to automatically create Port Forwarding entries upon the LAN host request.
There are two main UPnP mechanisms on R1: NAT Port Mapping Protocol (NAT-PMP) and Internet Gateway Device (IGD) Protocol. Due to an application unawareness of UPnP implementation on NAT gateway, usually, the application tries to utilize both available UPnP mechanisms simultaneously and expects one of them to be supported on R1. In this part of the series we will focus on the first mechanism – NAT Port Mapping Protocol.
- R1 supports UPnP NAT-PMP and the gateway is under your control
- A is a LAN host that uses private IP
- B resides in the Internet/WAN and configured with Public/External IP
- Some application requires B to establish UDP/TCP-based session with A on port Z
NAT-PMP is described in RFC 6886. It uses UDP port 5351 for communication. To show you the protocol principles I launch uTorrent client and Wireshark on my Windows 11 machine. After running uTorrent, you can use the ‘nat-pmp’ filter to capture desired communication. Unfortunately, the router provided by my ISP does not support NAT-PMP, however, we may still see the uTorrent attempts to allocate NAT translation using this protocol. The very first packets that NAT-PMP-capable application releases are Map TCP Request and Map UDP Requests
As you can notice from the picture, uTorrent client is trying to establish a connection with the router on port UDP 5351. This packet includes the following important information:
- Opcode – a packet type. Can have one the following values:
0 – External Address Request
1 – Map UDP Request
2 – Map TCP Request
128 – External Address Response
129 – Map UDP Response
130 – Map TCP Response
- Internal Port – UDP/TCP port on which application (uTorrent in our case) is going to listen
- Requested External Port – the external port that should be allocated on a NAT gateway
- Requested Port Mapping Lifetime – a lifetime of the Port Forwarding entry.
As we can see for the very first packet, ‘Requested Port Mapping Lifetime’ is set to zero. This means the first thing that NAT-PMP client normally tries to do is to age-out existing similar Port Forwarding translation on NAT gateway. This is to make sure that the new lifetime of the translation will be set with the following packets and may be useful if the application was previously shut down unexpectedly and required Port Forwarding translation still exists on the NAT gateway. In addition, NAT-PMP-capable applications set ‘Requested Port Mapping Lifetime’ to zero during the graceful shutdown process to age-out created PAT entries upon exit.
Both ‘Map UDP Request’ and ‘Map TCP Request’ should be followed by corresponding response packets. In the previous picture, you may see ICMP Port Unreachable packets instead. As I already mentioned my router does not support NAT-PMP but normally, NAT gateway replies with ‘Map UDP/TCP response’ packet that among others includes ‘Result code’ field. The field can take of the following values:
0 – Success
1 – Unsupported Version
2 – Not Authorized/Refused (e.g. NAT gateway supports mapping, but user has turned feature off)
3 – Network Failure (e.g. NAT gateway itself has not obtained a DHCP lease)
4 – Out of resources (NAT gateway cannot create any more mappings at this time)
5 – Unsupported opcode
So, under normal circumstances, you can expect ‘Map UDP/TCP response’ packet with ‘Result code’ set to zero.
Regardless of the age-out existing Port Forwarding communication results, the NAT-PMP-capable application will try to send another TCP and UDP mapping requests with the same ‘Internal Port’ and ‘Requested External Port’ values. This time the application will set ‘Requested Port Mapping Lifetime’ to its default non-zero value (3600 seconds for uTorrent).
Again, in a normal scenario, R1 should reply with ‘Map UDP/TCP response’ packet with ‘Result code’ set to ‘0’ (Success) and can configure the requested Port Forwarding entry. The NAT gateway already has all the required information to create NAT translation:
- Inside IP Address – source IP address taken from IPv4 header of the request packet
- Inside Port – from ‘Internal Port’ field
- Outside IP Address – R1’s own external IP address
- Outside Port – from ‘Requested External Port’ field.
However, at that time, the NAT-PMP-capable application is not aware of the External/Public IP address that it should inform host B about. The application requests this information by sending ‘External Address Request’ packet.
The response to this request must have the following format (taken from RFC 6886):
As you may guess, the NAT-PMP-capable application can now use the IP address received in ‘External IPv4 Address’ field of ‘External Address Response’ packet for sharing with B.
After this stage, B can communicate with A using ‘Outside IP Address:Outside Port’ pair as the Destination.
The NAT-PMP-capable application should try to renew the mapping halfway to expiry time (after 1800 seconds for uTorrent) and, as previously mentioned, should send ‘Map UDP/TCP Request’ with ‘Requested Port Mapping Lifetime’ set to zero in case of a graceful shutdown.
List of popular applications using NAT-PMP
- BitTorrent, Bitcomet, Deluge, Frostwire, µTorrent, qBittorrent, Transmission, Vuze – BitTorrent file-sharing clients
- Colloquy – an Internet Relay Chat client.
- Crashplan – an offsite backup program.
- FarFinder – a remote file access application for OS X.
- FreeSWITCH – an open source telephony platform.
- Folx – a downloader for Mac, used for torrents or normal downloads.
- Limewire – a Gnutella file-sharing client.
- Natpmpd – a software implementation of NAT-PMP for OpenBSD
- Nicecast – a music-streaming program.
- Stallone – a software implementation of NAT-PMP for linux/iptables.
- ShareTool – an automated VPN program for OS X.
- MobileMe – Apple Inc’s mobile device synchronization service.
In the next article, we will take a closer look at the second UPnP mechanism – Internet Gateway Device Protocol and will focus on some security concerns common for UPnP protocols. Stay tuned.