Open ports for NAT with NAT-PMP and UPnP IGD

Earlier, I heard many times that UPnP somehow can open ports on its own (produce Port Forwarding on a router) upon request from a host from a local network. However, the exact manner in which this happens, and which protocols are used for this, until now was covered with a veil of fog for me.



In this article, I want to briefly describe how the two mechanisms for port forwarding, namely the NAT Port Mapping Protocol and the Internet Gateway Device (IGD) Protocol , which is part of the UPnP protocol set, work. To my surprise, I found that in runet information on this issue is more than scant, which inspired me to write this note.

')

First, here’s a short FAQ:



Q: What are these protocols for?

A: To form a rule for forwarding a specific TCP / UDP port (Port Forwarding) on ​​the router, not manually, but “automatically”, i.e. on request from the host on the internal network.



Q: How is this implemented?

A: The device behind NAT sends a request to the router indicating the internal and external port numbers and protocol type (TCP / UDP). If the specified external port is free, the router generates a translation rule and reports to the requesting computer about the successful execution of the request.



Q: Does the router authenticate / authorize requests to open a port?

A: No, not done.



Now consider the work of these protocols in more detail (under the cut).

Port mapping protocol

NAT-PMP is described in RFC 6886. For its work, it uses the UDP port of the server 5351.



Consider the work of the protocol on a specific example - torrent client Vuze 5.7 for Windows 7.



Note: NAT-PMP is disabled by default in Vuze. It must be activated in the plugin settings.



1. Launch Wireshark. In the filter string, enter nat-pmp

2. Start Vuze.

3. We stop packet interception, we watch results.



I got the following:







In total we see 6 packages (3 requests and 3 responses).



The first 2 are a request for the external address of the router and a response indicating this same address. We will not dwell on them in detail and better consider how port mapping takes place using the example of 3-4 packets.



Request:







Here we see that forwarding of external UDP port 48166 to the same internal port is requested. Interestingly, the protocol does not indicate the address of the host to which the translation should occur (Inside Local in Cisco terminology). This means that the router must take the source address of the packet from the IP header and use it as Inside Local.



The parameter Requested Port Mapping Lifetime is expected to indicate the lifetime of the entry in the translation table.



Answer:







As we can see, the router supposedly created the requested broadcast and responded with the code Success . The parameter Seconds Since Start of Epoch means the time since the initialization of the translation table (that is, since the last reset of the router).



The mapping of TCP ports is exactly the same and differs only in the value of the Opcode field.



After the application has stopped using these ports, it can send a translation deletion request to the router.

The main difference between a delete request and a creation request is that the Lifetime parameter is set to zero.



This is what happens if we close Vuze.



Request:







Answer:







At this point, the NAT-PMP review is over, I propose to move on to a slightly more “tricky” UPnP IGD.

Internet Group Device Protocol

For the exchange of its messages, this protocol uses SOAP.



However, unlike NAT-PMP, IGD does not use a fixed port number of the server, so before you exchange messages, you must first find out this port. This is done using the SSDP protocol (this protocol is part of UPnP and is used to discover services).



We start the torrent client. It forms the SSDP request and sends it to the multicast address 239.255.255.250.







The router generates a response and sends it already unicast:







Inside the response, we can see the URL for interacting with the router via IGD.



Next, Vuze connects to the router at the specified URL and receives XML with information about this device, including a set of URIs to control some functions of the router. After the required URI is found in rootDesc.xml, Vuze sends a SOAP request to create a NAT translation using the found URI.



Note: before requesting the creation of a broadcast, Vuze made the router list all available Port Forwarding. For what it was done, I can only guess.



SOAP-request to create a UDP port broadcast:







As mentioned earlier, the desired URI (goes immediately after POST) took Vuze from rootDesc.xml. To add a translation, use a function called AddPortMapping .



It can also be noted that, in contrast to the NAT-PMP, Inside Local address is specified inside the protocol itself.



Similar to NAT-PMP, when you close the torrent client, mappings of the forwarded ports are deleted. This is done with the DeletePortMapping function:







You may notice that to delete a rule, you only need to specify the protocol type (UDP) and the external port number, without specifying the other parameters.

Conclusion

In this article, we looked at two fairly simple ways to create Port Forwarding rules on a home router on command from a host from a local network. It remains only to note that if you consider the operation of these protocols to be a threat to the security of your home network, you can try to turn them off (although, of course, it is much better to entrust the security issues to the utility that is designed for this - the firewall). In the case of my Zyxel Giga II, on which, by the way, all tests were performed, this is done by the no service upnp CLI command (it is noteworthy that there is no UPnP enable / disable option in the web interface).