Re: [freenet-support] Re: freenet on slashdot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 21 May 2004 22:10, Ole Tange wrote: > 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. I read it. And I can't say I have changed my mind. To use the terminology found in the RFC: The "port restricted cone nat" is the problem I tried to describe in my post. STUN does not solve that problem: The binding acquisition usage of STUN does not work for all NAT types. It will work for any application for full cone NATs only. For restricted cone and port restricted cone NAT, it will work for some applications depending on the application. Application specific processing will generally be needed. For symmetric NATs, the binding acquisition will not yield a usable address. The tight dependency on the specific type of NAT makes the protocol brittle. => "Application specific processing" generaly looks like it needs external support, such as a server with a public IP forwarding the traffic between the two hosts. It is in my belief that "port restricted cone nat" is the most common NAT found (AFAIK Linux NAPT can be counted to this group). Next in line would be the "symmetric NAT" that large ISP:s especially in Europe (due to the lack of available IPv4 addressess) use. I wasn't even avare that there are NAPT GW:s that don't track the IP address (restricted cone), and I would find that as a serious security concern.. "Cone nat" should work currently if fred is configured with the external ipAddress. External IP address detection would also be easy to add. If I have misunderstood something fundamental, please correct me. > 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). I'm a full time student, and thus I live on the small financial aid for students (<300รข / month). No way I'm going to afford a SIP phone ;) Could describe the technology used in the SIP phone to penetrate the both NAPT GW:s (assuming they are both "port restructed full cone")? - -- Roger Oksanen <[EMAIL PROTECTED]> +358 50 355 1990 CS Student at Helsinki UniversityPGP id 1B125A3E Homepage http://www.cs.helsinki.fi/u/raoksane/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFArqvj78OZUBsSWj4RAvQyAJ95k8gRnsRds+bypc4p1FJCRHx5BACgv2bF xUpQ38DD7bJ8zn/IwX1zsPI= =Tv/O -END PGP SIGNATURE- ___ 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]
Re: [freenet-support] Re: freenet on slashdot
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]
Re: [freenet-support] Re: freenet on slashdot
On Fri, May 21, 2004 at 07:37:25PM +0100, Toad wrote: > In any case, is it fair to say that we will probably need some sort of > introduction over the network for anything like this to work? i.e. we > will need a way to send a message to a node we are not directly > connected to, through the network? Interesting thought: that's another place I2P could help us! > > On Fri, May 21, 2004 at 07:36:16PM +0100, Toad wrote: > > Umm. I was told that most NATs would use the port number to forward > > packets from any and all external hosts to the one internal PC that has > > used a given port.. is that wrong? > > > > On Fri, May 21, 2004 at 06:48:42PM +0300, Roger Oksanen wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > On Friday 21 May 2004 18:15, Ian Clarke wrote: > > > > Roger Oksanen wrote: > > > > > 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. > > > > > > > > Not true in 85% of cases, most NATs will forward UDP packets that > > > > come from a host to which they recently sent a packet, allowing the > > > > establisment of bi-directional UDP between two NATted nodes. > > > > > > Yes, it will match the "connection" based on the source and destination > > > IP address. Of course, when both computers are behind NAT:s (and I'm > > > talking of NAPT), the source port will be changed when it passes the > > > NAPT gw. Thus when it reaches the other NAPT gw, it's source address is > > > unknown to both A and B, and B:s NAPT gw. The NAPT GW won't let the > > > packet pass to B because it has no way to tell where it should go. > > > > > > Scenario > > > A: Node A:s AP address > > > G1: Node A:s NAPT GW > > > A1: Node A:s NAPT GW IP > > > B: Node B:s IP.. > > > G2: Node B:s NAPT GW > > > > > > A knows B and B1, B knows A and A1 > > > 1) A sends UDP packet 1234:B1:1234 (sourcep:destip:destp - source IP is > > > not intreseting here, so I left it out) > > > 2) G1 changes it to 5678:B1:1234 and remembers it. > > > 3) G2 receives 5678:B1:1234 and drops it, it can't possibly know where > > > it was going > > > > > > 4) Now B could send a packet 1234:A1:5678 (because G1 remembers the > > > route) but how would it know the NAPT port (5678). It can't. So it > > > would have to walk through every possible port. => Out of luck > > > And to make things worse, G2 will also change the source port number, so > > > G1 won't accept the new packet even if B would successfully hit the > > > right destination port. > > > > > > > > > > > > > > > - 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). > > > > > > > > Not if it has been informed of what port to use through out-of-band > > > > means (ie. via an introduction). > > > > > > Introduction works only when the destination node has a public IP and > > > thus can receive the introduction message, from wich it figures out the > > > random port number that the NAPT gw has invented. > > > > > > > > > - -- > > > Roger Oksanen <[EMAIL PROTECTED]> +358 50 355 1990 > > > CS Student at Helsinki University PGP id 1B125A3E > > > Homepage http://www.cs.helsinki.fi/u/raoksane/ > > > -BEGIN PGP SIGNATURE- > > > Version: GnuPG v1.2.3 (GNU/Linux) > > > > > > iD8DBQFAriTa78OZUBsSWj4RAm+zAJ9ahDR7y+gGd3BfH6jBf0BPiUQZrwCfSLmA > > > T+v5vsy7a0clyXww+Zh3ECw= > > > =Vtu3 > > > -END PGP SIGNATURE- > > > ___ > > > 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] > > > > -- > > Matthew J Toseland - [EMAIL PROTECTED] > > Freenet Project Official Codemonkey - http://freenetproject.org/ > > ICTHUS - Nothing is impossible. Our Boss says so. > > > > > ___ > > 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] > > -- > Matthew J Toseland - [EMAIL PROTECTED] > Freenet Project Official Codemonkey - http://freenetproject.org/ > ICTHUS - Nothing is impossible. Our Boss says so. > ___ > 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] -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. signature.asc Descri
Re: [freenet-support] Re: freenet on slashdot
In any case, is it fair to say that we will probably need some sort of introduction over the network for anything like this to work? i.e. we will need a way to send a message to a node we are not directly connected to, through the network? On Fri, May 21, 2004 at 07:36:16PM +0100, Toad wrote: > Umm. I was told that most NATs would use the port number to forward > packets from any and all external hosts to the one internal PC that has > used a given port.. is that wrong? > > On Fri, May 21, 2004 at 06:48:42PM +0300, Roger Oksanen wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On Friday 21 May 2004 18:15, Ian Clarke wrote: > > > Roger Oksanen wrote: > > > > 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. > > > > > > Not true in 85% of cases, most NATs will forward UDP packets that > > > come from a host to which they recently sent a packet, allowing the > > > establisment of bi-directional UDP between two NATted nodes. > > > > Yes, it will match the "connection" based on the source and destination > > IP address. Of course, when both computers are behind NAT:s (and I'm > > talking of NAPT), the source port will be changed when it passes the > > NAPT gw. Thus when it reaches the other NAPT gw, it's source address is > > unknown to both A and B, and B:s NAPT gw. The NAPT GW won't let the > > packet pass to B because it has no way to tell where it should go. > > > > Scenario > > A: Node A:s AP address > > G1: Node A:s NAPT GW > > A1: Node A:s NAPT GW IP > > B: Node B:s IP.. > > G2: Node B:s NAPT GW > > > > A knows B and B1, B knows A and A1 > > 1) A sends UDP packet 1234:B1:1234 (sourcep:destip:destp - source IP is > > not intreseting here, so I left it out) > > 2) G1 changes it to 5678:B1:1234 and remembers it. > > 3) G2 receives 5678:B1:1234 and drops it, it can't possibly know where > > it was going > > > > 4) Now B could send a packet 1234:A1:5678 (because G1 remembers the > > route) but how would it know the NAPT port (5678). It can't. So it > > would have to walk through every possible port. => Out of luck > > And to make things worse, G2 will also change the source port number, so > > G1 won't accept the new packet even if B would successfully hit the > > right destination port. > > > > > > > > > > > - 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). > > > > > > Not if it has been informed of what port to use through out-of-band > > > means (ie. via an introduction). > > > > Introduction works only when the destination node has a public IP and > > thus can receive the introduction message, from wich it figures out the > > random port number that the NAPT gw has invented. > > > > > > - -- > > Roger Oksanen <[EMAIL PROTECTED]> +358 50 355 1990 > > CS Student at Helsinki UniversityPGP id 1B125A3E > > Homepage http://www.cs.helsinki.fi/u/raoksane/ > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.2.3 (GNU/Linux) > > > > iD8DBQFAriTa78OZUBsSWj4RAm+zAJ9ahDR7y+gGd3BfH6jBf0BPiUQZrwCfSLmA > > T+v5vsy7a0clyXww+Zh3ECw= > > =Vtu3 > > -END PGP SIGNATURE- > > ___ > > 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] > > -- > Matthew J Toseland - [EMAIL PROTECTED] > Freenet Project Official Codemonkey - http://freenetproject.org/ > ICTHUS - Nothing is impossible. Our Boss says so. > ___ > 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] -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. signature.asc Description: Digital signature ___ 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]
Re: [freenet-support] Re: freenet on slashdot
Umm. I was told that most NATs would use the port number to forward packets from any and all external hosts to the one internal PC that has used a given port.. is that wrong? On Fri, May 21, 2004 at 06:48:42PM +0300, Roger Oksanen wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Friday 21 May 2004 18:15, Ian Clarke wrote: > > Roger Oksanen wrote: > > > 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. > > > > Not true in 85% of cases, most NATs will forward UDP packets that > > come from a host to which they recently sent a packet, allowing the > > establisment of bi-directional UDP between two NATted nodes. > > Yes, it will match the "connection" based on the source and destination > IP address. Of course, when both computers are behind NAT:s (and I'm > talking of NAPT), the source port will be changed when it passes the > NAPT gw. Thus when it reaches the other NAPT gw, it's source address is > unknown to both A and B, and B:s NAPT gw. The NAPT GW won't let the > packet pass to B because it has no way to tell where it should go. > > Scenario > A: Node A:s AP address > G1: Node A:s NAPT GW > A1: Node A:s NAPT GW IP > B: Node B:s IP.. > G2: Node B:s NAPT GW > > A knows B and B1, B knows A and A1 > 1) A sends UDP packet 1234:B1:1234 (sourcep:destip:destp - source IP is > not intreseting here, so I left it out) > 2) G1 changes it to 5678:B1:1234 and remembers it. > 3) G2 receives 5678:B1:1234 and drops it, it can't possibly know where > it was going > > 4) Now B could send a packet 1234:A1:5678 (because G1 remembers the > route) but how would it know the NAPT port (5678). It can't. So it > would have to walk through every possible port. => Out of luck > And to make things worse, G2 will also change the source port number, so > G1 won't accept the new packet even if B would successfully hit the > right destination port. > > > > > > > - 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). > > > > Not if it has been informed of what port to use through out-of-band > > means (ie. via an introduction). > > Introduction works only when the destination node has a public IP and > thus can receive the introduction message, from wich it figures out the > random port number that the NAPT gw has invented. > > > - -- > Roger Oksanen <[EMAIL PROTECTED]> +358 50 355 1990 > CS Student at Helsinki University PGP id 1B125A3E > Homepage http://www.cs.helsinki.fi/u/raoksane/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD8DBQFAriTa78OZUBsSWj4RAm+zAJ9ahDR7y+gGd3BfH6jBf0BPiUQZrwCfSLmA > T+v5vsy7a0clyXww+Zh3ECw= > =Vtu3 > -END PGP SIGNATURE- > ___ > 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] -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. signature.asc Description: Digital signature ___ 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]
Re: [freenet-support] Re: freenet on slashdot
On Fri, May 21, 2004 at 03:44:20PM +0200, 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. What is STUN? Certainly we could write a UDP transport... > > /Ole -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. signature.asc Description: Digital signature ___ 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]
Re: [freenet-support] Re: freenet on slashdot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 21 May 2004 18:15, Ian Clarke wrote: > Roger Oksanen wrote: > > 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. > > Not true in 85% of cases, most NATs will forward UDP packets that > come from a host to which they recently sent a packet, allowing the > establisment of bi-directional UDP between two NATted nodes. Yes, it will match the "connection" based on the source and destination IP address. Of course, when both computers are behind NAT:s (and I'm talking of NAPT), the source port will be changed when it passes the NAPT gw. Thus when it reaches the other NAPT gw, it's source address is unknown to both A and B, and B:s NAPT gw. The NAPT GW won't let the packet pass to B because it has no way to tell where it should go. Scenario A: Node A:s AP address G1: Node A:s NAPT GW A1: Node A:s NAPT GW IP B: Node B:s IP.. G2: Node B:s NAPT GW A knows B and B1, B knows A and A1 1) A sends UDP packet 1234:B1:1234 (sourcep:destip:destp - source IP is not intreseting here, so I left it out) 2) G1 changes it to 5678:B1:1234 and remembers it. 3) G2 receives 5678:B1:1234 and drops it, it can't possibly know where it was going 4) Now B could send a packet 1234:A1:5678 (because G1 remembers the route) but how would it know the NAPT port (5678). It can't. So it would have to walk through every possible port. => Out of luck And to make things worse, G2 will also change the source port number, so G1 won't accept the new packet even if B would successfully hit the right destination port. > > > - 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). > > Not if it has been informed of what port to use through out-of-band > means (ie. via an introduction). Introduction works only when the destination node has a public IP and thus can receive the introduction message, from wich it figures out the random port number that the NAPT gw has invented. - -- Roger Oksanen <[EMAIL PROTECTED]> +358 50 355 1990 CS Student at Helsinki UniversityPGP id 1B125A3E Homepage http://www.cs.helsinki.fi/u/raoksane/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAriTa78OZUBsSWj4RAm+zAJ9ahDR7y+gGd3BfH6jBf0BPiUQZrwCfSLmA T+v5vsy7a0clyXww+Zh3ECw= =Vtu3 -END PGP SIGNATURE- ___ 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]
Re: [freenet-support] Re: freenet on slashdot
Roger Oksanen wrote: 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. Not true in 85% of cases, most NATs will forward UDP packets that come from a host to which they recently sent a packet, allowing the establisment of bi-directional UDP between two NATted nodes. * Both ends need to know each others public (NAT) IP address. Shouldn't be much of a problem since peers can be introduced to each-other by nodes to which they already have connections. - 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). Not if it has been informed of what port to use through out-of-band means (ie. via an introduction). Ian. ___ 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]
Re: [freenet-support] Re: freenet on slashdot
-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 :( - -- Roger Oksanen <[EMAIL PROTECTED]> +358 50 355 1990 CS Student at Helsinki UniversityPGP id 1B125A3E Homepage http://www.cs.helsinki.fi/u/raoksane/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFArhl678OZUBsSWj4RAlCCAKCN7XdEt/TDBifSyuBqCydvRu/QnQCeIQSE sj1QcN38kBmPYZ1iew3D9UI= =VaAB -END PGP SIGNATURE- ___ 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]
Re: [freenet-support] Re: freenet on slashdot
>> 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. Doesn't STUN involve connections to a centralised server? If so, we wouldn't be able to use that for connections between two behind-a-nat freenet nodes... ___ 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]
