Starcraft and NAT
Getting Starcraft to work for two people behind NAT
Ed. The symptom that this solves is that when two people are behind the same NAT gateway, they experience lots of lag in the game, and may see high latency in the Battle.net game setup. We work around this by remapping port 6112 at the NAT gateway.
This information is from Jan 18, 2007. (original)
My friend Jason and I have been figuring out how to allow two people behind a single NAT gateway router to play Starcraft through Battle.net. Limited information is found through Google on this topic, and Blizzard offers no help. We each have Linksys WRT54G routers with alternate firmware that supports running iptables. (DD-WRT and HyperWRT Thibor + tofu)
Having two people behind a single NAT gateway router connect to the same Battle.net game typically results in the appearance of lots of lag as the two clients do not communicate with each other. To get around this, the following iptables rules can be inserted on the NAT gateway or router.
In this example 70.100.200.24 is the public IP address for the two people behind the NAT router. 192.168.1.2 is the IP address of one client machine, and 192.168.1.3 is the IP address of the other client machine. On the router, type these commands as root:
iptables -t nat -I PREROUTING -p udp -d 70.100.200.24 --dport 63002 -j DNAT --to-destination 192.168.1.2:6112
iptables -t nat -I POSTROUTING -p udp -s 192.168.1.2 --sport 6112 -j SNAT --to-source 70.100.200.24:63002
iptables -t nat -I PREROUTING -p udp -d 70.100.200.24 --dport 63003 -j DNAT --to-destination 192.168.1.3:6112
iptables -t nat -I POSTROUTING -p udp -s 192.168.1.3 --sport 6112 -j SNAT --to-source 70.100.200.24:63003
The PREROUTING chain entries cause the packets to be sent to the Internet with port 63002 or 63003 rather than the standard port 6112 for Starcraft.
The POSTROUTING chain entries cause the packets to be sent on the LAN. It's important to make sure these are the first rules in their chains. I've seen other instructions that use "-A" rather than "-I" to add the rules, and this does not work for me since there are already some global rules in the chains that will handle the packets. For example, the POSTROUTING chain has a MASQUERADE target for all packets. That causes the local packets to be sent to their destinations with a LAN source address, which will be dropped by the Starcraft client because it is expecting the source address on game packets to be the public IP address.
These iptables rules will not allow one of the local machines to host the game. When we've tried that, some clients were unable to connect, so this is an issue still under some investigation. When we have time, we'll look at the Wireshark captures.
Labels: firewall, games, iptables, NAT, networking, starcraft
posted by John Paul @ 6:47 PM
16 Comments
16 Comments:
You sir, are a hero!
My brother and I have been trying to play Starcraft together over Battle.net for three or four years now, and finally we can kick some ass together. With the announcement of Starcraft 2 we felt like playing starcraft again, now we can with a lot more fun. Thanks again.
hey man thanks for the info, we got sc working after all the sc2 news.
anyways, we are also able to host by forwarding the 6112 to the computer that hosts the game, then everyone else can join
sorry if im not coherent, trying to reply inbetween sc games!
Do I just put the codes in startup scripts?
Do I still have to forward the ports to 63002 now?
You can put the iptables commands in a startup script on your gateway/route assuming it runs Linux and iptables (like the WRT54G does with alternate firmware).
The iptables commands take care of the forwarding that needs to be done at the NAT gateway, but if you have another system in front of that, which is a configuration beyond what these scripts handle, then you may need to forward ports 63002 and 63003, but on a WRT54G system you do not need to forward these ports since that's what the iptables commands already do.
This isn't working for me, we can't see each other type, and it still lags any game we're in together. I've got the script in startup, should the router be reset or something?
If the startup script has not run at all, then the iptables rules will not have been added. If you have a telnet or ssh shell to your router, you should be able to enter the iptables commands there without having to restart your router, but restarting your router might help if that causes the iptables commands to be run. I'm sorry I cannot really debug particular issues; I have to re-learn how to manage iptables every time I deal with it.
Hi, how can I do this with a WPN824 neatgear router? I don't know where to enter the commands. Thanks in advance.
just wondering if you know: why doesn't every router allow people to access root and why must people update to alternative firmware in order to use iptables, if it is useful?
I suggest you post your question of why router firmware is the way it is at Reddit or Slashdot. I do not have an answer.
could you PLEASE give step by step instructions on how to do this on the WRT54G? im looking for where to type those codes but i cant find it. i have been trying to do this for years! please help!
On a WRT54G, you will need first to install an alternate firmware that has some kind of shell access. Check Wikipedia's WRT54G page for links to firmware. I suggest installing the HyperWRT + Thibor firmware since that's what I've used. You can then enable remote shell access daemons on the router (telnetd or sshd) and then telnet (linux and Windows command) or ssh (use Putty on Windows) into the WRT54G and run the iptables commands as root OR put them in the "firewall script" from "Administration->Management->edit firewall script". If you type them in from the login shell, the iptables commands are effective immediately. If you put them in the firewall script, I believe you must restart your router for them to take effect.
I don't see how this could help - if you're already having masquerading on the WAN NIC, this ought to be done for you by automation, but I probably misread the iptables rules.
Feel free to clarify, or ignore my probable misunderstanding.
The problem that these iptables rules solve is that even with NAT and IP masquerading, the Battle.net protocol that the games use is based on UDP, which is connectionless, using only port 6112. If the protocol were TCP rather than UDP, then the NAT gateway would be able to know which incoming packets went to each machine. In fact the normal IP masquerading rules and NAT work just fine for a single computer behind the NAT gateway because there is no ambiguity about which system should receive the incoming packets. As soon as a second machine is added on the local network, the NAT gateway has to determine where it should send the packets, and what gateways do then is usually simply to send the packets to the last system that sent an outgoing packet on the same port.
Note also that Warcraft 3 lets the clients use any port from 6112 to 6119 for the Battle.net UDP traffic, and so one would not need to have these iptables rules on the NAT gateway if one were to configure different ports from the game's network settings. Starcraft does not have this networking option.
This post has been removed by a blog administrator.
This post has been removed by a blog administrator.
Post a Comment
<< Home