P2P Through Firewalls 220
An anonymous submitter writes "A few stream-through-firewall applications have been announced recently. p2pnet has an interview with Ian Clarke about his new 'Dijjer' program, which promises to reduce bandwidth requirements from HTTP servers by transparently distributing the load. Slyck.com has an article about LimeWire's new version that offers firewall-to-firewall transfers (code here). [Both Dijjer and LimeWire are GPL'd.] There's also been a lot of discussion on the p2p hackers list about reliable UDP transfers."
please dont (Score:5, Funny)
Re:please dont (Score:4, Insightful)
Re:please dont (Score:3, Informative)
I don't know about you (Score:4, Interesting)
Re:I don't know about you (Score:5, Informative)
Re:I don't know about you (Score:5, Funny)
Re:I don't know about you (Score:2)
limewire = spyware free (Score:2, Informative)
Besides the official site stating categorically no adware, spyware, or bundled software, have an actual read of the page you linked to. It's written by a desperately technologically impaired writer who probably just got these from another source.
But... (Score:5, Insightful)
Seriously, though, this is the kind of thing that I desperately wish mainstream media/Congress paid more attention to. It's only the lawsuits and illegal uses that get covered because that's what sells ads.
Re:But... (Score:5, Funny)
No, it's used for warez, porn and mp3s.
Text of interview (Score:5, Informative)
p2pnet.net News:- Freenet author Ian Clarke is developing Dijjer, a new open source p2p content distribution tool, and he's looking for people to test drive it before it goes online in beta.
"Dijjer is a peer-to-peer HTTP cache, designed to allow the distribution of large files from Web servers while virtually eliminating the bandwidth cost to the file's publisher," he told p2pnet.
"Dijjer is designed to be simple, elegant, and to cleanly integrate with existing applications where possible. Dijjer uses "UDP hole punching" to allow it to operate from behind firewalls without any need for manual reconfiguration.
"Dijjer's distributed and scalable content distribution algorithm is inspired by Freenet."
Below is a brief Q&A.
p2pnet: When did you start working on this?
Clarke: Several months ago. It's hard to pinpoint a specific time because it's a combination of a variety of ideas that have been at the back of my mind for quite some time.
p2pnet: What prompted you?
Clarke: Dissatisfaction with apps like BitTorrent, and a desire to demonstrate that the ideas behind Freenet could be applied to solve other problems.
p2pnet: When do you expect (hope) it'll be completed?
Clarke: Well, I'm sure that development will continue for quite some time, but I hope to release a beta version in four to eight weeks that will be suitable for large-scale adoption.
p2pnet: Who do you see as the principle users?
Clarke: Anyone who needs to distribute large files to large numbers of people but who can't afford to pay for the bandwidth that this would normally require.
The download site [dijjer.org] says features include:
"No Firewall configuration
With many P2P applications you must reconfigure your firewall to get the most out of them. Not so with Dijjer, we use state-of-the-art "NAT2NAT" techniques to get the most out of your internet connection without any reconfiguration.
"Sequential downloads
If you tried to download a video through Dijjer you may have noticed that you could start watching the video before the download completed. This is because Dijjer behaves like a web server, pieces of a file are download in-order and fed to your web browser when they arrive, allowing your browser to start displaying content before it has completely downloaded.
"No "Tracker" necessary, works with virtually any URL
This is a big one, Dijjer will work with almost any direct URL, the content publisher doesn't need to lift a finger - they may not even realise that people are using Dijjer to save their bandwidth costs!
"Cross platform and native compilable
Dijjer is implemented in Java, meaning that it will run on Windows, Linux, and Macs. Those who don't wish to install the Java Runtime Environment (JRE) will be pleased to note that Dijjer can be compiled with the GNU Compiler for Java (JCJ) to native code thus eliminating the need for a JRE. Native compiled versions of Dijjer will be available from this site in due course.
"Free as in Speech
Dijjer will be released under the GNU Public License.
"No cumbersome clients
Dijjer downloads through your web browser or preffered HTTP download application. You don't need to learn to use yet another P2P client user interface.
"Advanced scalable distributed caching algorithm
Dijjer uses a highly scalable distributed caching algorithm inspired by Freenet. This will allow it to deliver faster download speeds while placing less burden on the web server, and will be better able to handle sudden increases in demand for content."
"Now all I need are some people to help me test it,"says Clarke.
Re:Text of interview (Score:4, Funny)
Sweet! Maybe it will be as fast as Freenet!
Re:Text of interview (Score:2)
You *do* realize that Freenet is so slow on account of its design constraints wrt privacy and anonymity -- constraints that don't apply to this project -- right?
Re:Text of interview (Score:2)
I hope that's true, but I don't see why you're so sure. There are many other good candidate reasons that Freenet is slow.
*Any* URL? (Score:3, Interesting)
This is a big one, Dijjer will work with almost any direct URL, the content publisher doesn't need to lift a finger - they may not even realise that people are using Dijjer to save their bandwidth costs!
So, am I to understand that when using dijjer you are broadcasting your web surfing habits all the time in the hopes that someone other than marketers and police are out there listening? Or is there some anonymizing Freenet magic going on here? Givi
Re:Text of interview (Score:2)
Been waiting for this! (Score:2, Interesting)
Seems like somebody finally came up with the answer!
Freespirit
Hamachi (Score:2)
but it does promise exactly what you are looking for. 2c.
Re:Been waiting for this! (Score:3, Interesting)
Essentially, UDP is a stateless system, so stateful firewalls don't have SYN packets to signal the start of a connection, so you can do the following
Reliable... udp... transfers? (Score:5, Insightful)
Re:Reliable... udp... transfers? (Score:5, Informative)
Most modern UDP transfer systems use NACKing, where the receiver just tells the sender if it didn't get a packet (the packets are numbered sequentially) and that it should put it in the retransmit queue. The sender just goes about it's business spewing out packets until it's informed the receiver didn't get one.
Mod parent up. (Score:3, Insightful)
Most of reliable UDP protocols do use unsolicited NACK'ing and solicited ACK'ing. This cuts down overhead on fat pipes to just one ACK per a transfer, which is as low as it gets.
This approach doesn't work well on lossy links or for interactive sessions though.
Re:Reliable... udp... transfers? (Score:5, Insightful)
Re:Reliable... udp... transfers? (Score:2)
Re:Reliable... udp... transfers? (Score:2)
Correct, which is why they should (and most do) use UDP, which is unreliable by design, specifically for the type of situations you cite. Trying to make UDP reliable is totally counter productive. You'll just end up with TCP.
Re:Reliable... udp... transfers? (Score:3, Insightful)
I'm so looking forward to having my bandwidth eaten by a system that wants a precise STFU packet to stop spewing at me.
Ignorance is a bliss (Score:2)
It is essentially a guaranteed system-level NACK, which comes handy exactly in the situation you describe. Every decent NACK-based protocol implementation has ICMP handler (see SOL_IP, IP_RECVERR in setsockopt).
Re:Reliable... udp... transfers? (Score:2)
Re:Reliable... udp... transfers? (Score:2)
Re:Reliable... udp... transfers? (Score:4, Informative)
UDP is connectionless--you just send a packet to a given IP/port and it goes there. This means that you can forge the from address to make it impossible to tell who is sending the file (provided your ISP doesn't filter those as bogus packets). Of course, you still need some way to get the request from the recipient to the sender (along with re-requests for lost packets).
UDP has no flow control--the sender sends as fast has he likes without any knowledge as to what the maximum bandwidth on the connection is. If the sender's direct upstream connection is the bottleneck, then that should be fine, but otherwise there may be huge packet loss. Also, because of the lack of flow control, it tends to hog the bandwidth instead of share the bandwidth.
Re:Reliable... udp... transfers? (Score:2)
eg: TFRC, ftp://ftp.isi.edu/in-notes/rfc3448.txt
Re:Reliable... udp... transfers? (Score:5, Interesting)
a) Instead of a relative small window like TCP, we can make the window as big as we want. This would let us cut down a LOT on ACKs (or pseudo-ACKS in the case of UDP). We can ACK a range, or a range with exceptions, or whatever. For a protocol specializing in bulk transfers, it can really cut down on overhead.
b) TCP guarantees that data arrives to the application in order. This is expensive when we don't care. A custom UDP protocol lets us pick up missing chunks at our leisure, we simply need to maintain a list of missing chunks as the transfer goes along so we can request them later.
c) Since UDP is connectionless, firewalls must create pseudo-connections for UDP. When a UDP packet is sent, the firewall will allow incoming UDP packets from that host/port to the originating port. This gives us a way of signaling to the firewall that we wish to accept UDP packets from that host on that port, even though the client on the other end will never recieve that packet due to their own firewall. Once they've both done it, they have a mutual "connection". This is a brilliant hack, whoever thought of it.
d) We can hide the sender of the data. If we request a file in some mutually accessible place, along with the host/port we're going expect packets from, anyone anywhere can start spewing packets at us with falsified sender information. It's nearly impossible to determine where they came from with UDP.
"However, one must wonder why not just use TCP, which is guaranteed to be reliable. IMHO, What you'd end up with using UDP is a LOT of "did you get it? yes/no"-type network traffic between peers."
TCP does that a lot too (a LOT), it's simply handled by the network stack rather than the application. TCP ACKs cause 1/15th or 1/20th as much upstream traffic as the downstream portion of the connection causes. That adds up when you have a {dsl,cable} modem that's 1/10th as fast with upstream traffic.
Re:Reliable... udp... transfers? (Score:2)
a) Modern TCP implementations (with window scaling) support a maximum window size of approximately 1 GB.
b) A big window, and the selective acknowledgement feature provided by many TCP stacks these days, makes this mostly moot as well.
c) Yeah, until the firewall vendors start looking for this and the whole thing becomes a even more insanely unreliable hackjob than it already is. Why not
Re:Reliable... udp... transfers? (Score:2)
b) A big window, and the selective acknowledgement feature provided by many TCP stacks these days, makes this mostly moot as well."
AFAIK, RFC1323 is not enabled by default in Windows 98, 98SE or XP. Using UDP lets people benefit without messing with their settings. sack is supported, but with a small window it doesn't do as much good.
"c) Yeah, until the firewall vendors start looking for this and the
Re:Reliable... udp... transfers? (Score:2)
Re:Reliable... udp... transfers? (Score:2)
TCP or UDP are both one layer up, layer 4 or 'transport' layer protocols. This layer deals with the logic in communicating between different IP based devices. TCP [Transmission Control Protocol] enforces 'reliable' communications within the p
OT nit (Score:2)
UDP [Unreliable Datagram Protocol]
Good description. But it is User Datagram Protocol
Re:OT nit (Score:2)
Re:Reliable... (TCP/IP vs TCP/UDP) (Score:3, Insightful)
With UDP, if you want reliable transmission, then you have to do all that work yourself. If you have a generally reliable link, then this can be very cheap. It's also very cheap if you onl
Re:Reliable... udp... transfers? (Score:2)
Indeed, the Internet is by design unreliable. TCP fixes this, UDP doesn't.
But it's not too hard to fix it. The question which needs asking is whether it would be better to just use TCP. It sounds like they have reasons for wanting not to, though.
Re:Reliable... udp... transfers? (Score:2)
Not likely (Score:3, Informative)
UDP is actually faster (Score:2)
It'll still take some form of end-to-end acknowledgement scheme, but since it is pushed up to the application, there is less overhead overall.
Of course if EVERY app did this, it would really gum up the Internet.
bittorrent behind a firewall (Score:5, Informative)
While I imagine this is possible with Linux, I have no specific knowledge of how to do it. I did it with PF on OpenBSD.
Re:bittorrent behind a firewall (Score:2)
Re:bittorrent behind a firewall (Score:2)
Re:bittorrent behind a firewall (Score:3, Informative)
pass in on $ext_if inet proto tcp from any to $ext_if \
port $btorrent flags S/SA keep state queue (p2p_bit, low_ack)
Change to:
pass in on $ext_if inet proto tcp from any to $ext_if \
user torrent flags S/SA keep state queue (p2p_bit, low_ack)
Not only will it assign the apropriate queue, but automatically open the ports without specifically defining them?
Re:bittorrent behind a firewall (Score:2)
Re: (Score:2)
Re:bittorrent behind a firewall (Score:2)
Re: (Score:2)
Re:bittorrent behind a firewall (Score:2)
Cross between Coral and BitTorrent? (Score:4, Informative)
This looks like an interesting hybrid of Coral [nyu.edu] and BitTorrent. Coral is nice in that you don't need to install any client-side software to take advantage of it. This one it appears you do need to install a client-side proxy, which is a little scary.
This system seems to utilize a client that takes on roles of both the BitTorrent tracker and the Coral caching nodes. I wonder how the client caches cooordinate? Any centralized server involved here?
Another firewall-busting HTTP serving system is YouServ [nyud.net] (coral link), though geared more at sharing personal content instead of content requiring "super distribution".
Re:Cross between Coral and BitTorrent? (Score:3, Informative)
Limewire = java based. (Score:3, Interesting)
Personnaly I think limewire sucks. Here's the reasons. 1. It's slow and processor hogging.
2. It dosen't melt into my fluxbox theme. (my fault)
3: It requires Java.
But for the ordinary user I think limewire is the best p2p software out there.
Fear kazaa though.
Re:Limewire = java based. (Score:3, Insightful)
Re:Limewire = java based. (Score:2)
Dijjer (Score:3, Interesting)
That is a good thing, but potentially a bad as well, for how some sites make money... I think a needed features is a robot.txt entry that blocks dijjer from caching the site.
Re:Dijjer (Score:2)
I'd state it differently: this potentially breaks the formerly viable business model of certain websites, therefore requiring that such websites adapt or go under... and in so doing, perpetuate the natural competition of a free marketplace rather than restricting the evolutionary opportunit
robots.txt is for search engines (Score:3, Informative)
VPN-mesh? (Score:5, Interesting)
Each PC that wants to share data, acts as a hub with x-number of tunnels going out at one time. The content of each hub could be spidered and locally cached. (kind of like combining a router-cache with a Freenet hub)
It might be slower (like DC++) but you could setup groups of peers that get preferential bandwidth.
BUT you could always add a swarm-like functinality of BT.
a) secure from **AA (as long as you don't let them into your peer-group)
b) distributed load (no central server to take down)
c) because it is a VPN, you don't need to worry a firewall because YOU initiate the connection and keep it open. {I do know that you are fubar if the firewall admin blocks the ports, but wouldn't you be SOL anyway?}
d) well, I just think it sounds kida cool. =)
Re:VPN-mesh? (Score:2, Informative)
Re:VPN-mesh? (Score:2)
How did they get into DC++ hubs? A lot of them are private, yet for p2p apps to really work (for activities that are frowned upon by the *AA's) you need to appeal a large group of people (if I'm only interested in sharing with a small group of people, I can always set an ftp server) so infiltration will always be relatively easy.
The only way you are truly going to be secure, is by masking the origin IP, like FreeNet does, and then y
But... (Score:3, Interesting)
Or perhaps the problem is rather with NAT? In that case, I'm still hoping that someday someone will implement something like RFC 1701 [faqs.org] or somesuch instead of continuously reinventing the wheel.
what's the big problem? (Score:3, Interesting)
POS PC = free from side of road
Smoothwall GPL = free
Problem solved..
Re:what's the big problem? (Score:2)
Re:what's the big problem? (Score:2)
I'm personally not worried about it, if they were hacked it didn't involve the GPL version, they run the corporate version. And if there is a vulnerability in the GPL version, they'll shortly have a patch available.
Also, another poster mentioned add-ins. Yep. A bunch of them. http://sourceforge.net/projects/smoothiemods/ [sourceforge.net]
Re:what's the big problem? (Score:2)
How do you know the GPL version isn't affected? It's the GPL website that's down. One hopes they're being extra carefull double checking all the downloadable files and updates to make sure they haven't had trojaned versions substituted.
Re:what's the big problem? (Score:2)
This guy didn't make the mod, I don't think, he just has some pics of all the mods installed and running
I have very cool way to do this. (Score:2)
If someone out there that is willing to put the time in to implementing a reliable UDP I'd be willing to share my notes and research on how to implement my ECIP error correction over IP as well as my SPAC Protocols. (Selective Packet Acknoledgement) algorythems. They can work together for a really cool solution.
The original code was lost when my former company went bust, it's was mess anyhow.
But the algorythems can be reimplemented.
ECIP [ecip.com]
John L. Sokol
PS: Method of passing bi-directional data between [ecip.com]
Re:I have very cool way to do this. (Score:2)
Dijjer is self defeating (Score:5, Insightful)
Trivially solved (Score:4, Informative)
Re:Dijjer is self defeating (Score:2)
Re:Dijjer is self defeating (Score:2)
Re:Dijjer is self defeating (Score:2)
Followed by virus-through-firewall applications (Score:3, Insightful)
0wn corporate networks! Laugh at their ineffective firewalls. Use them to send spam all night! Resell them on Spamforum.biz [spamforum.biz]. At last, the killer app for "grid computing".
Wondered when.... (Score:3, Informative)
UDP is stateless. There is no connection setup like there is with TCP so there's really no way for a firewall or gateway to statefully track where to send UDP packets, so the typical implementation for NAT'ing UDP is something of a 'best guess' scenario, redirecting certain packets based on port numbers and IP's. These new applications take advantage of this synchronous behavior of NAT devices to permit direct connection between client computers where both are behind NAT firewalls.
NAT of UDP is generally implemented like this: If you begin sending UDP from source port 2000 on your computer to a remote host on port 5000, then the router doing NAT will automatically open up a 'hole' that allows any UDP packet from the remote host from source port 5000 to destination port 2000 on your machine to pass through to you. This is sort of how it works with TCP too; however the firewall only opens up the 'holes' when connections are first set up and only allows packets with correct sequence numbers to pass back through.
Essentially how it works is that two clients decide to "connect" and agree on port numbers, etc through some third host that both can reach via tcp. They then begin broadcasting UDP data to each other. Once a packet goes out from both hosts, the two 'holes' in the firewall will open up. Probably at least one packet will not actually arrive at its indended destination; however, the software can implement its own robust transfer protocol over UDP.
Games have been doing this forever. QuakeWorld (the Quake 1 client tailored to internet play) was one of the first to implement it. Most implentations of SIP support this type of connection.
Swarming Simulation (Score:2)
It allows you to visualize firewalled transfers.
Problem with Dijjler (Score:5, Informative)
This is simmilar to freenet, and indeed will maximize everyone's bandwidth. But it has grave issues when not combined with Freenet's huge anonymimity factors like encryption and hiding IPs , and will open you up to all sorts of legal problems.
I don't want the FBI knocking down my door because my Dijjer client has been downloading kiddie porn for someone else without my knowledge. Sure, I *may* be able to argue in court that it was not me, and hey, I may even be able to prove it. But is that potential trouble worth my saving on some bandwidth? I think not.
Re:Problem with Dijjler (Score:2)
Proof, try it yourself. (Score:2)
Meanwhile, check out some of the output from the server, printed right to STDOUT. Remember - I did not download this file, or make a request for it, and it certianly does not exist on my machine:
8950 -1 -> lysanderspooner.xs4all.nl:9114 : acknowledgeRequest {uid
Re:Problem with Dijjler (Score:2)
Re:Problem with Dijjler (Score:2)
Re:Problem with Dijjler (Score:3, Interesting)
Correlation doesn't imply causality.
URL? I have never heard of that. I have spoken to many ISPs and they secretly love P2P, it is the primary driver for broadband adoption. Well designed P2P can actually red
DMCA explicitly makes caching legal (Score:3, Informative)
Care to be more specific? It seems to me that Dijjer is pretty-much exactly what the system caching [cornell.edu] exemption of the DMCA was intended for.
Dijjer does not create any more liability for its users than a HTTP cache creates for an ISP, and note that virtually all ISPs run HTTP caches, so far as I know, without encountering legal problems.
But how (Score:2)
Freenet? (Score:2)
Re:security? (Score:2)
Re:security? (Score:2)
Re:security? (Score:5, Informative)
Basically it works because UDP doesn't work very well with NATs, and so the NAT has to have a very general policy on what it forwards. UDP is a packet (datagram) based protocol. Each UDP packet is actually just an IP packet with two extra headers added - the source port and the destination port, and then just the data. So how can a NAT know which host on the local network it should send a UDP packet to? It can't really, so it is forced to guess, and the classical way to do this simply to forward incoming UDP packets with a given source port to a host that recently sent an outgoing UDP packet from that source port.
This allows hosts behind the NAT to open something like a server port, by simply sending packets from a certain source port out to the Internet regularly, thus making sure that packets sent to that destination port from the Internet will be sent to them. Note though that this also reveals the scalability problem with UDP and NATs: if you have many machines sending UDP packets from the same ports you get a problem.
On modern, stateful, firewalls, the NATs are slightly smarter, and will only forward the UDP packet to a node in the internal network if that recently sent a packet from the destination port of the incoming packet, and to the host that the incoming packet was sent from. This makes it impossible to act as a general "server", but UDP hole punching is still possible if you have an intermediary who can tell two NATed hosts to start sending UDP packets to each other with certain port values. This means that a non-NATed host is still needed, but it doesn't need to forward all the traffic between the two others, like it would with a proxy solution.
Blah, I meant this to be short, but instead I wasted my time writing a long slashdot post, and now there is probably already a +5 with a shorter description. Everybody mock me...
How to Initiate Connection? (Score:2)
This is pretty easy if you have a 3rd party server to bounce initial requests off of (both clients subscribing and listening for initiation requests), but then it's not really peer-to-peer, is it?
Re:How to Initiate Connection? (Score:3, Informative)
- Someone sends a request that gets routed through the network.
- Someone sends a reply that gets routed back through the network. The reply contains the address of a few [directly connectable] people the replier is connected to.
- The requestor sends a message to the directly connectable folks telling them to tell the replier to start sending UDP packets.
- Requestor & Replier both start se
Re:How to Initiate Connection? (Score:3, Informative)
This definitely an ugly hack, but all NAT is really just an ugly hack, so it isn
Generic Matchmaker? (Score:3, Insightful)
Is there a generic (P2P Protocol Agnostic) matchmakerd? Seems silly to have one for each network. If there were a standard, I could, for example, put a call through to my parents' video phone without having to know their IP address if we both subscribed to the same matchmaker or network of
Re:security? (Score:2)
This sounds a lot easier. A little bit of port randomization, and I have myself a working solution.
~D
UDP Hole Punching explained (Score:4, Informative)
The problem with getting stuff across a NAT gateway is that communication must go through the NAT, and the NAT is generally configured to block incoming traffic unless it's expecting it.
See, NAT works by pretending to be you. When you go get a web page, you send a packet to a webserver. The NAT box, being your gateway, gets this packet, then sends out a reformatted packet of it's own to that webserver. It opens a return port to get the data from that webserver and this gets forwarded along to the receiving system. Basically you're changing the addresses used in both ways, so as to munge the thing between the private and public IP address space.
UDP works in a similar way, it's just modifying addresses going through the gateway. However, with UDP, usually the port number doesn't change. Meaning that when I send a packet out, I don't get to specify what port the responding host sends a return packet back to. I'm expected to know that it'll be coming back on the same port. So NAT deals with UDP pretty simply. The outgoing port and incoming port are the same. This is open to possible abuse, so most NAT boxes only forward packets from the original host back to the private network.
That's potentially confusing, so I'll use an example:
Computer A is behind a NAT. He sends a UDP packet to computer B on the public internet, on port 30000. The NAT munges the outgoing address and forwards it to computer B. Computer B sends back a UDP packet on port 30000. The NAT verifies that he is only allowing B to respond on that port, and sends the packet back to computer A. If computer C were to send something to the NAT on port 30000, it would be discarded by the NAT (not all NAT's do this, some allow anything in for a short time instead).
In the case where only one system is behind a NAT, this is easy to solve. The computer behind the NAT must initiate the connection. That's all there is to it. Computer A initiating the connection makes it possible for the NAT to send stuff back to computer A, and so all is good.
In the case where both computers A and B are behind their own NAT, suddenly they have no way to talk to each other. Anything A sends to B gets dropped by B's NAT, and anything B sends to A gets dropped by A's NAT. The only fix for this has been port forwarding, which manually punches a hole in one or both NAT devices.
UDP Hole Punching exploits the UDP behavior of NAT devices to allow A and B to communicate directly without any port forwarding being needed. It works like this:
Computer A sends a UDP packet to computer B on port 30000. This act opens the hole in the NAT for B to talk to A on port 30000. At the same time, A sends a packet to Server S on the P2P network. This packet basically asks computer B to send something to computer A on port 30000. Server S routes the packet to computer B over the already setup P2P network. Computer B then sends something to computer A on the given port, and they can now talk directly and setup other ports if they likee by this single channel of communication that they have gotten open.
And that's all it is, really. Just a way of using an intermediary that can talk to both A and B (via the already established P2P routing) to allow them to talk directly. Nothing particularly tricky.
Why UDP? Because UDP doesn't get the port changed by the NAT. TCP connections over a NAT usually get ports munged by the NAT without informing the computer behind the NAT. That's part of the "transparency" portion of NAT. The less tricky behavior of UDP on a NAT device makes this possible.
Re:How? (Score:2)
By using non-blocked ports, like port 80 (http). To circumvent application level proxies, the p2p program can make it's own communication look like like common html traffic. This is common with p2p programs, and part of why it's so hard to block that shit.
Re:How? (Score:5, Informative)
After receiving the ACKs, the connections can send UDP data messages in both direction safely. The only trick is you need to ensure that a message is sent every so often so the NAT/firewall doesn't close. If nothing else is sent, a special KEEPALIVE message is sent. Beyond this, the communication is somewhat similar to TCP with a FIN message shutting things down at the end.
Re:If you have ANY port open to the net (Score:2)