On Fri, 21 May 2004, Roger Oksanen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Friday 21 May 2004 16:44, Ole Tange wrote: > > On Wed, 19 May 2004 20:32:08 +0100, Toad wrote: > > > and most of the rest are > > > behind NATs which the user doesn't properly work around. :) > > > > Is there any reason why we cannot use STUN to avoid the NAT problems? > > It ought to be fairly simple to encapsulate the TCP-packets in UDP. > > Tunneling packets in UDP when both hosts are behind NAT has the > following problems: > * Generic NAT tunneling implementations don't work; They require > that one host is on a routable address. > * Tunneling TCP requires a device driver on every platform (see the > Mobile-IP RFC for NAT tunneling). > => This can be solved by running a protocol stack in user space > (i.e. in fred). > * Both ends need to know each others public (NAT) IP address. > * Both ends need to do the "punch hole in NAT" > - The node (A) that wants to contact the other node (B) > must insert a message intended for B, so that B can punch > a hole in the NAT. > - One cannot punch a hole in the NAT so that every IP is allowed. > - Since NAT changes the source port number. A would have > to send the initializing UDP packet to every port on B > (essentially port scan B). > - It might be that the hole that B punched through, only > accepts incoming UDP packets from a specific UDP port > => B has to punch holes for every possible port that > A:s NAT produces source ports for. > > ===> Ouch. Won't work :(
Read RFC-3489 and become enlightened. Or, if that is too much to ask, download/buy a SIP-phone and place a call from behind NAT to behind NAT (_this_ ought to enlighten you). /Ole _______________________________________________ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
