This recipe will explain the shortest setup possible when using OpenVPN. For this setup, you require two computers that are connected over a network (LAN or Internet). We will use both a TUN-style network and a TAP-style network and will focus on the differences between them. A TUN device is used mostly for VPN tunnels where only IP traffic is used. A TAP device allows all the Ethernet frames to be passed over the OpenVPN tunnel, hence providing support for non-IP based protocols, such as IPX and AppleTalk.
While this may seem useless at first glance, it can be very useful to quickly test whether OpenVPN can connect to a remote system.
Install OpenVPN 2.3.9 or higher on two computers. Make sure the computers are connected over a network. For this recipe, the server computer was running CentOS 6 Linux and OpenVPN 2.3.9 and the client was running Windows 7 Pro 64bit and OpenVPN 2.3.10.
Here are the steps that you need to follow:
- Launch the server-side (listening) OpenVPN process for the TUN-style network:
[root@server]# openvpn --ifconfig 10.200.0.1 10.200.0.2 --dev tun
- Then, launch the client-side OpenVPN process:
[WinClient] C:>"Program FilesOpenVPNinopenvpn.exe" --ifconfig 10.200.0.2 10.200.0.1 --dev tun --remote openvpnserver.example.com
The following screenshot shows how a connection is established:
As soon as the connection is established, we can ping the other end of the tunnel.
- Next, stop the tunnel by pressing the F4 function key in the command window and restart both ends of the tunnel using the TAP device.
- Launch the server-side (listening) OpenVPN process for the TAP-style network:
[root@server]# openvpn --ifconfig 10.200.0.1 255.255.255.0 --dev tap
- Then launch the client-side OpenVPN process:
[WinClient] C:>" Program FilesOpenVPNinopenvpn.exe" --ifconfig 10.200.0.2 255.255.255.0 --dev tap --remote openvpnserver.example.com
The connection will now be established and we can again ping the other end of the tunnel.
The server listens on UDP port 1194, which is the OpenVPN default port for incoming connections. The client connects to the server on this port. After the initial handshake, the server configures the first available TUN device with the IP address 10.200.0.1 and it expects the remote end (the Peer address) to be 10.200.0.2.
The client does the opposite: after the initial handshake, the first TUN or TAP-Win32 device is configured with the IP address 10.200.0.2. It expects the remote end (the Peer address) to be 10.200.0.1. After this, the VPN is established.
Let's look at a couple of different scenarios and check whether they would modify the process.
In the previous example, we chose the UDP protocol. It would not have made any difference if we had chosen the TCP protocol, provided that we had done that on the server side (the side without --remote) as well as the client side. The following is the code for doing this on the server side:
[root@server]# openvpn --ifconfig 10.200.0.1 10.200.0.2 --dev tun --proto tcp-server
Here's the code for the client side:
[root@client]# openvpn --ifconfig 10.200.0.2 10.200.0.1 --dev tun --proto tcp-client --remote openvpnserver.example.com
With the TAP-style interface, it is possible to run non-IP traffic over the tunnel. For example, if AppleTalk is configured correctly on both sides, we can query a remote host using the aecho command:
aecho openvpnserver 22 bytes from 65280.1: aep_seq=0. time=26. ms 22 bytes from 65280.1: aep_seq=1. time=26. ms 22 bytes from 65280.1: aep_seq=2. time=27. ms
A tcpdump -nnel -i tap0 command shows that the type of traffic is indeed non-IP-based AppleTalk.