Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

NAT translation not working from inside the network (hairpin condition)

I'm writing a P2P application. Peers regularly ping a main server to update their current IP/port, so when a peer wants to reach another one it can ask the server for that information. For now peers use UPnP to configure the NAT (for classic home setups) to be accessible from outside.

So everything works, except when a peer's client tries to reach another (or the same) peer's server and both are behind the same NAT. Since in that case the client is trying to reach its own "external" (public) IP address from behind the NAT, the NAT doesn't do the port forwarding and is unable to route the IP packet.

For now I'm thinking of two solutions:

  • query the NAT with UPnP to see to which local IP the port is forwarded
  • store on the main server the internal IPs of the peers

Can you think of other solutions? What strategies do mainstream P2P applications implement to solve this problem?

like image 492
Jules Olléon Avatar asked May 18 '11 15:05

Jules Olléon


People also ask

What does hairpin NAT do?

Hairpin NAT allows the internal clients (192.168. 1.0/24) to reach the UNMS server using the public IP address assigned to the EdgeRouter. Follow the steps below to add the Destination NAT and firewall rules to the EdgeRouter: GUI: Access the EdgeRouter Web UI.

How do you check if an IP is Natted?

Go to www.whatismyip.com. If the IP it shows is different from the IP of your NIC, you're behind a NAT. If by NAT you mean any NAT including a WIFI router for example click the windows button, type cmd, click on command prompt, type in ipconfig and press enter, see what it says to the right of "IPv4 Address".

How do I know if my NAT is working?

If NAT is set up correctly, you should see an inbound packet from the 172.16. 0.0 IP space arriving at the Router on UDP port 50000 then arriving at the Master Repeater on exactly the same port. You should also then be seeing this on all sites on the ports used there.


1 Answers

Since in that case the client is trying to reach its own "external" (public) IP address from behind the NAT, the NAT doesn't do the port forwarding and is unable to route the IP packet.

This is known as the hairpin condition. Not all router/NAT solve this properly. The solutions are:

a) Check whether your router/NAT can be configured to enable 'hairpining'. This solution works iff you control all router/NATs in your deployment.

b) Buy another router/node allowing this. Just like a), it works iff your control all router/NATs in your deployment.

c) If you can get obtain the port information for from UPnP, this is a solution too, but not all Router/NAT know or support UPnP. It does not cover for all cases in large deployment.

d) Using multicasting to 'discover' other nodes on the LAN and even communicate with them is a common solution to this problem. You need to agree on an IP address and have peers listen to it.

e) Storing the private IP address on the server is a solution too, but it requires more storage capacity on the server than solution d. There is a timeout (i.e., expiration of data validity) to handle too.

f) Use a TURN like communication between peers (i.e., communication between nodes pass through central server). This solution is rock solid, but not the most efficient in terms of bandwidth consumption.

Hope this helps.

like image 148
Jérôme Verstrynge Avatar answered Sep 27 '22 20:09

Jérôme Verstrynge