Bridged OpenVPN Server Setup

(Last updated May 28, 2023. The forum thread is here.)

This guide describes how to set up a bridge-mode OpenVPN server in a Linux virtual machine (VM). These instructions are intended for home users who wish to run the VM on a Mac or Windows PC. The focus is on using VMware Fusion on a Mac host, but the instructions can easily be adapted for use with VirtualBox or VMware Workstation on other platforms. VMware Fusion Player (for macOS) and VMware Workstation Player (for Windows) are free for non-commercial use, and VirtualBox is free, open-source software.

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. Local traffic of any protocol (TCP, UDP, AppleTalk, IPX, etc.) going to and from the clients, including broadcasts, will be tunneled over a single UDP port. All data over the VPN connection is encrypted.

Possible uses of this VPN include:

• Accessing typical LAN services such as file sharing and printers
• Accessing services that rely on broadcasts or multicasts 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

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.

If you're going to run a VPN server on your home network, it's a good idea to 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. Machines using static IP addresses will have to be changed manually on the respective machines. 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.

This guide will assume that you're running a Debian 11 “Bullseye” VM. Guides on installing Debian in a VM can be found on the Web and YouTube. This section covers only some of the steps, mainly those important to this particular application and the rest of this guide. If you already have your Linux machine set up, you should note the requirements below regarding the VM's virtual network adapter settings before proceeding to the OpenVPN Server Setup section.

The VM software's defaults for the memory and storage space allocated to the VM should be sufficient.

The VM's virtual network adapter must be bridged to the host's Ethernet connection. It must also be allowed to enter promiscuous mode to monitor all network traffic. In VirtualBox, in the VM's network settings, under Advanced, set Promiscuous Mode: Allow All. In VMware Fusion, if starting the VM using the GUI, you have to wait for the guest OS to boot and then enter your administrator password every time you start the VM (except during an administrator password timeout). To avoid this, use the following Terminal command (not now, but after you've finished setting up OpenVPN):

sudo vmrun start "/Users/username/Virtual Machines.localized/Debian 11.x 64-bit.vmwarevm/Debian 11.x 64-bit.vmx" nogui

This will start the VM in “headless” mode, i.e., as a background process. The VM can be shut down gracefully using the command

sudo vmrun stop "/Users/username/Virtual Machines.localized/Debian 11.x 64-bit.vmwarevm/Debian 11.x 64-bit.vmx" soft

In both commands, edit the path to the .vmx file, mainly replacing “username” with your username and both instances “Debian 11.x 64-bit” with whatever you named the VM. Save these commands in shell scripts or .command files for quick usage.

Record the VM's MAC address for use later, which is found in the VM's network settings.

Add a folder to the VM's list of shared folders. This setup assumes that you added a shared folder named “vmshared”.

You may find it easier to use “Install” rather than “Graphical install” since, in a VM, the mouse pointer may not work well until the VM's support software is installed.

The hostname doesn't matter unless you're planning to use it (I just use IP addresses). The domain name can be left blank if your ISP's domain name wasn't detected automatically.

At the software selection screen, the default choices are fine, but the SSH server software is useful for accessing the Linux terminal remotely or when the VM is run in “headless” mode (see the SSH Server appendix). If changing your selections, use the space bar. Pressing return will proceed to the next screen.

After the installation is complete, and Debian has booted to the login screen, log in and set up a shortcut to the Terminal application. If using the default GNOME desktop environment, press the command key on a Mac, or the Windows key in Windows, search for “terminal”, and drag the Terminal icon to the dock for quick access in the future.

In a VMware VM, Open VM Tools should have been installed automatically in Debian when following the default installation, so you should be able to copy and paste into the VM. The keyboard shortcut for pasting into the Linux terminal is shift+control+V, as seen in the terminal's Edit menu.

Open Terminal, and become root by entering

su -

Create a mount point for shared folders:

sudo mkdir -p /mnt/hgfs

We'll use the text editor “nano” throughout this guide to edit text files. To make shared folders mount automatically, enter

nano /etc/fstab

and add to the file the line

.host:/ /mnt/hgfs fuse.vmhgfs-fuse auto,allow_other 0 0

Press control+X, then Y to accept changes, and return to save the file. Reboot the VM by entering

reboot

Open Terminal and enter

ls /mnt/hgfs

The shared folder “vmshared” should now be visible.

If using VirtualBox, you'll have to install Guest Additions before being able to copy and paste into the VM and access shared folders. Again, consult a separate guide. Shared folders will appear in /media, and will have “sf_” prepended to their names if using auto-mount.

The command to shut down the VM as root is

shutdown -h now

You can also run as root

apt update

followed by

apt upgrade

once in a while to update the operating system and its software packages.

The instructions in this section can be used for running OpenVPN 2.5 in Debian 11 (proceeding from the VM setup above) or some similar Linux distribution.

Open Terminal, and become root. You should always become root before running the commands below. Install OpenVPN, Easy-RSA and the Linux Ethernet bridge utilities:

apt 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

./easyrsa init-pki

Create a Certificate Authority (CA) by entering

./easyrsa build-ca nopass

The Common Name will be set to “Easy-RSA CA” by default, so no entry is required.

Create the server credentials by entering

./easyrsa gen-req openvpnserver nopass

The Common Name will be set to “openvpnserver” by default, so no entry is required.

Sign the server credentials by entering

./easyrsa sign-req server openvpnserver

Enter “yes” (without quotes) as requested.

Generate Diffie-Hellman parameters by entering

./easyrsa gen-dh

Now we'll create the client credentials.

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

./easyrsa gen-req joe nopass

The Common Name will be set to “joe” by default, so no entry is required.

Sign the credentials of client “joe” by entering

./easyrsa sign-req client joe

Enter “yes” (without quotes) as requested.

You can make more client credentials by changing “joe” in the previous two commands. Each client's Common Name must be unique.

IMPORTANT: If you ever come back later to /etc/openvpn/easy-rsa to create credentials for additional clients, do NOT run “./easyrsa init-pki” again since this would wipe out your existing credentials.

Create the HMAC signature:

openvpn --genkey secret /etc/openvpn/easy-rsa/pki/private/ta.key

Certificate and key files will be given to the clients. Copy these files to the host OS via the shared folder by entering

mkdir /mnt/hgfs/vmshared/credentials

followed by

cp /etc/openvpn/easy-rsa/pki/ca.crt /etc/openvpn/easy-rsa/pki/issued/*.crt /etc/openvpn/easy-rsa/pki/private/*.key /mnt/hgfs/vmshared/credentials

If using VirtualBox, /mnt/hgfs/vmshared would be replaced by /media/sf_vmshared in the above two commands.

For information on revoking client certificates, see this guide.

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

On an macOS 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'll 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
Subnet mask (netmask): 255.255.255.0 (/24 following the Free IP address in CIDR notation)
Broadcast address: 192.168.5.255
Router's IP address: 192.168.5.1
VM's MAC address: 08:00:27:e7:0e:0a (found in the VM's network settings)

We'll 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="ens33"
eth_ip_netmask="192.168.5.100/24"
eth_broadcast="192.168.5.255"
eth_gateway="192.168.5.1"
eth_mac="08:00:27:e7:0e:0a"

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
        ip addr flush dev $t
        ip link set $t promisc on up
    done

    ip addr flush dev $eth
    ip link set $eth promisc on up

    ip addr add $eth_ip_netmask broadcast $eth_broadcast dev $br
    ip link set $br address $eth_mac
    ip link set $br up

    ip route add default via $eth_gateway
    ;;
stop)
    ip link set $br down
    brctl delbr $br

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

    ip link set $eth promisc off up
    ip addr add $eth_ip_netmask broadcast $eth_broadcast dev $eth

    ip route add default via $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_netmask, eth_broadcast, eth_gateway and eth_mac. Those four variables must be set equal to the free IP address for the Linux VM and its subnet mask, broadcast address, router's IP address, and VM's Mac address, respectively, in quotes as shown. (Depending on your VM software, you may also have to change the “eth” variable to match the name of your Ethernet interface. Use the command “ip a” in Terminal to find this name.) Exit and save. 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.

This script is adapted from the “bridge-start” and “bridge-stop” scripts at OpenVPN's Ethernet bridging page, with the now-deprecated “ifconfig” commands replaced with the equivalent “ip” (iproute2) commands. It bridges the Ethernet interface (the “eth” variable) 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/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/openvpnserver.crt
key /etc/openvpn/easy-rsa/pki/private/openvpnserver.key
dh /etc/openvpn/easy-rsa/pki/dh.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
tls-auth /etc/openvpn/easy-rsa/pki/private/ta.key 0
cipher AES-256-GCM
persist-key
persist-tun
status /var/log/openvpn-status.log
log-append /var/log/openvpn.log
verb 3

The line beginning with “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 subnet mask, 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.

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.

We need to tell OpenVPN to make use of our “openvpn-bridge” script. Enter

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

Copy these two lines:

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

and paste them at the bottom of the [Service] section.

Exit and save. Reboot the VM by entering

reboot

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

Verify that the br0 and tap0 interfaces are up by entering in Terminal

ip a

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

systemctl status openvpn@server.service

Press Q to exit.

Stop the OpenVPN server by entering, as root,

systemctl stop openvpn@server.service

Entering “ip a” 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. The OpenVPN server will always start at boot.

Create a plain text file in a program such as TextEdit in macOS 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
tls-auth ta.key 1
cipher AES-256-GCM
verb 3

PUBLIC_IP_ADDRESS must be replaced with the public IP address of the server side. Google “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 lines beginning with “cert” and “key” must be changed to match the file names of the .crt and .key files for the given client. Save the file as “joe.conf”, and give ca.crt, joe.crt, joe.key, ta.key and joe.conf to the client.

For macOS clients, use Tunnelblick. Be sure to get the correct version for your version of macOS, 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, ta.key and joe.conf into a new 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 under the “Settings” tab, set “Set DNS/WINS” to “Do not set nameserver”. Also uncheck “Check if the apparent public IP address changed after connecting,” since this is unnecessary for this type of VPN setup (the client's public IP address will not change). Exit the menus. With the OpenVPN server running, click the tunnel icon, and connect. A message about the DNS server address not being routed through the VPN may pop up, which can be ignored since this isn't the intent of this VPN setup.

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 original client files after the configuration is created, since they get copied to the folder ~/Library/Application Support/Tunnelblick/Configurations.

For Windows clients, the Windows version of OpenVPN can be used, but here we'll go over using the Securepoint SSL VPN Client, which is very easy to use. When installing, select “Mangagement” for the starting context. Run the desktop shortcut, right-click the program's padlock icon in the taskbar, and select “Show window.” Click on the gear icon, select “New”, and give the VPN connection a name. Enter the public IP address of the server, keep the default protocol (UDP) and port (1194), and click Add and Next. 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. Copy ta.key to the folder with the VPN connection's name, found in the user's “AppData\Roaming\Securepoint SSL VPN\config” folder, the folder to which the other certificate and key files have been copied. Open joe.conf (with WordPad if it was written in macOS 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 original client files after the configuration is created, since they get copied to the folder mentioned above.

If you ever accidentally delete the desktop shortcut, and need to create another one, the executable, SSLVpnClient.exe, may be in the user's “AppData\Local\Apps\Securepoint SSL VPN” folder, depending on how it was installed. The shortcut must have

-manage

at the end of the shortcut's Properties > Target field.

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

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

Uninstall unused TAP adapters under Device Manager > Network adapters. You also can manage TAP adapters using the gear icon > Client settings > “General” tab in Securepoint.

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 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.”

If you have iptables firewall rules set up in Linux, you may need to enter the rules given at OpenVPN's Ethernet bridging page. If you followed the Linux VM setup above, this is not necessary.

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.

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. If sharing port 443 with another service within the VM itself, replace the IP address with “localhost”. 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.

The SSH server is useful for managing the VM from the terminal of another machine, such as Terminal in macOS, or PuTTY in Windows. If you didn't select “SSH server” in Debian's software selection screen during installation, install it manually (as root):

apt install openssh-server

To be able to log in as root, edit the configuration file,

nano /etc/ssh/sshd_config

and uncomment (delete the “#”) and edit the line with the PermitRootLogin field to be

PermitRootLogin yes

Restart the SSH service (or just reboot):

service ssh restart

To log in to the server from another Mac or Linux terminal, use the command

ssh root@192.168.5.100

where the IP address is that chosen for the Linux VM. In PuTTY, it's sufficient to enter the IP address into the “Host Name (or IP address)” field, then log in as “root”. If you remake the VM in the future, the macOS terminal will notice that the machine is not the same one as before, and, as a safety precaution, not let you proceed. If you don't use SSH with any other machines, the quickest remedy to this problem is to delete the SSH known hosts file:

sudo rm ~/.ssh/known_hosts

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 macOS, 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.

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.

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.

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.

• AppleTalk games can be played over the VPN.

• 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.

• 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.

OpenVPN 2.5 manual:
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-5/

OpenVPN HOW-TO page:
https://openvpn.net/community-resources/how-to/

Deprecated Options in OpenVPN:
https://community.openvpn.net/openvpn/wiki/DeprecatedOptions