The official version of this document is stored on the main website. If you find a problem in the official version you can fix it in the [Wiki version](HOWTO). Changes made to the Wiki version will be merged periodically to the official version.

* [Client configuration file](https://github.com/OpenVPN/openvpn/blob/master/sample/sample-config-files/client.conf).

* No X509 PKI (Public Key Infrastructure) to maintain

* Lack of perfect forward secrecy -- key compromise results in total disclosure of previous sessions

* Secret key must exist in plaintext form on each VPN peer

* Secret key must be exchanged using a pre-existing secure channel

method can be used, or you can search for an OpenVPN port or package that is specific to your OS/distribution.

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:

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

Note that the server and client clocks need to be roughly in sync or certificates might not work properly.

**Please take note:** Easy-RSA Version 3 is now preferred over Easy-RSA Version 2.

EasyRSA-3 has a [Quick-Start Guide](https://github.com/OpenVPN/easy-rsa/blob/master/README.quickstart.md)

There is also [Easy-TLS](https://github.com/TinCanTech/easy-tls), which is an add-on utility to manage `.inline` files and **TLS Crypt V2** keys. (It's very useful)

On Windows:

You are using [Easy-RSA Version 3](https://github.com/OpenVPN/easy-rsa/releases).

----

Otherwise, continue:

On Windows:

Generating client certificates is very similar to the previous step. On Linux/BSD/Unix:

On Windows:

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.

Diffie Hellman parameters must be generated for the OpenVPN server. On Linux/BSD/Unix:

On Windows:

Output:

Now we will find our newly-generated keys and certificates in the **keys** subdirectory. Here is an explanation of the relevant 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.

Next, make sure that the TUN/TAP interface is not firewalled.

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:

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:

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

The lack of standards in this area means that most OSes have a different way of configuring daemons/services for autostart on boot. The best way to have this functionality configured by default is to install OpenVPN as a package, such as via RPM on Linux or using the Windows installer.

When OpenVPN is started as a service on Windows, the only way to control it is:

While most configuration changes require you to restart the server, there are two directives in particular which refer to files which can be dynamically updated on-the-fly, and which will take immediate effect on the server without needing to restart the server process.

**client-config-dir** -- This directive sets a client configuration directory, which the OpenVPN server will scan on every incoming connection, searching for a client-specific configuration file (see the manual page for more information). Files in this directory can be updated on-the-fly, without restarting the server. Note that changes in this directory will only take effect for new connections, not existing connections. If you would like a client-specific configuration file change to take immediate effect on a currently connected client (or one which has disconnected, but where the server has not timed-out its instance object), kill the client instance object by using the management interface (described below). This will cause the client to reconnect and use the new **client-config-dir** file.

**crl-verify** -- This directive names a Certificate Revocation List file, described below in the Revoking Certificates section. The CRL file can be modified on the fly, and changes will take effect immediately for new connections, or existing connections which are renegotiating their SSL/TLS channel (occurs once per hour by default). If you would like to kill a currently connected client whose certificate has just been added to the CRL, use the management interface (described below).

The default [server.conf](https://github.com/OpenVPN/openvpn/blob/master/sample/sample-config-files/server.conf) file has a line

For more information, see the [OpenVPN Management Interface Documentation](https://github.com/OpenVPN/openvpn/blob/master/doc/management-notes.txt).

Once the VPN is operational in a point-to-point capacity between client and server, it may be desirable to expand the scope of the VPN so that clients can reach multiple machines on the server network, rather than only the server machine itself.

First, you must advertise the 10.66.0.0/24 subnet to VPN clients as being accessible through the VPN. This can easily be done with the following server-side config file directive:

Next, add the following line to the main server config file (not the ccd/client2 file):

Why the redundant **route** and **iroute** statements, you might ask? The reason is that **route** controls the routing from the kernel to the OpenVPN server (via the TUN interface) while **iroute** controls the routing from the OpenVPN server to the remote clients. Both are necessary.

Next, ask yourself if you would like to allow network traffic between client2's subnet (192.168.4.0/24) and other clients of the OpenVPN server. If so, add the following to the server config file.

This will cause the OpenVPN server to *advertise* client2's subnet to other connecting clients.

The last step, and one that is often forgotten, is to add a route to the server's LAN gateway which directs 192.168.4.0/24 to the OpenVPN server box (you won't need this if the OpenVPN server box is the gateway for the server LAN). Suppose you were missing this step and you tried to ping a machine (not the OpenVPN server itself) on the server LAN from 192.168.4.8? The outgoing ping would probably reach the machine, but then it wouldn't know how to route the ping reply, because it would have no idea how to reach 192.168.4.0/24. The rule of thumb to use is that when routing entire LANs through the VPN (when the VPN server is not the same machine as the LAN gateway), make sure that the gateway for the LAN routes all VPN subnets to the VPN server machine.

Similarly, if the client machine running OpenVPN is not also the gateway for the client LAN, then the gateway for the client LAN must have a route which directs all subnets which should be reachable through the VPN to the OpenVPN client machine.

This requires a more complex setup (maybe not more complex in practice, but more complicated to explain in detail):