Emaculation.com

This is an old revision of the document!


Bridged OpenVPN Server Setup

<html> <span style=“color:red;font-size:150%;”>THIS GUIDE IS UNDER RENOVATION FOR USE WITH DEBIAN 8 AND UBUNTU 15.04. DON'T USE IT UNTIL THIS NOTICE HAS BEEN REMOVED!</span> </html>

(Last updated May 5, 2015. The forum thread is here.)

Introduction

This guide describes how to set up a bridge-mode OpenVPN server in a VirtualBox Linux virtual machine (VM). These instructions are intended for home users who wish to run the VM on a Mac or Windows PC. We'll use only free and open-source software, but other virtualization software such as Parallels or VMware can be used instead. This guide may look long and intimidating, but that's only because many of the steps are spelled out in detail so that it can be as beginner-friendly as possible. A lot just involves copying and pasting. You don't need to read the appendices unless you're interested in their specific topics.

An OpenVPN server in a bridged configuration creates a virtual private network (VPN) that can be thought of as a virtual Ethernet switch to your network. It allows people you trust to make a virtual Ethernet connection to your LAN from over the Internet. Therefore, people that connect, called clients, are able to send and receive all the same data that they could if they were physically connected to your LAN by Ethernet, while still maintaining their own normal LAN and Internet connections. Traffic going to and from the clients is tunneled over a single UDP port. This means that local traffic of any protocol (TCP, UDP, AppleTalk, IPX, etc.), including broadcasts, will be sent over that UDP port. All data over the VPN connection is encrypted and compressed.

Possible uses of this VPN include:

  • Accessing typical LAN services such as file sharing and printers
  • Accessing services that rely on broadcasts or mulitcasts such as Apple's Bonjour
  • Playing LAN games over the Internet
  • Easily sharing the VPN connection with virtual machines and emulators
  • Using non-IP protocols such as AppleTalk or IPX over wireless or over the Internet
  • Networking virtual machines and emulators with old computers that use such non-IP protocols natively

We refer to the LAN on which the OpenVPN server is running as the “server side” of the VPN. We refer to wherever the client connects from as the “client side” of the VPN. Only the individual clients connecting via VPN will be connected to the server side. No other machines on the client side will be connected to the server side.

The computer on which you want to run the OpenVPN server must be wired to your router by Ethernet, and you must have the ability to forward a UDP port. The IANA port number for OpenVPN is port 1194, but you can use any free port you want. Clients can use wireless or Ethernet and do not need to forward any ports.

Using a Unique Subnet

If you're going to run a VPN server on your home network, I highly recommend that you change your private IP subnet to some uncommon numbering, i.e., not 0 or 1 in the third octet. The third octet is x.x.this.x number of the IP address. Your router software should be able to accomplish this. With my Apple AirPort Extreme, using AirPort Utility, I can change the number of the third octet, and the AirPort simply reassigns the DHCP-given addresses and changes the existing DHCP reservations and port mappings (forwardings) appropriately. Machines using static IP addresses will have to be changed manually on the respective machines. I can also change between 10.0.x.x, 172.16.x.x and 192.168.x.x numbering schemes. Using a unique subnet is important because many services require that clients enter the IP address of the host. If there are conflicting (identical) private IP addresses on both the server side and client sides, then things can't be expected to work. So, for example, a numbering such as 10.0.149.x or 192.168.37.x should be fine.

To be clear, only the server's network has to worry about having a different subnet numbering than the numberings of each of the clients. The clients can't see each other's LANs, so their comparative numberings don't matter. Clients can see only each other's OpenVPN-assigned private IP addresses in addition to the machines on the server side.

Linux VM Setup

This section provides a procedure for setting up a simple Debian 8 “Jessie” VM for beginners. If you already have your Linux machine set up, then proceed to the OpenVPN Server Setup section. Note that, to run an OpenVPN server, a virtual machine's virtual network adapter must be in a bridged configuration.

VM Settings

Download the Debian network installer disc image from the upper right of the Debian home page.

Download and install VirtualBox. In VirtualBox, create a new VM with the following settings:

Name and operating system:
Name: Debian (or whatever you want)
Type: Linux
Version: Debian (64 bit) if you have a 64-bit host, (32 bit) otherwise

Allocate at least 768 MB of memory, and choose the default hard drive settings. In the newly created VM's settings, set:

General > Advanced:
Shared Clipboard: Bidirectional
Drag'n'Drop: Bidirectional

Network > Adapter 1:
Attached to: Bridged Adapter
Name: select your Ethernet interface/adapter
Under Advanced, Promiscuous Mode: Allow All

Shared Folders:
Add a shared folder to the host OS, and check Auto-mount. This setup assumes that you added a shared folder named “linuxshared”.

All other settings can be left as their defaults.

Debian Installation

Start the VM, point the window that pops up to your Debian disc image, and hit Start. Use the arrow keys to select “Install” on a 32-bit host, or “64 bit install” on a 64-bit host. The installer program proceeds as follows:

Select your language, location and keyboard configuration.

For the hostname, the default “debian” is okay. For the domain name, you can enter anything if your ISP's domain name wasn't detected automatically.

Enter and verity a root password.

Enter the user's name. This is not the username.

Enter a username.

Enter and verify a user password. For the purposes of this VM, it's simplest to make this the same as the root password.

Select your time zone.

Select the default choice on the “Partition disks” screens. Hit tab and enter to select “Yes” when it asks whether to write changes to disk.

Select your country for the Debian archive mirror, and the default choice for the archive mirror URL. Leave the HTTP proxy information blank.

Choose whether you want to participate in the package usage survey.

Use the space bar to select only “SSH server” and “standard system utilities,” then hit enter.

Select “Yes” to install the GRUB boot loader, and choose the /dev/sda device.

When the installation is complete, ensure that the Debian disc image is no longer connected to the VM (no check mark) under the VM's Devices > CD/DVD Devices menu, then select “Continue.” The VM will reboot into the newly installed Debian.

At the “debian login:” prompt, enter

root

followed by the root password. Enter

apt-get install gnome-core xorg

to install a basic graphical user interface (GUI). Enter Y to continue.

When the prompt returns, reboot the VM by entering

reboot

The VM will reboot into the newly installed GUI. Select the user. Click on the small gear icon next to the “Sign In” button and select “GNOME Classic.” Enter the user password.

Go to Applications > Utilities, and scroll down to select Terminal. You will not yet be able to copy and paste into the VM since Guest Additions are not yet installed. Become root by entering

su

followed by the root password. Enter

apt-get install gcc make linux-headers-$(uname -r)

Select “Insert Guest Additions CD image…” in the VM's Devices menu. Select Cancel on the window that pops up. Open Terminal, become root, and enter

umount /media/cdrom
mount -o exec /media/cdrom
/media/cdrom/VBoxLinuxAdditions.run

Reboot the VM by entering

reboot

Open Terminal and enter

ls /media

The shared folder “linuxshared” should now be visible as “sf_linuxshared”. Also, you will now have the ability to copy and paste into the VM. The keyboard command for pasting into the Linux terminal is shift+control+V, as seen in the terminal's Edit menu.

Note that the command to shut down the VM as root is

shutdown -h now

OpenVPN Server Setup

The instructions in this section can be used for running OpenVPN 2.3 in Debian 8 (proceeding from the VM setup above) or Ubuntu 15.04 (uses systemd).

Authentication Setup with Easy-RSA

Open Terminal, and become root. Install OpenVPN, Easy-RSA and the Linux Ethernet bridge utilities:

apt-get install openvpn easy-rsa bridge-utils

Copy Easy-RSA to OpenVPN's directory:

cp -r /usr/share/easy-rsa /etc/openvpn

Now we'll make the credentials (certificates and keys) for OpenVPN authentication. Go to Easy-RSA's directory:

cd /etc/openvpn/easy-rsa

Enter

source vars

followed by

./clean-all

The one important field for the following commands is “Common Name”. If you mess up an entry for the following commands, you can hit control+C and re-enter the command.

Create a Certificate Authority (CA) by entering

./build-ca

For Common Name, enter “OpenVPN-CA”. No entry is required for the other fields. Hit return to proceed through the entries. This will look like:

Country Name (2 letter code) [US]:
State or Province Name (full name) [CA]:
Locality Name (eg, city) [SanFrancisco]:
Organization Name (eg, company) [Fort-Funston]:
Organizational Unit Name (eg, section) [changeme]:
Common Name (eg, your name or your server's hostname) [changeme]:OpenVPN-CA
Name [changeme]:
Email Address [mail@host.domain]:

Create the server credentials by entering

./build-key-server server

The Common Name will be set to “server” by default, so no entries are required. This will look like:

Country Name (2 letter code) [US]:
State or Province Name (full name) [CA]:
Locality Name (eg, city) [SanFrancisco]:
Organization Name (eg, company) [Fort-Funston]:
Organizational Unit Name (eg, section) [changeme]:
Common Name (eg, your name or your server's hostname) [server]:
Name [changeme]:
Email Address [mail@host.domain]:

Just hit return to skip the challenge password and company name, and enter Y to sign the certificate and commit.

Generate Diffie-Hellman parameters by entering

./build-dh

Now we'll create the client credentials. Each client must have a unique Common Name. As long as you build each key using a different word, the Common Name indeed will be unique.

To create credentials for a client called “joe”, enter

./build-key joe

The Common Name will be set to “joe” by default, so no entries are required. This will look like:

Country Name (2 letter code) [US]:
State or Province Name (full name) [CA]:
Locality Name (eg, city) [SanFrancisco]:
Organization Name (eg, company) [Fort-Funston]:
Organizational Unit Name (eg, section) [changeme]:
Common Name (eg, your name or your server's hostname) [joe]:
Name [changeme]:
Email Address [mail@host.domain]:

Again, hit return to skip the challenge password and company name, and enter Y to sign the certificate and commit. You can make more client credentials now, say,

./build-key jane

IMPORTANT: If you ever come back later to /etc/openvpn/easy-rsa to create credentials for additional clients, you must enter “source vars” before running “./build-key jane”.

The CA certificate and client certificates and keys will be given to the clients. For now, copy the keys folder to the host OS via the shared folder by entering

cp -r /etc/openvpn/easy-rsa/keys /media/sf_linuxshared

More information on Easy-RSA, including information on revoking client certificates, can be found at OpenVPN's HOWTO page.

VPN Setup

Now we'll configure the OpenVPN server. First, you must obtain some information about your network's private IP address numbering.

On an OS X host, open System Preferences and go to Network. On the left, select the active interface (Ethernet), click “Advanced…” and select the “TCP/IP” tab. Look for the values for Subnet Mask (netmask) and Router. On a Windows host, this information can be obtained by running the command “ipconfig” (without quotes) in the Windows command prompt, cmd.exe. “Default Gateway” is the router's address. You will also need to know your broadcast address, which is simply the first three octets of your subnet plus 255. Finally, decide on a free IP address on your network, which will be assigned to the Linux VM.

This guide will use the following example private IP address numbering (adjust this to your numbering):

Free IP address for Linux VM: 192.168.5.100
Netmask: 255.255.255.0
Broadcast address: 192.168.5.255
Router's IP address: 192.168.5.1

We'll use the text editor “nano” to create a script called “openvpn-bridge” that performs the Ethernet bridging. Enter

nano /etc/openvpn/openvpn-bridge

Copy and paste the following script into that (empty) file.

#!/bin/sh

# Define Bridge Interface
br="br0"

# Define list of TAP interfaces to be bridged,
# for example tap="tap0 tap1 tap2".
tap="tap0"

# Define physical ethernet interface to be bridged
# with TAP interface(s) above.
eth="eth0"
eth_ip="192.168.5.100"
eth_netmask="255.255.255.0"
eth_broadcast="192.168.5.255"
eth_gateway="192.168.5.1"

case "$1" in
start)
    for t in $tap; do
        openvpn --mktun --dev $t
    done

    brctl addbr $br
    brctl addif $br $eth

    for t in $tap; do
        brctl addif $br $t
    done

    for t in $tap; do
        ifconfig $t 0.0.0.0 promisc up
    done

    sleep 10

    ifconfig $eth 0.0.0.0 promisc up

    ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast

    route add default gw $eth_gateway
    ;;
stop)
    ifconfig $br down
    brctl delbr $br

    for t in $tap; do
        openvpn --rmtun --dev $t
    done

    ifconfig $eth $eth_ip netmask $eth_netmask broadcast $eth_broadcast

    route add default gw $eth_gateway
    ;;
*)
    echo "Usage:  openvpn-bridge {start|stop}"
    exit 1
    ;;
esac
exit 0

Use the arrow keys to edit the script. Edit the four lines beginning with eth_ip, eth_netmask, eth_broadcast and eth_gateway. Those four variables must be set equal to the free IP address for the Linux VM, netmask, broadcast address and router's IP address, respectively, in quotes as shown. Edit only those four lines. Press control+X, then Y to accept changes, and return to save the file. Entering “ls” should now show the file “openvpn-bridge” in the list of files in the directory. If you need to edit the script again, enter the same command above used to create it.

The duration of the “sleep” command may need to be increased for slow hard drives. If, in the future, there is no Internet connection in the VM after booting (ping google.com from the Linux terminal, for example), then try increasing the sleep command. My Ubuntu VM needed “sleep 20” to be reliable, but “sleep 10” worked fine for my Debian VM.

This script is adapted from the “bridge-start” and “bridge-stop” scripts at OpenVPN's Ethernet bridging page. It bridges the Ethernet interface, eth0, and OpenVPN's TAP interface, tap0, as members of the bridge interface, br0. It also sets the Linux VM's private IP address to the free address that you chose, effectively giving the server a static IP address.

Make the script executable by entering

chmod 744 /etc/openvpn/openvpn-bridge

Now we'll create the server configuration file. Enter

nano /etc/openvpn/server.conf

Copy and paste the following text:

port 1194
proto udp
dev tap0
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
remote-cert-tls client
server-bridge 192.168.5.100 255.255.255.0 192.168.5.101 192.168.5.110
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
status /var/log/openvpn-status.log
log-append /var/log/openvpn.log
verb 3

The line around the middle that begins “server-bridge” must be changed to match your private IP addresses. Set the first and second addresses of that line to the free IP address for the Linux VM and your netmask, respectively. The third and fourth addresses of that line denote the private IP address range to be allocated to clients. This must be set to an unused address range on your network. This range ideally should be outside your router's DHCP range, but it doesn't need to be. As can be seen, in this example, ten addresses are allocated, ending with 101 through 110. More information on the server configuration file can be found at OpenVPN's HOWTO page and the OpenVPN 2.3 manual.

Port Forwarding

Putting the VM aside for a bit, in your router's settings, you need to forward OpenVPN's port to the Linux VM's private IP address. The port chosen in this example, in server.conf above, is UDP port 1194, the default for OpenVPN. Therefore, for this example, we would forward public and private (external and internal) UDP port 1194 to the private IP address 192.168.5.100.

Final Settings in the VM

We need to tell OpenVPN to make use of our “openvpn-bridge” script. First, copy the following two lines:

ExecStartPre=/etc/openvpn/openvpn-bridge start
ExecStopPost=/etc/openvpn/openvpn-bridge stop

Enter

nano /lib/systemd/system/openvpn@.service

Paste the two lines at the bottom of the [Service] section so that its last three lines look like

WorkingDirectory=/etc/openvpn
ExecStartPre=/etc/openvpn/openvpn-bridge start
ExecStopPost=/etc/openvpn/openvpn-bridge stop

Exit and save. Reboot the VM by entering

reboot

The OpenVPN server will be running at boot, i.e., no user login is required.

Basic Testing

Verify that the br0 and tap0 interfaces are up by entering

ifconfig

When the OpenVPN server is running, the br0 interface will have the IP address that you chose for the Linux VM.

Check the OpenVPN server status by entering

service openvpn status

Stop the OpenVPN server by entering

service openvpn stop

Entering “ifconfig” again should show the network interfaces back to normal (no br0 or tap0), with the eth0 interface now having the IP address.

Start or restart the OpenVPN server by using “start” or “restart” instead of “stop” in the command above. Note that the startup process will take approximately as long as the duration of the “sleep” command in the “openvpn-bridge” script. Again, the OpenVPN server will always start at boot.

OpenVPN Client Setup

Client Configuration

Create a plain text file in a program such as TextEdit in OS X or Notepad in Windows. For the client “joe”, copy and paste into that file the following text:

client
dev tap0
proto udp
remote PUBLIC_IP_ADDRESS 1194
persist-key
persist-tun
ca ca.crt
cert joe.crt
key joe.key
remote-cert-tls server
comp-lzo
verb 3

PUBLIC_IP_ADDRESS must be replaced with the public IP address of the server side. Google “what's my ip” on the server side to get this address. A client already on the server side could use the private IP address of the Linux VM instead of the public IP address. Tunneling non-IP protocols, such as AppleTalk and IPX, over wireless is one reason to do this. Clients over the Internet must use the public IP address.

The “cert” and “key” lines must be changed to match the file names of the .crt and .key files for any given client. Save the file as “joe.conf”, and give ca.crt, joe.crt, joe.key and joe.conf to the client. Zipping them together is easiest.

More information on the client configuration file can be found at OpenVPN's HOWTO page and the OpenVPN 2.3 manual.

Mac Client Software: Tunnelblick

For OS X clients, use Tunnelblick. Be sure to get the correct version for your version of OS X, which could be the beta release. When it asks for configuration files after you install it, just quit. Tunnelblick uses files with a “.tblk” extension. For the client “joe”, place the files ca.crt, joe.crt, joe.key and joe.conf into a folder called whatever you want to call that VPN connection, say, “Home VPN.tblk”. Double-click that file to add it to Tunnelblick's list of connections. Tunnelblick appears at the right side of the menu bar as a tunnel icon. Go to “VPN Details…”, select the connection on the left, and set “Set DNS/WINS” to “Do not set nameserver”. Select “Advanced…”, and under “Connecting & Disconnecting,” uncheck “Check if the apparent public IP address changed after connecting,” since this is unnecessary for this type of setup (the public IP address will not change). Exit the menus. With the OpenVPN server running, click the tunnel icon, and connect.

To get back to the individual client files, right-click on the .tblk file and select “Show Package Contents.” If you want to change any of the client files, you must reload (double-click) the .tblk file again after making the changes. However, to quickly change the client configuration file without having to reload, go to “VPN Details…”, highlight the connection in the list on the left, click the gear icon below the list and select “Edit OpenVPN Configuration File.” The client doesn't need to keep the client files after the configuration is created.

Windows Client Software: Securepoint OpenVPN Client

For Windows clients, the Windows version of OpenVPN can be used, but I recommend the Securepoint OpenVPN Client, which is very easy to use. When installing, select “Mangagement” for the starting context. Select Yes for saving user credentials. Run the desktop shortcut, right-click the shield icon in the taskbar and select “Show profiles”. Click “New” and give the VPN connection a name. Enter the public IP address of the server, port (1194) and protocol (UDP). For the client “joe”, point “Root CA” to ca.crt, “Certificate” to joe.crt, and “Key” to joe.key. Leave “Server certificate” unchecked. Click Next, Next and Finish. Open joe.conf (with WordPad if it was written in OS X or Linux), select all, and copy. In Securepoint, right-click on the VPN connection's name, select “Quick edit”, delete everything, and paste. Now you can connect. The client doesn't need to keep the client files after the configuration is created.

The program runs in German when not run with the shortcut. If you ever accidentally delete the desktop shortcut, then use the following arguments in the Properties > Target field of a shortcut to “Spvpncl.exe”

-manage -enableSaveData -useEnglish

to enable management, saving user credentials, and English, respectively.

Broadcasts in Windows

In Windows, broadcasts may not work by default for OpenVPN's TAP adapter. To get broadcasts working over the VPN, the metric for the TAP adapter must be lowered so that it gets highest priority. This post explains how this works. In short:

Open Network and Sharing Center > Change adapter settings > right-click on TAP adapter > Properties > select “Internet Protocol Version 4 (TCP/IPv4)” > Properties > Advanced… > uncheck “Automatic metric” and type “1” (without quotes) for “Interface metric” > OK out of everything

Uninstall unused TAP adapters under Device Manager > Network adapters.

Troubleshooting

If a remote client can't connect to the server, try to connect a computer on the server side using the Linux VM's private IP address instead of the public IP address in the client configuration file. If you still can't connect, this probably means that there's a problem in the Linux VM since the router's public port forwarding rule is taken out of the equation.

To test whether the client's request to connect is reaching the VM, use tcpdump in the VM. Install tcpdump as root in Terminal:

apt-get install tcpdump

To listen, for example, for packets passing through the br0 interface on port 1194 (both TCP and UPD), enter

tcpdump -ni br0 port 1194

If a client connects successfully, the list of packets will increase very quickly. If not, there will be very little activity. That indicates that there could be a problem with the router's port forwarding rule.

Using software firewalls may cause issues. Firewall exceptions probably will have to be made for the client software and/or the TAP interface/adapter. A machine on the server side should be able to ping a successfully connected client using the client's OpenVPN-assigned IP address. If the client is connected but the ping is unsuccessful, then chances are that something on the client's machine is interfering. For example, Windows security settings or antivirus software that provides networking security can cause the TAP adapter to be classified as an “unidentified network.” You may have to set the Windows Firewall state to “Off” under “Public Profile” of Windows Firewall's “Advanced settings.”

Note that this bridged configuration does not require IP forwarding to be enabled since bridging operates at layer 2 of the OSI model, not at layer 3 where routing such as IP forwarding is done.

Also, the Ethernet interface to which the VM is bridged can't be involved in any bridging in the host OS. If the Ethernet interface is a member of a bridge interface that's already up in the host OS, then networking won't work in the Linux VM. See this for comments on running the Linux VM and networked emulators (that use bridging) in the host OS simultaneously.

Appendices

Bypassing Public Firewalls Using TCP Port 443

Firewalls in certain controlled environments such as public hotspots, companies, and schools/colleges/universities block most ports, sometimes allowing traffic over only TCP ports 80 (HTTP) and 443 (HTTPS). Since TCP port 443 is primarily used for sending HTTP over SSL/TLS, and OpenVPN encrypts its traffic over SSL/TLS, the OpenVPN traffic can be sent over this port as well, being indistinguishable from the other SSL/TLS traffic.

To use TCP port 443, edit your server.conf file to include the lines

port 443
proto tcp

instead of the lines “port 1194” and “proto udp”. Also, insert the line

tcp-nodelay

which will help to minimize any extra latency incurred by using TCP.

Using a UDP port for a VPN will generally yield faster performance than TCP, so you should use TCP only if you must. This is because TCP performs error checking and flow control, whereas UDP does not. Your local services that use private (internal) TCP ports will be performing these checks anyway, so there is no loss of this functionality when tunneling over UDP.

If you have a hosted service on your LAN that already uses TCP port 443, OpenVPN can share the port with that service. If you have this service running at IP address 192.168.5.25, for example, you would insert the line

port-share 192.168.5.25 443

into your server.conf file. Set your router to forward public and private (external and internal) TCP port 443 to the private IP address of the Linux VM (OpenVPN server). Non-OpenVPN traffic will be redirected to the other service's address. See the OpenVPN 2.3 manual for more details.

Client Usage with Virtual Machines

To make use of the VPN connection in a virtual machine, the client should first connect to the VPN in the host, then have the virtualization program bridge the VM's virtual network adapter to OpenVPN's TAP interface. For example, in OS X, open the connection via Tunnelblick in the host, then bridge the VM to tap0. Note that, in this configuration, the VM's public IP address will be that of the server side, and the VM will no longer be visible on the client's LAN. The VM's virtual network adapter will receive a private IP address in the server side's DHCP range, not in OpenVPN's client range. A second bridged virtual network adapter can be used to allow the VM to be bridged to both the client's LAN and the VPN. Usually, just switching to the TAP interface when desired, then switching back, using a single virtual network adapter, is easiest.

Also, on the server side, you should make it a habit to use virtual network adapters for VMs in their bridged configurations, unless you specifically don't want this. In bridged mode, a VM will receive its own private IP address and be visible to the rest of the LAN and VPN, effectively being treated as a separate computer on the LAN.

LAN Gaming

The bridged OpenVPN server is ideal for playing LAN games over the Internet. This is primarily because many games require broadcasts (be sure that clients configure their TAP adapter), and many older games use non-IP protocols, both of which work easily over the virtual Ethernet connection. Below are some comments regarding LAN games using this VPN.

Hosting the Game

If there are two or more VPN clients, a machine on the server side should host the game, since those machines are at the “center” of the virtual network. This ensures that any given client's ping time in the game is no larger than the ping time between that client and the server side. If there's only one client, then it doesn't matter whether the VPN client hosts the game.

Non-IP Protocols and Retro Games

The bridged OpenVPN server tunnels the entire Ethernet frame over the VPN. Therefore, it doesn't matter what protocol is being used. It will work just as it would over Ethernet. Furthermore, any machine connected to the OpenVPN server can use these protocols over a wireless connection. So a machine already on the server side, but connected by wireless, could become a client of the OpenVPN server in order to use non-IP protocols.

Here is some general information for playing old multiplayer games on modern computers:

  • Virtual machines and emulators that include networking functionality are very useful for running old operating systems, which some old games may require.
  • IPX games for Windows can be played over the VPN as they would normally over a LAN, when using Windows XP or earlier, which include the IPX protocol. For Windows Vista or later, use IPXWrapper.
  • DOSBox can be used for playing DOS games. It can emulate IPX, modem, and direct serial connections. I recommend the Daum build, which is packed with features that aren't included in the official build.
  • Many video game console emulators contain netplay functionality. The Emulation General wiki provides a good overview of these emulators.
  • Some LAN-based programs don't specify which ports they use. Unless you can determine the ports, a VPN is necessary for networking these programs over the Internet.
  • You can play shared-screen and “hot seat” games using remote desktop software.
bridged_openvpn_server_setup.1430860424.txt.gz · Last modified: 2015/05/05 14:13