Ludic Linux

OpenVPN for Gaming

How I got it set up

I’m no expert, certainly not in networking, so this isn’t so much a HowTo as a HowIDid. I’ll show you how I set up OpenVPN to allow my friends and I to play old ass games that only work on LAN (in our case, Titan Quest and a spot of FlatOut 2, both via Wine in my case, of course). This solution works for games which rely on UDP broadcast (i.e. games where you can’t just enter a direct IP, you have to look for games on the local network).

Preamble

Bear in mind that this approach will expose your entire local network to any clients you invite. They will be able to see any shared resources on your local network — essentialy it’ll be as if they are connected directly to your LAN. This is only for use with friends whom you trust.

You can use any security measures you like, you don’t have to use keys. I’ll be using keys though.

I’ll be using the same keys for all clients. This isn’t generally advised since if one of them leaks their key then, in order to remain secure, you’ll need to revoke and replace the key for everyone. In a big organisation this would be a terrible idea but for a handful of friends I think it’s easier to just have one key for all of them. Which approach you take is up to you.

I used netctl to make the bridge since it seemed simplest. You can use any method you like but I’ll only be covering netctl.

I’m using Arch so examples will be Arch-centric and I’ll be using Systemd to manage services, adjust to taste.

Stuff you’ll need:

  • OpenVPN installed, obviously. It’ll be in your repos.
  • rsa-tools to generate the keys. Again, check your repos.
  • A wired internet connection on the server machine (I believe it’s possible to bridge a wifi connection but it’s more complicated so you’re on your own with that).
  • If the machine you’re going to use as the server has a dynamic external IP then use a dynamic DNS service to get yourself a hostname that people can connect on, otherwise you’re going to have to give your clients new configs every time your IP changes. If you have a static IP then you can just use that if you like.
  • Some friends to test it’s working.
  • Hedgewars — handy for testing. Throw up a LAN game and see if others can see it.

I am the keymaster

We need to make an assload of keys.

I followed these instructions exactly so there’s no point repeating them here, they’re excellent instructions.

The only changes I made were to use server where the example uses elmer and to use client where the example uses bugs. So when generating keys for my server, in the common name field, I used server and when generating the client keys I used client for the common name. If you want to stay matched up with me then do the same.

When you fill in the defaults in the .vars file, just put sensible things in each of the following fields: KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, and KEY_EMAIL.

Follow the instructions using the default values for all fields except when it asks you for common name where you should use server or client as appropriate.

When you’re done, inside the /root/easy-rsa/keys/ directory, you should have (amongst others) the following files:

  • ca.crt
  • client.crt
  • client.key
  • dh2048.pem
  • server.crt
  • server.key
  • ta.key

As root, copy these files to /etc/openvpn/. Copying the client files as well as the server files will allow us to run a client locally to make sure we’ve not done anything catastrophically wrong.

If you mess up the key making process at any point, just run ./clean-all and start again.

OpenVPN server configuration

Before we go any further you should forward UDP port 1194 to the machine you’re going to run the server on. This will vary depending on your router and/or software firewall, I’m sure you know how to forward ports: do that!

We’re going to base our OpenVPN configuration on one of the examples because that sounds like a sensible thing to do. The location of the examples will vary per distro but you want to copy the example called server.conf to /etc/openvnc/. So on Arch that’s:

$ sudo cp /usr/share/openvpn/examples/server.conf /etc/openvpn/server.conf

Now open /etc/openvpn/server.conf (as root) in your favourite text editor. And edit the settings as follows. I’m only going to include the lines I changed; anything not listed here should stay as default.

dev tap0

ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key

dh /etc/openvpn/dh2048.pem

;server 10.8.0.0 255.255.255.0 # i.e. we comment this line out

server-bridge 192.168.1.254 255.255.255.0 192.168.1.100 192.168.1.200

client-to-client

duplicate-cn

tls-auth /etc/openvpn/ta.key 0

user nobody
group nobody

We put the full paths in for the key files to allow for flexibility when testing.

Some of those lines need comments and caveats.

This line…

server-bridge 192.168.1.254 255.255.255.0 192.168.1.100 192.168.1.200

… will vary depending on your network. My router assigns IPs in the 192.168.1.x range. If yours assigns them in the 192.168.0.x range then you’ll want to change that first value to 192.168.0.254. The second value is the netmask which should usually be right as it is and you’ll probably know if it’s not.

The last two numbers are the range of IPs OpenVNC will assign to clients. Adjust these as appropriate. So if your router assigns IPs in 192.168.0.x then you’ll want this line to be:

server-bridge 192.168.0.254 255.255.255.0 192.168.0.100 192.168.0.200

This line…

client-to-client

… allows clients to ‘see’ each other on the network. For gaming you will most likely want this.

This line…

duplicate-cn

… allows multiple clients to connect with the same keys. If you’re going to give each of your clients different keys then you can leave that commented out.

And that’s it. The server configuration is done.

Bridging

We need to create two network devices. The first is the tap0 device that OpenVPN will use and the second is a bridge to connect that tap0 device with our ethernet connection.

There are many ways to do this, I’m using netctl since it seemed simplest. So, as root, create the file /etc/netctl/tuntap and put the following in it:

Description='tuntap connection'
Interface=tap0
Connection=tuntap
Mode='tap'
User='nobody'
Group='nobody'

That one’s straightforward. Now let’s make the bridge device.

Create a file, again as root, at /etc/netctl/bridge and put the following in it:

Description="bridge connection"
Interface=br0
Connection=bridge
BindsToInterfaces=(eth0 tap0)
IP=no
ExecUpPost="ip link set dev br0 address $(cat /sys/class/net/eth0/address); IP=dhcp; ip_set"
ExecDownPre="IP=dhcp"

# # Ignore (R)STP and immediately activate the bridge
SkipForwardingDelay=yes

There are two instances of eth0 there, replace these with the name of your ethernet device which you can find by executing ip link show in a terminal (it will likely be the one that starts with ‘eth’ or ‘en’).

This file could be simpler, what this line…

ExecUpPost="ip link set dev br0 address $(cat /sys/class/net/eth0/address); IP=dhcp; ip_set"

… does is ensures that the bridge has the same MAC address as my ethernet interface which was necessary for port forwarding on my router. If this is not necessary for you then there are simpler examples here.

And that’s the bridge done and ready to go. Just the clients left.

Client config

This is very similar to the server configuration. First copy the example file to /etc/openvpn/ as root like so:

$ sudo cp /usr/share/openvpn/examples/client.conf /etc/openvpn/client.conf

(Again, paths may vary on other distros)

Now edit /etc/openvpn/client.conf as root in your text editor. As before I’ll only include the lines you should change, everything else should remain the same.

dev tap0

remote YOUR_HOSTNAME_OR_IP 1194

user nobody
group nobody

tls-auth ta.key 1

Only one line to adjust here:

remote YOUR_HOSTNAME_OR_IP 1194

Just replace ‘YOUR_HOSTNAME_OR_IP’ with… yeah, your hostname or IP. The one you want your friends to connect to over the internet. So if you’re using dynamic dns and the hostname is hello.noip.com then this line would be:

remote hello.noip.com 1194

If you’re using your IP instead which is 1.2.3.4 then the line would be:

remote 1.2.3.4 1194

Ok, that’s the client config file done.

On Windows, the client.conf file will need to be renamed to client.ovpn so you may as well make a copy now:

$ sudo cp /etc/openvpn/client.conf /etc/openvpn/client.ovpn

You need to send your client files to your clients, how you do this is up to you, I made a zip file which I sent to each of them. The files they need are:

  • ca.crt
  • client.crt
  • client.key
  • client.ovpn on Windows OR client.conf on Linux
  • ta.key

So bundle those files up into a zip file or whatever you like, we’ll come back to what clients should do with them shortly.

Let’s start the server

First we need to bring up the network interfaces that OpenVPN will use, so in a terminal we do:

$ sudo netctl start tuntap
$ sudo netctl start bridge

And then we start OpenVPN itself:

$ sudo systemctl start openvpn@server

(This assumes you called your server configuration file server.conf like I did. If you called it myserver.conf instead then this command would be sudo systemctl start openvpn@myserver)

To stop these services just issue the same commands with stop instead of start. If you want it so that it all happens automatically at boot then issue the same commands with enable instead of start.

And that’s it, the server should be running. You can use ip link show to check those interfaces are there if you like.

Here’s a link to my configs in case they might be helpful.

Connecting clients

You’ve distributed those client files to your clients as described above and they’re ready to go. Here’s what they do.

On Linux

They just need install OpenVPN from their repos and put all the files you gave them in /etc/openvpn/. Then they can do:

$ sudo systemctl start openvpn@client

And they should be connected. Since you already have those files in place you can issue that command to see if it works. It won’t be very meaningful since you’ll just be connecting to a LAN you’re already on. If you want to see whether you’re successfully connected, do:

$ sudo cat /etc/openvpn/openvpn-status.log

That’ll show any connected clients.

On Windows

Windows users need to install the OpenVPN client. Once that’s done, they need to navigate to the program’s install directory and then put the files you gave them inside the config folder. So their config folder, when things are set up correctly, should contain the following:

  • ca.crt
  • client.crt
  • client.key
  • client.ovpn
  • ta.key

They then need to run the OpenVPN client which will put an icon in their system tray. Then, if things are set up correctly, if they right click on the system tray icon, they should have the option to connect, which they should click.

They should then connect.

You can test for a successful connection by getting them to ping an IP on your internal network, such as your own machine, and you can try pinging the IP that OpenVPN assigned to them.

If that works then throw up a LAN game of Hedgewars and see if they can see it.

Further stuff

Metrics on Windows

Windows clients may need to mess around with metrics in order to see games. I’m not sure this is necessary; I got my friends to do this before I hit on the working solution. So here it is just in case.

In Windows 7 (should be very similar on other Windowses) open the start menu and enter:

ncpa.cpl

In the search box. Press enter.

Click on Change adapter settings on the left, this should bring up a list of network interfaces. Choose the OpenVPN one, right click it and select Properties.

On the properties window, in the box in the middle, first of all deselect/disable Internet Protocol Version 6 since this is useless to us for gaming.

Now highlight the Internet Protocol Version 4 entry and click on the Properties button lower down.

On the next Window, click on the Advanced button near the bottom.

Finally we’re there. Windows instructions are absurd.

Ok, so on this window, near the bottom, untick Automatic metric if it’s ticked and then enter 5 in the Interface metric field.

Now OK your way back out of everything. This may need a reboot to take effect, who knows; it’s Windows.

MTU Stuff

You may want to mess around with the MTU size which may or may not improve performance in certain situations. I did it and noticed a minor reduction in pings. I did exactly what this section of the wiki told me to so there’s no point repeating the instructions.

Cesi n’est pas une LAN

I have no idea whether LAN is masculine or feminine.

As I said up top, I am not an expert as I hope was evident in my writing. I just stumbled, after a lot of fumbling around, on something that works. If you have any technical questions, please don’t ask me; I won’t know the answers. Ask some people who might know instead.

If you have any corrections or improvements to my instructions then please do tell me. Either email me via the link up top or do a pull request on the repo (also up top), whichever you prefer.

Once I’d got my config up and running I decided to copy it over to my Raspberry Pi rather than use my desktop PC. That way it’s always available, whether my PC’s on or not. The RPi handles it fine alongside its day-to-day task of being a little media server. It’s a pretty cool thing to do with a Pi you have lying around.

Again, here’s a link to my configs in case they might be helpful.

And lastly, here we are, me and my friends playing Titan Quest by harnessing the vast power of Linux, OpenVPN, the Arch Wiki and (in my case) Wine.

Yeah, we all chose the same gender and tunic colour. How embarassing.

Articles are copyright of their respective authors and are licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.