Stas Khirman wrote: > Alexander wrote: > >> Please note also, to the best of my knowledge, there is still no >> published NAT traversal scheme, comparable on its quality to, say, >> Hamachi. Published NAT traversal mechanisms, like ICE, lacks some >> important knowledge, critical for the high-probability NAT traversal. > > Am I mistaken, but STUN and STUNT claim to penetrate almost 100/90% > (respectively) percents of various NAT combinations? Am I missing something > here? > > http://nutss.gforge.cis.cornell.edu//pub/imc05-tcpnat.pdf
Some people already answered about symmetric NAT traversal. But even cone NAT may have a non obvious problems. For example, consider 2 peers, A and B, each behind its NAT or firewall. After that they have found each other with a help of some public server, they begin NAT traversal procedure: - A sends UDP packet to B. This packet will not probably reach B, but will open hole at the A side - B sends UDP packet to A. This packet most likely will reach A, because UDP hole at A side already opened. But the following scenario is also possible: - A sends UDP packet to B - router at B side responds with ICMP port unreachable message - router at A side, upon reception of this message, CLOSES THE HOLE! - B sends UDP packet to A - router at A side responds with ICMP port unreachable message - router at B side, upon reception of this message, closes the hole - and so on... At this case P2P connection will not be established, regardless both routers are cone. The production NAT traversal software, like Hamachi and Skype, know how to workaround situations like these, but to the best of my knowledge, these tricks are not published, and standard protocols, like ICE, don't include them. _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
