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.

Normally a NAT will keep the public end point of a local end point the same for all packets that are coming from it, thus making UDP hole punching easily possible. However, some NATs will map the local end point to a different public one for each different host a packet is sent to, thus making UDP hole punching not possible.

The only way to do traditional UDP punching would be to guess the remote end point. However, since there are more than 65,000 ports, this method is not very reliable. So I've read that applications like Skype - which well-knowingly are able to communicate through pretty much any type of NAT - use a relay for that. Here are my questions:

A relay is simply a socket that transfers incoming data from one socket to another socket, right? Are there any other ways of doing UDP hole punching through naughty NATs without either taking wild guesses or using a relay (which then isn't really "hole punching" anymore)?

share|improve this question

migrated from stackoverflow.com Jan 31 '12 at 23:32

This question came from our site for professional and enthusiast programmers.

add comment

1 Answer

up vote 0 down vote accepted

The term non-well-behaved-NATs is incorrect - any NAT device that uses PAT (port address translation) to aggregate multiple private addresses to a single public address will re-map source ports. This is what "Port Address" refers to in PAT.

It would be impossible for two internal devices to use the same source address to the same destination, and expect the source port to remain the same after NATting, and it doesn't benefit the security posture to attempt to keep the source port consistent when targetting multiple destinations. So this is generally not an aim that firewalls have in their design.

This doesn't help here of course, where you want to know the source port of a connection, without actually receiving any packets from that source. A relay is the obvious option where the endpoints communicate via a third party (yes a relay just transfers packets between sockets as you suggest - the implementation is probably far more complex within skype servers, but in principle it is the same).

It is difficult to see how you could do this any other way, as the endpoints are not aware of the translations that happen in-flight, so they couldn't even communicate what their source port is via a side channel of some kind (like only registering the port with a central server but communicating directly).

share|improve this answer
    
Thanks for your reply. I think you misunderstood me a bit when I was saying "non-well-behaved". What I meant by that were NATs that map packets sent by the same local endpoint to a different public endpoint each if their destination is different. –  user1046192 Feb 1 '12 at 20:15
    
@user1046192 Sure - I did get this, I just wasn't clear I suppose. I was just indicating that this is standard behaviour for most firewalls where PAT is deployed. In any case, that part of the question was just fyi, the answer was more "I don't see an alternative way you can do this as the local endpoints cannot know their public facing udp source ports". –  Paul Feb 1 '12 at 22:22
    
Okay. Thanks for that information. I've read somewhere that it's bad behaviour if NATs do that. The author of that article must have been wrong I suppose. –  user1046192 Feb 2 '12 at 0:42
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.