Linux Firewalls and WoW

Like most geeks I have the, somewhat unfortunate, habit of making my computing environment a bit more complicated than probably needs to be for most use cases.

A bit of explanation: at home we have the link from Telkom coming in to a DSL Router (with a built-in firewall) connecting via the DMZ to the Bastion Host and from there on into the internal network; all of the machines which have personal firewalls enabled.

The firewalls mostly block incoming traffic since

  1. We tend to run Linux or Mac OS-X internally so we’re more… resilient?… to virus attacks
  2. I’m trying to protect my machines, not the internet (Socially irresponsible? Maybe. Do I care? No.)

So yes, I’m being paranoid; but probably not paranoid enough.

What’s the point of all this, you may ask. What a brilliant question I will exclaim; then go on to explain:

Blizzard’s WoW needs to periodically download some fairly large patches (the last one weighing in at a CD’s worth of 653Mb) and—as may be guessed—this tends to take a while.

One of the ways to speed up the download is to enable “Peer-to-Peer” transfer, which cunningly uses the Bittorrent protocol to allow download not only Blizzard’s site but also from others logically closer to you; while at the same time allowing yet more people to also download sections from you.

All very clever; however… I think I may have mentioned these multiple little firewalls between my li’l Mac Mini and the big bad Internet? So, what to do? Once again, a very astute question!

The WoW site is next to useless unless you use a single hardware firewall or, even more harrowing, you use Windows as your firewall (An exceptionally bad bad idea). The help files certainly does nothing for you if you use multiple firewalls!

So herewith an overview of tunnelling Bittorrent through multiple firewalls to your destination host.

Since we’ve already established that I’m somewhat paranoid, we’ll start with the internal Linux firewall.

Netfilter/IPTables, the default Linux 2.4/2.6 firewall, is a Stateful Firewall, so it makes the configuration a boat-load easier.

Okay, I’ll get to the point.

IPTables can be seen as table of “chains” (hence the name) and each chain defines a rule-set. When a packet comes in on an interface IPTables start by deciding whether the packet is inbound for the firewall itself, or destined for another host beyond the box, and based on that, either apply the INPUT or FORWARD chain in the *filter table.

Conversely, of course, traffic originating on the firewall will be bound by the OUTPUT chain.

If you add to the mix the existence if a private IP address space (and who wouldn’t; not too many of us have access to officially allocated IPv4 addresses we can use with wild abandon) the packet will also then have to be managed by the *nat table. Fortunately I didn’t need to bring QoS into the equation, this can be hairy enough as it is already.

In the *nat table you need to use the PREROUTING chain inbound, as well as the normal OUTPUT chain with it’s link to the built-in MASQUERADE target.

What does this all mean, you ask? Well, this means that a Bittorrent packet hitting the external interface of the firewall needs to be forwarded to the relevant client. To do that you need to both allow it through the FORWARDing chain and then, in the PREROUTING chain, use the DNAT target with the --to-destination argument pointing to the client.

By way of example: My firewall has two interfaces: eth0 is 192.168.0.254 in the DMZ and eth1 is 192.168.128.1 on the client network. This means that I need the following rules in Netfilter:

*filter
:Forward-Only - [0:0]
-A Forward-Only -i eth0 -m state --state NEW -m tcp -p tcp \
    --dport 6881:6999 -j ACCEPT

*nat
:PREROUTING ACCEPT
-A PREROUTING -i eth0 -p tcp --dport 6881:6999 -j DNAT \
    --to-destination 192.168.128.128

Forward-Only is a chain I’ve defined to be called from the FORWARD chain: Own defined chains allows you to easily (relatively) build robust firewall without worrying yourself to death about the niggley details or compromising security.

With this the packet hitting the firewall will be forwarded to the client, now we just need to ensure the packet actually gets to the firewall.

Most DSL Router have built-in firewalls, and since they all differ at best I can offer some generalities.

The basic principle of configuration is the same as the firewall: Accept a packet on the external interface and then forward it on to the client; just in this case the client will be the internal Firewall. The reason for this is that most decent DSL Routers contain an embedded Linux Kernel so they use the same type of Firewall, but hidden behind some sort of Web-GUI.

In doing this you may have to define a Bittorrent service (if this has not been predefined) which contains the 6881:6999 TCP port range.

The last element is, of course, the client. Here you truly are on your own. With a Linux client you just need to add the Bittorrent ports to the INPUT chain in the *filter table, and on Mac OS-X you need to go to System Preferences -> Sharing -> Firewall -> New and create the service. On Windows? I have absolutely no idea…

In the specific case of WoW, you also need to open ports 3724 and 6112, in addition to the ones mentioned, but that is merely more of the same…

Blizzard has a fairly decent article on their site that covers much the same I did, with the exception of the assumption of single (DSL Router based) firewalls. They do cover personal firewalls for Windows in fair depth, I just couldn’t be bothered to look since I don’t care for Windows much.

Leave a Reply

Your browser is out-of-date!

Update your browser to view this website correctly.Update my browser now

×