OpenVPN + NAT + PvPGN = DotA from home :D

Posted on: Sun, 09/17/2006 - 00:15 By: dae
Tags

UPDATED!!! More recent summarize and route setting can be found here.

The situation is that, our lab network is behind firewall, only a few ports/protocol are permitted. In fact, the entire network in CU has a firewall. Moreover, our network is sectioned such that ppl in the different rooms will be under different subnet. Hence, LAN game is not possible.

The problem: let me play DotA with my friend living not in our room. subproblem 1a: let me play DotA with my friend living not in our room but in CU. subproblem 1b: let me play DotA with my friend living outside CU.

Sol 1: Goes for public PvPGN Status: Failed... 1a is solved. Since battle.net is just a chat room and game browsing mechanism. Once the game is created, it is listed on the battle.net (PvPGN, in our case). After that, any connection is made directly to the creator machine. In this case, that machine is inside Chula where most faculty do not apply any special firewall. But there still exists some problems. Our network is so damn slow and it is very hard to login to any PvPGN.

This solution is not OK for 1b. Even though WCIII allows us to choose any arbitrary high port, The protocol itself required UDP communication, which is blocked.

Sol 2: Use our own PvPGN Status: Failed.... solve the sub problem of 1a. Since it is our own machine and it resides in the same network, we face no lag. However, 1b remains unsolved. Ppl outside CU can't even login to the PvPGN.

Sol 3: Zero Config VPN Status: Failed.... We choose Hamachi. Hoping that it will create a virtual LAN for us. However, Hamachi does not work inside CU. So, this one also failed.

Sol 4:OpenVPN Status: Very promising... but failed... OpenVPN is highly configurable. It allows us to use either TCP or UDP and any port of our choice. We can create VPN from everywhere. However, everybody has to use OpenVPN and OpenVPN is damn hard to config for those who ain't familiar with command line. This one is not so user friendly. It is best if we can require only the ppl outside CU to use OpenVPN while the rest should do anything they like.

Sol 5: OpenVPN + PvPGN Status: Failed... Instead of going for a LAN game over virtual network, this choice combine the previous solutions. However, it still ain't work. With OpenVPN running on the same machine of PvPGN, ppl outside CU can login to the PvPGN and see the list of the games. Unfortunately, they cannot join since the game traffic still travels in the public internet.

Sol 6:OpenVPN + PvPGN + NAT Status: Work!!! This one finally work. The solution is that we must redirect the traffic from ppl outside CU to the game creator machine to travel via VPN. So there are basically two things to do

  • (1) Make the OpenVPN machine to become a NAT server
  • (2) Change the rounting of the outside machine.

To do task (1), it is very simple. Just executing these commands (as root, of course).

echo 1 > /proc/sys/net/ipv4/ip_forward
http://openvpn.net/howto.html#examples

The problem (2) can be done also by using the route command in WinXP

route ADD x.x.x.x MASK y.y.y.y z.z.z.z 

where x.x.x.x is the creator machine (or network) and y.y.y.y is the subnet mask while z.z.z.z is the gateway. In our case, it is the OpenVPN gateway side. We can check this by running

route PRINT

Finally, (2) can be done directly from the config file of openVPN client, by adding a line

route x.x.x.x y.y.y.y

and OpenVPN will determine the rest for you.

A special care should be taken with this route command. Do not route the entire LAB network since it will route the connection to the OpenVPN machine via itself. In other words, you should not add any routing that covers the OpenVPN machine.

UPDATED!!! More recent summarize and route setting can be found here.