How Skype Punches Holes in Firewalls 215
An anonymous reader writes "Ever wondered, how P2P software like Skype directly exchanges data — despite the fact, that both machines are sitting behind a firewall that only permits outgoing traffic? Read about the hole punching techniques, that make a firewall admin's nightmares come true."
Great article (Score:5, Interesting)
Re:Confusing title (Score:3, Interesting)
Re:Great article (Score:5, Interesting)
STUN? (Score:2, Interesting)
I've also heard that what Skype does is somehow better than STUN, though it's hard to see how. Can anybody confirm/deny/explain that?
Not exactly new (Score:4, Interesting)
Oh man, this shit is a pain in the ass. I had to look into the over the summer. This is the same technique that Apple's iChat uses for audio and video calls. Many many p2p applications use this technique to get through firewalls and NAT routers. The problem is that it doesn't always work when both computers are behind their own NAT router.
Let's say Bob (as in the example in the article) is behind a NAT, his local ip he got from his router via DHCP is 192.168.1.2, and the public IP of his router is 2.2.2.2. He wants to use UDP port 2828 on his computer to transmit his voice data to Alice. So he sends out the first packed to 1.1.1.1:1414, as in the example. Now because of his NAT it looks like the data is coming from 2.2.2.2 and some arbitrary port (the router can't always use the same source port as the NATed computer because some other computer on the local network might already be using that port to connect to the outside world) lets say his router uses 3939.
Now Bobs router says, "Okay, I'll let through any UDP packets sent from 1.1.1.1:1414 to 2.2.2.2:3939 and I'll pass them on to 192.168.1.2:2828". As in the example, Alice's router will just drop this packet because there is no pre-existing connection from Alice's computer using this info. Then when Alice tries to send a packet to 2.2.2.2:2828 Bob's router drops it because his router isn't expecting traffic to this port. His router is expecting packets to go to port 3939. And Bob has no way of telling Alice which port she should actually be sending packets to since he doesn't even know which port his router decided to use on the public side to send out his packets.
You can get around this if only one computer is behind a NAT, or if you open up a persistent connection through your router to your computer. Anyway, I believe UPnP is supposed to help with this somehow, but I got so sick of it that I switched jobs.
You can do this with TCP too... (Score:5, Interesting)
Re:Great article (Score:3, Interesting)
I was impressed with this technique too. Perhaps the third party for a protocol such at bittorrent could use the seeders as UDP port mediators. It would be pretty easy to determine if the traditional listening port range was being filtered, and then the other seeding peers could do the UDP port exchanges for peers behind NAT firewalls. I don't think having a centralized trust is an issue here, because the whole concept relies on checksums anyway.
Of course I don't intimately understand how the protocol works in terms of discovery of other peers, so I could be talking out of my ass. Feel free to ridicule me if any of you know different.
The only place I could see this falling apart is the added overhead of establishing the scheme for *every* peer that wants to connect to your machine. The handshake to get each other's UDP ports would have to take place on some seeder *each* time a new peer came online, and each new host would somehow need to know which seeder was going to help exchange UDP ports. You would need an election, kind of like the master computer browser election on a NetBIOS PTP network. Perhaps you could handle this in tiers, allowing each "master browser" to handle a certain number of host UDP port exchanges.
Just think if this worked though. It would mean no more leechers!
Perl code (Score:3, Interesting)
http://samy.pl/chownat/ [samy.pl]
Re:Great article (Score:5, Interesting)
Port Scanning (Score:1, Interesting)
So according to this article, Skype reverts to port scanning my computer in some cases depending on how my firewall behaves.
At least under some legislations, port scanning alone is enough to be considered an illegal attack on my information systems. Why does this not apply to Skype?