How to Install OpenVPN
OpenVPN can be downloaded here.
For security, it’s a good idea to check the file release signature after downloading.
The OpenVPN executable should be installed on both server and client machines, since the single executable provides both client and server functions.
Linux Notes (using RPM package)
If you are using a Linux distribution which supports RPM packages (SuSE, Fedora, Redhat, etc.), it’s best to install using this mechanism. The easiest method is to find an existing binary RPM file for your distribution. You can also build your own binary RPM file:
rpmbuild -tb openvpn-[version].tar.gz
Once you have the .rpm file, you can install it with the usual
rpm -ivh openvpn-[details].rpm
or upgrade an existing installation with
rpm -Uvh openvpn-[details].rpm
Installing OpenVPN from a binary RPM package has these dependencies:
Furthermore, if you are building your own binary RPM package, there are several additional dependencies:
See the openvpn.spec file for additional notes on building an RPM package for Red Hat Linux 9 or building with reduced dependencies.
Linux Notes (without RPM)
If you are using Debian, Gentoo, or a non-RPM-based Linux distribution, use your distro-specific packaging mechanism such as apt-get on Debian or emerge on Gentoo.
It is also possible to install OpenVPN on Linux using the universal ./configure method. First expand the .tar.gz file:
tar xfz openvpn-[version].tar.gz
Then cd to the top-level directory and type:
./configure make make install
OpenVPN for Windows can be installed from the self-installing exe file on the OpenVPN download page. Remember that OpenVPN will only run on Windows 2000 or later. Also note that OpenVPN must be installed and run by a user who has administrative privileges (this restriction is imposed by Windows, not OpenVPN). The restriction can be sidestepped by running OpenVPN in the background as a service, in which case even non-admin users will be able to access the VPN, once it is installed. More discussion on OpenVPN + Windows privilege issues.
OpenVPN can also be installed as a GUI on Windows, using Mathias Sundman’s installation package, which will install both OpenVPN and the Windows GUI.
After you run the Windows installer, OpenVPN is ready to use and will associate itself with files having the .ovpn extension. To run OpenVPN, you can:
- Right click on an OpenVPN configuration file (.ovpn) and select Start OpenVPN on this configuration file. Once running, you can use the F4 key to exit.
- Run OpenVPN from a command prompt Window with a command such as:
Once running in a command prompt window, OpenVPN can be stopped by the F4 key.
- Run OpenVPN as a service by putting one or more .ovpn configuration files in \Program Files\OpenVPN\config and starting the OpenVPN Service, which can be controlled from Start Menu -> Control Panel -> Administrative Tools -> Services.
A GUI is also available for the Windows version of OpenVPN.
Mac OS X Notes
Angelo Laub and Dirk Theisen have developed an OpenVPN GUI for OS X.
See also OpenVPN Client and Mac OS X 10.3.
Some notes are available in the INSTALL file for specific OSes. In general, the
./configure make make install
method can be used, or you can search for an OpenVPN port or package which is specific to your OS/distribution.
Determining whether to use a routed or bridged VPN
Overall, routing is probably a better choice for most people, as it is more efficient and easier to set up (as far as the OpenVPN configuration itself) than bridging. Routing also provides a greater ability to selectively control access rights on a client-specific basis.
I would recommend using routing unless you need a specific feature which requires bridging, such as:
- the VPN needs to be able to handle non-IP protocols such as IPX,
- you are running applications over the VPN which rely on network broadcasts (such as LAN games), or
- you would like to allow browsing of Windows file shares across the VPN without setting up a Samba or WINS server.
Numbering private subnets
Setting up a VPN often entails linking together private subnets from different locations.
The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets (codified in RFC 1918):
While addresses from these netblocks should normally be used in VPN configurations, it’s important to select addresses that minimize the probability of IP address or subnet conflicts. The types of conflicts that need to be avoided are:
- conflicts from different sites on the VPN using the same LAN subnet numbering, or
- remote access connections from sites which are using private subnets which conflict with your VPN subnets.
For example, suppose you use the popular 192.168.0.0/24 subnet as your private LAN subnet. Now you are trying to connect to the VPN from an internet cafe which is using the same subnet for its WiFi LAN. You will have a routing conflict because your machine won’t know if 192.168.0.1 refers to the local WiFi gateway or to the same address on the VPN.
As another example, suppose you want to link together multiple sites by VPN, but each site is using 192.168.0.0/24 as its LAN subnet. This won’t work without adding a complexifying layer of NAT translation, because the VPN won’t know how to route packets between multiple sites if those sites don’t use a subnet which uniquely identifies them.
The best solution is to avoid using 10.0.0.0/24 or 192.168.0.0/24 as private LAN network addresses. Instead, use something that has a lower probability of being used in a WiFi cafe, airport, or hotel where you might expect to connect from remotely. The best candidates are subnets in the middle of the vast 10.0.0.0/8 netblock (for example 10.66.77.0/24).
And to avoid cross-site IP numbering conflicts, always use unique numbering for your LAN subnets.
Setting up your own Certificate Authority (CA) and generating certificates and keys for an OpenVPN server and multiple clients
The first step in building an OpenVPN 2.0 configuration is to establish a PKI (public key infrastructure). The PKI consists of:
- a separate certificate (also known as a public key) and private key for the server and each client, and
- a master Certificate Authority (CA) certificate and key which is used to sign each of the server and client certificates.
OpenVPN supports bidirectional authentication based on certificates, meaning that the client must authenticate the server certificate and the server must authenticate the client certificate before mutual trust is established.
Both server and client will authenticate the other by first verifying that the presented certificate was signed by the master certificate authority (CA), and then by testing information in the now-authenticated certificate header, such as the certificate common name or certificate type (client or server).
This security model has a number of desirable features from the VPN perspective:
- The server only needs its own certificate/key — it doesn’t need to know the individual certificates of every client which might possibly connect to it.
- The server will only accept clients whose certificates were signed by the master CA certificate (which we will generate below). And because the server can perform this signature verification without needing access to the CA private key itself, it is possible for the CA key (the most sensitive key in the entire PKI) to reside on a completely different machine, even one without a network connection.
- If a private key is compromised, it can be disabled by adding its certificate to a CRL (certificate revocation list). The CRL allows compromised certificates to be selectively rejected without requiring that the entire PKI be rebuilt.
- The server can enforce client-specific access rights based on embedded certificate fields, such as the Common Name.
Generate the master Certificate Authority (CA) certificate & key
In this section we will generate a master CA certificate/key, a server certificate/key, and certificates/keys for 3 separate clients.
For PKI management, we will use a set of scripts bundled with OpenVPN.
If you are using Linux, BSD, or a unix-like OS, open a shell and cd to the easy-rsa subdirectory of the OpenVPN distribution. If you installed OpenVPN from an RPM file, the easy-rsa directory can usually be found in /usr/share/doc/packages/openvpn or /usr/share/doc/openvpn-2.0 (it’s best to copy this directory to another location such as /etc/openvpn, before any edits, so that future OpenVPN package upgrades won’t overwrite your modifications). If you installed from a .tar.gz file, the easy-rsa directory will be in the top level directory of the expanded source tree.
If you are using Windows, open up a Command Prompt window and cd to \Program Files\OpenVPN\easy-rsa. Run the following batch file to copy configuration files into place (this will overwrite any preexisting vars.bat and openssl.cnf files):
Now edit the vars file (called vars.bat on Windows) and set the KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, and KEY_EMAIL parameters. Don’t leave any of these parameters blank.
Next, initialize the PKI. On Linux/BSD/Unix:
. ./vars ./clean-all ./build-ca
vars clean-all build-ca
The final command (build-ca) will build the certificate authority (CA) certificate and key by invoking the interactive openssl command:
|Note that in the above sequence, most queried parameters were defaulted to the values set in the vars or vars.bat files. The only parameter which must be explicitly entered is the Common Name. In the example above, I used “OpenVPN-CA”.|
Generate certificate & key for server
Next, we will generate a certificate and private key for the server. On Linux/BSD/Unix:
As in the previous step, most parameters can be defaulted. When the Common Name is queried, enter “server”. Two other queries require positive responses, “Sign the certificate? [y/n]” and “1 out of 1 certificate requests certified, commit? [y/n]“.
Generate certificates & keys for 3 clients
Generating client certificates is very similar to the previous step. On Linux/BSD/Unix:
./build-key client1 ./build-key client2 ./build-key client3
build-key client1 build-key client2 build-key client3
If you would like to password-protect your client keys, substitute the build-key-pass script.
Remember that for each client, make sure to type the appropriate Common Name when prompted, i.e. “client1″, “client2″, or “client3″. Always use a unique common name for each client.
Generate Diffie Hellman parameters
parameters must be generated for the OpenVPN server. On Linux/BSD/Unix:
ai:easy-rsa # ./build-dh Generating DH parameters, 1024 bit long safe prime, generator 2 This is going to take a long time .................+........................................... ...................+.............+.................+......... ......................................
Now we will find our newly-generated keys and certificates in the keys subdirectory. Here is an explanation of the relevant files:
The final step in the key generation process is to copy all files to the machines which need them, taking care to copy secret files over a secure channel.
Now wait, you may say. Shouldn’t it be possible to set up the PKI without a pre-existing secure channel?
The answer is ostensibly yes. In the example above, for the sake of brevity, we generated all private keys in the same place. With a bit more effort, we could have done this differently. For example, instead of generating the client certificate and keys on the server, we could have had the client generate its own private key locally, and then submit a Certificate Signing Request (CSR) to the key-signing machine. In turn, the key-signing machine could have processed the CSR and returned a signed certificate to the client. This could have been done without ever requiring that a secret .key file leave the hard drive of the machine on which it was generated.
Creating configuration files for server and clients
Getting the sample config files
It’s best to use the OpenVPN sample configuration files as a starting point for your own configuration. These files can also be found in
Note that on Linux, BSD, or unix-like OSes, the sample configuration files are named server.conf and client.conf. On Windows they are named server.ovpn and client.ovpn.
Editing the server configuration file
The sample server configuration file is an ideal starting point for an OpenVPN server configuration. It will create a VPN using a virtual TUN network interface (for routing), will listen for client connections on UDP port 1194 (OpenVPN’s official port number), and distribute virtual addresses to connecting clients from the 10.8.0.0/24 subnet.
Before you use the sample configuration file, you should first edit the ca, cert, key, and dh parameters to point to the files you generated in the PKI section above.
At this point, the server configuration file is usable, however you still might want to customize it further:
If you want to run multiple OpenVPN instances on the same machine, each using a different configuration file, it is possible if you:
Editing the client configuration files
The sample client configuration file (client.conf on Linux/BSD/Unix or client.ovpn on Windows) mirrors the default directives set in the sample server configuration file.
Starting up the VPN and testing for initial connectivity
Starting the server
First, make sure the OpenVPN server will be accessible from the internet. That means:
To simplify troubleshooting, it’s best to initially start the OpenVPN server from the command line (or right-click on the .ovpn file on Windows), rather than start it as a daemon or service:
openvpn [server config file]
A normal server startup should look like this (output will vary across platforms):
Sun Feb 6 20:46:38 2005 OpenVPN 2.0_rc12 i686-suse-linux [SSL] [LZO] [EPOLL] built Sun Feb 6 20:46:38 2005 Diffie-Hellman initialized with 1024 bit key Sun Feb 6 20:46:38 2005 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ] Sun Feb 6 20:46:38 2005 TUN/TAP device tun1 opened Sun Feb 6 20:46:38 2005 /sbin/ifconfig tun1 10.8.0.1 pointopoint 10.8.0.2 mtu 1500 Sun Feb 6 20:46:38 2005 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2 Sun Feb 6 20:46:38 2005 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:23 ET:0 EL:0 Sun Feb 6 20:46:38 2005 UDPv4 link local (bound): [undef]:1194 Sun Feb 6 20:46:38 2005 UDPv4 link remote: [undef] Sun Feb 6 20:46:38 2005 MULTI: multi_init called, r=256 v=256 Sun Feb 6 20:46:38 2005 IFCONFIG POOL: base=10.8.0.4 size=62 Sun Feb 6 20:46:38 2005 IFCONFIG POOL LIST Sun Feb 6 20:46:38 2005 Initialization Sequence Completed
Starting the client
As in the server configuration, it’s best to initially start the OpenVPN server from the command line (or on Windows, by right-clicking on the client.ovpn file), rather than start it as a daemon or service:
openvpn [client config file]
A normal client startup on Windows will look similar to the server output above, and should end with the Initialization Sequence Completed message.
Now, try a ping across the VPN from the client. If you are using routing (i.e. dev tun in the server config file), try:
If you are using bridging (i.e. dev tap in the server config file), try to ping the IP address of a machine on the server’s ethernet subnet.
If the ping succeeds, congratulations! You now have a functioning VPN.
If the ping failed or the OpenVPN client initialization failed to complete, here is a checklist of common symptoms and their solutions:
- You get the error message: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity). This error indicates that the client was unable to establish a network connection with the server.Solutions:
- Make sure the client is using the correct hostname/IP address and port number which will allow it to reach the OpenVPN server.
- If the OpenVPN server machine is a single-NIC box inside a protected LAN, make sure you are using a correct port forward rule on the server’s gateway firewall. For example, suppose your OpenVPN box is at 192.168.4.4 inside the firewall, listening for client connections on UDP port 1194. The NAT gateway servicing the 192.168.4.x subnet should have a port forward rule that says forward UDP port 1194 from my public IP address to 192.168.4.4.
- Open up the server’s firewall to allow incoming connections to UDP port 1194 (or whatever TCP/UDP port you have configured in the server config file).
- You get the error message: Initialization Sequence Completed with errors — This error can occur on Windows if (a) You don’t have the DHCP client service running, or (b) You are using certain third-party personal firewalls on XP SP2.Solution: Start the DHCP client server and make sure that you are using a personal firewall which is known to work correctly on XP SP2.
- You get the Initialization Sequence Completed message but the ping test fails — This usually indicates that a firewall on either server or client is blocking VPN network traffic by filtering on the TUN/TAP interface.Solution: Disable the client firewall (if one exists) from filtering the TUN/TAP interface on the client. For example on Windows XP SP2, you can do this by going to Windows Security Center -> Windows Firewall -> Advanced and unchecking the box which corresponds to the TAP-Win32 adapter (disabling the client firewall from filtering the TUN/TAP adapter is generally reasonable from a security perspective, as you are essentially telling the firewall not to block authenticated VPN traffic). Also make sure that the TUN/TAP interface on the server is not being filtered by a firewall (having said that, note that selective firewalling of the TUN/TAP interface on the server side can confer certain security benefits. See the access policies section below).
- The connection stalls on startup when using a proto udp configuration, the server log file shows this line:
TLS: Initial packet from x.x.x.x:x, sid=xxxxxxxx xxxxxxxx
however the client log does not show an equivalent line.
Solution: You have a one-way connection from client to server. The server to client direction is blocked by a firewall, usually on the client side. The firewall can either be (a) a personal software firewall running on the client, or (b) the NAT router gateway for the client. Modify the firewall to allow returning UDP packets from the server to reach the client.
See the FAQ for additional troubleshooting information.