Talk:UDP hole punching
This is the talk page for discussing improvements to the UDP hole punching article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
Unnamed section
[edit]I would very much like to see more information about the success or non-success of this method with common NAT-Router software/hardware. —Preceding unsigned comment added by 84.59.164.245 (talk • contribs) 17:38, 10 September 2005 (UTC)
- See the "Peer-to-Peer Communication Across Network Address Translators" paper linked to from the UDP hole punching page. Brynosaurus 16:49, 22 December 2005 (UTC)
The algorithm seems to be incomplete/wrong to me
[edit]Hello all,
I read over the article and it felt wrong to me what was stated there.
In 3. it sounds like Alice who sends a packet to Bob now uses the address translation that was created when Bob contacted the skype server. But this would not work as the router saves an IP/port tuple to forward any messages. So it would reject the packet from Alice.
The trick is that Bob punches a hole himself when he contacts Alice on the revealed port. Either Alices or Bobs or noones first packet may be rejected by the corresponding router as the port forward is still set to establish a connection to the skype server and not the other buddies client.
Was that too wierd or could everyone follow me ? :)
- Some routers this is the case, but many save the external port and link that to the internal IP without caring what the external IP is. Ksevio (talk) 21:12, 13 March 2013 (UTC)
--Bastian willy (talk) 21:18, 1 June 2011 (UTC) bastian_willy 21:15, 1. June 2011 (UTC)
I agree. The statement of the algorithm is incomplete. The first packet which Alice sends to Bob after Alice receives the server's notice of Bob's {Public IP Address,TU port} tuple, is actually the packet which causes the NAT at Alice's side to create an entry in its translation table, which will then be exploited by packets which Bob sends to Alice. The converse is also true, i.e. the first packet which Bob sends to Alice after Bob receives the server's notice of Alice's {Public IP Address,TU port} tuple, is actually the packet which causes the NAT at Bob's side to create an entry in its translation table, which will then be exploited by packets which Alice sends to Bob (pardon the repeated sentences, I am using them simply to ensure clarity of presentation).
This misleading section has been in place for too long. I am modifying it immediately to prevent further confusion. Edepa (talk) 08:42, 16 October 2013 (UTC)
- The example is getting a little hard to follow - it might be better with some actual ports/IPs as examples. #10 is also incorrect as the worst case scenario would be no connection if the NAT was port restricted. Ksevio (talk) 18:51, 23 October 2013 (UTC)
I do not understand the term "UDP connections" as UPD does not have connections. See this WIKI page — Preceding unsigned comment added by 192.127.94.7 (talk) 17:53, 7 March 2012 (UTC)
- UDP as a protocol does not have connections from the point of view of the client/server, but from the point of view of a firewall/NAT, there is a connection between two clients passing through that needs to be kept open for data to be returned through. Ksevio (talk) 21:12, 13 March 2013 (UTC)
--Action127 10/17/2020
From my understanding, i.e. beyond displayed often transcribed and confusing academic cook-book scenario, after step 3.) there is no Hole Punching from A towards B or vice versa and there is no additional NAT rule definition.
The typical scenario with current internet architecture is that you have cascaded NATs.
The term "UDP connection" might purposely be defined as a set of dynamic forwarding rules of involved NATs, or left out ;).
Those rules are created, when each of A, B send messages to S in a common public network. The public network then knows, how to delegate responses from public address/port of A, resp. B to A, resp. B through all involved NATs. Crucial is, whether the immediate NATs to the common public network, i.e. NA, NB (usually owned by internet providers) serve independent from the sender's address.
Concerning security/firewalls: If UDP Hole Punching basically works in your environment, there is no need to have in-going rules for P2P-applciations like Skype, TeamViewer, ... — Preceding unsigned comment added by Action127 (talk • contribs) 08:37, 17 October 2020 (UTC)
Merge
[edit]I suggest this article is merged with User Datagram Protocol. --MrRatermat2 (talk) 16:40, 22 December 2013 (UTC)
--Action127 (talk) 8:57, 17 October 2020 (UTC) Agree for current version of the article. The UDP protocol itself does not deal with security aspects of internet architecture and firewalls; these appear essential to me and should be added in this article, instead of merging.
Samy Kamkar's 'pwnat' hack?
[edit]Isn't https://samy.pl/pwnat/ worth a mention? 70.124.38.160 (talk) 19:20, 29 December 2022 (UTC)