If you're running a kernel between 2.x.x and 2.2.x, use:
$ ipautofw -A -r udp 6112 6112 -c tcp 6112
If you're using IPChains (on 2.2.x to 2.4.x) use:
$ ipmasqadm autofw -A -r udp 6112 6112 -c tcp 6112
If you're using IPTables (2.4.x and up) and NAT, there's a couple of commands that work, using SNAT, DNAT and PRE/POSTROUTING. I didn't bother to save them, since I don't run that version of the kernel.
see Masq Apps for other applications/games.
Some important notes: While this will allow you to connect to a Battle.net server, it is not guaranteed to allow you to play. Especially if you create the game. Why? Well, if you create the game, with you private-IP computer, that IP address will be placed somehwre inside the data packets sent by StarCraft. When another client will see these, it will have no idea how to reach you. (I hope I'm being clear: this is not a routing issue. It is an issue with the data format of the StarCraft packets). But if somebody else creates the game, you'll probably be fine. (Assuming they aren't behind a firewall, too).
that last bit thanks to Tod Detre.
Why is that? Because the Battle.net server is nothing more than a phone
directory. It doesn't do anything that allows the players to play, other than
letting them get to know each other. You see, all the Battle.net stuff is
negotiated through TCP, including the host's (the guy who Creates the game)
IP address, port, etc. This data is then used to establish a UDP connection
to the host. From there it gets a little complicated, since the game reverts
to its natural peer-to-peer mode, somehow. (i.e. if the host quits, the game
will continue. I wonder if that will hold true if the host is the only
non-firewalled computer in the game? [evil-grin]). The only thing the
Battle.net server does during the game is send some keep-alive/ping packets
to the client. Possibly for statistics, but more probably just to keep the
TCP connection to Battle.net alive.
thanks to the bnet-masq-howto for that info.
Back to Tech Journal