Slashdot Mirror

← Back to Stories (view on slashdot.org)

How Skype Punches Holes in Firewalls

Posted by CmdrTaco on from the i-thought-it-used-a-hammer dept.

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."

10 of 215 comments (clear)

  1. Great article by Nasarius · · Score: 5, Interesting

    I'm impressed, this is really good stuff. The article describes a general technique that can be used to trick most firewalls into believing that a UDP connection has already been established. Is this technique being used or considered by any P2P apps? I've run into the situation several times where I'm firewalled, and the only seeder of a torrent is too.

    --
    LOAD "SIG",8,1
    1. Re:Great article by pilot1 · · Score: 4, Interesting

      Back when eDonkey was still fairly popular, I remember the lMule devs (GNU/Linux port of eMule) were aware of this technique and planned on incorporating it in lMule. BitTorrent became popular, lMule forked many times, and we never got around to it. I'm not aware of any current P2P apps that do it. The problem is that the technique, as they describe it, requires a central trusted server that both sides can connect to. With Skype that's fine, but it's a problem when you're dealing with something that's supposed to be entirely P2P. I don't remember this limitation, so either I have a bad memory or there's some way around it.

    2. Re:Great article by w128jad · · Score: 3, Interesting
      I'm impressed, this is really good stuff. The article describes a general technique that can be used to trick most firewalls into believing that a UDP connection has already been established. Is this technique being used or considered by any P2P apps? I've run into the situation several times where I'm firewalled, and the only seeder of a torrent is too.


      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!
      --
      w2^7me out.
    3. Re:Great article by d3ac0n · · Score: 4, Interesting

      I would imagine that using the tracker server for this purpose would work. Obviously for "trackerless" torrents it would break again, but for standard tracker torrents it would probably work quite well. Couple it with torrent encryption and you have a very nice way to get around your college/work firewall.

      --
      Official Heretic from the "Church of Global Warming". Proven right thanks to whistle blowers. AGW = Flat Earth Theory
  2. Re:Confusing title by Aadain2001 · · Score: 2, Interesting

    No, it is "punching" a hole in the firewall. While NAT transversal is similar to this technique, is works even if you are not using NAT (say, at an office). While it's nothing "ground braking" or really that new, it is (at least to me) interesting and probably is to anyone who isn't a network guru.

    --
    Space for rent, inquire within
  3. STUN? by Darkforge · · Score: 1, Interesting

    Is this just the same thing as STUN (Simple Traversal of UDP through NATs)? The technique described in the article sounds simpler than STUN, but similar in concept. (SIP uses STUN, right?)

    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?

    --

    When I moderate, I only use "-1, Overrated". That way, I never get meta-moderated!

  4. Not exactly new by Wannabe+Code+Monkey · · Score: 3, 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.

    --
    We always knew Comcast was corrupt, here's the proof: http://tech.slashdot.org/comments.pl?sid=1909890&cid=34545432
  5. You can do this with TCP too... by sparr0w · · Score: 5, Interesting

    ... but its a little more tricky. We figured this out during our senior design project (a video communications system) - all we had to do was have the server start a TCP connection to the client over static source and destination ports, trash the connection before reset/fin packets could be sent and then turn a server on the source port. The NAT we were using would then let an incoming connection come on through to the server. With UDP its a whole lot easier, but it still can be done with TCP as well.

  6. Perl code by sheriff_p · · Score: 2, Interesting

    Samy, the guy involved with the MySpace worm, wrote some Perl to do this a while ago:

    http://samy.pl/chownat/

    --
    Score:-1, Funny
  7. Port Scanning by Anonymous Coward · · 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?