Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I'm trying to understand why UDP hole punching works.

  1. Given peers A, B behind a NAT router and Server with port 80 open.
  2. A sends a packet to Server from port 1234. This causes the router to open a route from/to A:1234 and S:80
  3. B sends a packet to Server from port 4321. This causes the router to open a route from/to B:4321 and S:80

At this point, A is supposed to be able to send directly packets to B:4321 and B is supposed to be able to send packets directly to A:1234.

I have two questions:

  1. Is my understanding of UDP hole punching correct?
  2. Why don't routers check that the packet source IP matches Server? Isn't this a security risk?

UPDATE: Answering my own question here since it is marked as closed. NAT hole punching works as follows:

  1. Given peers A, B behind a NAT router and Server.
  2. A and B connect to Server and send it a list of ports they will be using for outgoing/incoming connections.
  3. Assuming that A lists port 1234 and B lists port 4321, then A sends a packet from port 1234 to B on port 4321. This causes the router to open a route from/to A:1234 and B:4321.
  4. B's router blocks the request silently but A's router keeps the connection open waiting for a reply.
  5. B sends a packet from port 4321 to A on port 1234. This causes the router to open a route from/to B:4321 and A:1234.
  6. A's router accepts the incoming connection, thinking it is a response to step 3.
  7. We're done. Notice that throughout this process, we only used outgoing connections from A and B.
share|improve this question

closed as not constructive by techie007, TFM, BBlake, Canadian Luke, ChrisF Nov 19 '12 at 22:48

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

    
I believe how that usually works is this: suppose A does not trust B, and B does not trust A (e.g. hardware or software firewall). Assume that S is trusted, and connectable, by both A and B. Since S is TRUSTED, both A and B think communication is coming to and from S (well, because it technically is, in your example) - because A and B trust S - even if in fact A and B are communicating each other through S - I believe thats the case in which it works. –  sajawikio Nov 19 '12 at 18:26
    
@sajawikio, you misunderstood my question. In my example, A and B are communicating directly with one another. I've updated the question to make this more obvious. –  Gili Nov 19 '12 at 18:32
    
I believe that in that scenario A and B are not directly blocked by firewall, but A and B do not initially have any idea how to reach each other. A and B in your scenario contact S and exchange "endpoint infrormation" in order to communicate directly without S's help (S only gives the endpoint information to both clients). In some cases it is not possible to do hole punching if there's too many NAT's between the two servers and it has to resort to talking through S as I described first - see brynosaurus.com/pub/net/p2pnat –  sajawikio Nov 19 '12 at 18:43
add comment

Browse other questions tagged or ask your own question.