Bridged OpenVPN Server Setup

(Last updated September 7, 2021. The forum thread is here.)

Due to network incompatibilities between macOS 11 Big Sur and VirtualBox, users of this host OS should use VMware Fusion Player instead, which is free for personal use. Such a VM will require the administrator password at the time the virtual network adapter attempts to enter promiscuous mode. This can be avoided by running the VM headless from the macOS Terminal with the sudo command. This guide will be updated in the future to address usage of VMware Fusion Player, and won't be so VirtualBox-centric.


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. We'll use only free and open-source software: Debian, VirtualBox, and the required packages for use with OpenVPN. 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. 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 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 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.

Using a Unique Subnet

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.

Linux VM Setup

This section provides a procedure for setting up a simple Debian 10 “Buster” 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 VM'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 the default 1024 MB of memory, and choose the default hard drive settings (or larger size). In the newly created VM's settings, set:

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

Display > Screen:
Graphics Controller: VBoxVGA

Network > Adapter 1:
Attached to: Bridged Adapter
Name: select your Ethernet interface/adapter
Under Advanced, Promiscuous Mode: Allow All
Record the generated MAC Address for use later.

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

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.” The installer program proceeds as follows:

Select your language, location and keyboard configuration.

For the hostname, the default “debian” is okay. The domain name can be left blank 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 choices at the “Partition disks” screens. Hit tab and return to select “Yes” when it asks whether to write changes to disk.

Select No when asked whether to scan another CD or DVD.

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 and arrow keys to select only “standard system utilities,” then hit return. The SSH server software is useful for accessing the Linux terminal remotely or when the VM is run in “headless” mode (as a background process). These features help to streamline your usage of the OpenVPN server, but aren't covered in this guide.

Select “Yes” to install the GRUB boot loader, use the down arrow key to choose the /dev/sda device, and hit return.

When the installation is complete, select Continue. The VM will reboot into the newly installed Debian.

At the login prompt, enter


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


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 to log in. Go to Applications > Utilities, and scroll down to select Terminal. You won't yet be able to copy and paste into the VM, and VM's cursor may be sluggish, because 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)

In the VM's Devices menu, select “Insert Guest Additions CD image…”. Select Cancel on the window that pops up. In Terminal, enter

umount /media/cdrom
mount -o exec /media/cdrom

Reboot the VM by entering


Open Terminal and enter

ls /media

The shared folder “vmshared” should now be visible as “sf_vmshared”. Also, you'll 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

You can also run as root

apt-get update

followed by

apt-get upgrade

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

OpenVPN Server Setup

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

Authentication Setup with Easy-RSA

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


./easyrsa init-pki

Create a Certificate Authority (CA) by entering

./easyrsa build-ca nopass

For Common Name, enter “OpenVPN-CA” (without quotes).

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 /media/sf_vmshared/credentials
cp /etc/openvpn/easy-rsa/pki/ca.crt /etc/openvpn/easy-rsa/pki/issued/*.crt /etc/openvpn/easy-rsa/pki/private/*.key /media/sf_vmshared/credentials

More information on revoking client certificates, see this guide.

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

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.


# Define Bridge Interface

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

# Define physical ethernet interface to be bridged
# with TAP interface(s) above.

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

    brctl addbr $br
    brctl addif $br $eth

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

    for t in $tap; do
        ip addr flush dev $t
        ip link set $t promisc on up

    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
    ip link set $br down
    brctl delbr $br

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

    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
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. (If not using VirtualBox, you also might 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.) 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.

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, 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/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
keepalive 10 120
tls-auth /etc/openvpn/easy-rsa/pki/private/ta.key 0
cipher AES-256-GCM
compress lz4-v2
push "compress lz4-v2"
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. More information on the server configuration file can be found at OpenVPN's HOWTO page and the OpenVPN 2.4 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

Final Settings in the VM

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


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

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

OpenVPN Client Setup

Client Configuration

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:

dev tap0
proto udp
ca ca.crt
cert joe.crt
key joe.key
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-GCM
compress lz4-v2
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.

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

Mac Client Software: Tunnelblick

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.

Windows Client Software: Securepoint SSL VPN Client

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


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

Broadcasts in Windows

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

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.


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


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, for example, you would insert the line

port-share 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.4 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 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.

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.
  • 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 over the Internet using remote desktop software.
bridged_openvpn_server_setup.txt · Last modified: 2021/09/07 06:45 by nucar
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki