Firewalls 101

Punching holes
No, they don’t go all naughty and hack your machine – they don’t have to touch your firewall at all. In fact, they actually do everything by the book.

Both Hamachi and Skype rely on the User Datagram Protocol, or UDP, for sending volumes of data. UDP is a great protocol for things like games and streaming audio because it’s fast and fault tolerant – packets can go missing and it doesn’t matter.

By using UDP it’s possible to bypass a firewall. The process even has a name, UDP hole punching. Keeping in mind the boffins at Hamachi and Skype haven’t revealed all their tricks, we do know that UDP hole punching is used to set up connections between peers. The question is: How do they bypass the firewall?

The key is the behaviour of a stateful firewall to allow incoming connections that were first initiated by outgoing communication. So, let’s take two client machines using Hamachi by way of example. We’ll call them ‘Logan’ and ‘Craig’.

Craig sends a vitally important IM to Logan – ‘I’m gonna pwn your ass in CoH. And get a haircut’. Logan responds eloquently in kind with ‘Bring it on, girly man. And you first’. Naturally, the game is on. They both fire up Hamachi to create a VPN for Company of Heroes.

When Hamachi is launched, it logs you onto the central Hamachi servers and, in doing so, passes on your relevant network data – IP primarily, but also a preferred UDP port. At some stage, the Hamachi client is going to confirm with the server that a particular port is accessible (though communicating to the server with it), and this will be stored.

With both of them logged in, Logan selects to connect to Craig, and in doing so the Hamachi server swaps network data with the clients. Logan now has Craig’s IP address and an accessible UDP port, and vice versa.

But this doesn’t mean the machines can talk just yet. Remember any connection from Logan to Craig will be dropped by Craig’s firewall, because it’s foreign and doesn’t match up to any previously initiated connection.

Which is exactly what happens – Logan sends a packet to Craig’s machine on the IP address UDP port given by the Hamachi server, and Craig’s firewall drops it. But now Logan’s machine has opened a connection to Craig’s IP and port, and so the firewall is open to accepting a response from that same IP address and port. Essentially, Logan has punched a hole in his own firewall.

Thanks to the Hamachi server, Craig’s machine has Logan’s IP and the UDP port it used to try to connect to him. So now Craig initiates a connection to Logan, which because Logan’s machine is anticipating a response to its earlier sent packet, is allowed through.

The two machines now have a direct peer-to-peer direct connection and the Hamachi server (at least for UDP traffic) is taken out of the loop. This leaves Logan and Craig free to fire up Company of Heroes and go on to demonstrate new levels of pwnage on each other. Just who exactly would win depends on who’s editing this line before it goes to print.

So, in summary, the two machines manage a direct connection bypassing their firewalls by taking advantage of the stateful nature of modern firewalls, tricking them into accepting connections from a source they didn’t initially contact.

The real world
Obviously there are some caveats with UDP hole punching. The mechanism relies on UDP traffic, so any firewall blocking UDP prevents this loophole being used – but then, if UDP is blocked, you wouldn’t be able to use software like Hamachi and Skype anyway.

Next, if clients are having a hard time trying to connect (perhaps limited ports are available on a restrictive firewall), the central servers can act as a relay – the software will still work, but it will be slower and with greater overheads.

Finally, it does require a mediating server to work. If the Hamachi or Skype servers aren’t up or accessible at the time a connection is made, no peer-to-peer connection can be established.

Still, all these conditions being met, UDP hole punching is a clean (if unsecure) means of bypassing firewalls.

Logan initiates a UDP connection to Craig at 192.168.1.1 on port 1337. Because it’s an outgoing connection, Logan’s firewall allows it through. Craig, however, doesn’t recognise the source of the data, and drops it.

Craig, armed with Logan’s network information, initiates a connection to 10.1.1.1 port 7331. Because Logan’s firewall is expecting a response to come into port 7331 from a source of 192.168.1.1 port 1337, it allows Craig’s data through, and the two machines talk to each other. It’s important to note if the source or destination ports are different, the packets would be dropped. This is why a central server is needed to confirm on each client the IP and ports that will be used to connect.