tar xzf openvpn-[version].tar.gz
cd openvpn-[version]

./configure
make
sudo make install

sudo openvpn --config /path/to/your/config/file.ovpn

sudo systemctl enable openvpn@server

sudo chkconfig openvpn on

tar xfz openvpn-[version].tar.gz
cd openvpn-[version]
./configure
make
make install

./configure
make
make install

. ./vars
./clean-all
./build-ca

vars

clean-all
build-ca

./build-key-server server

./build-key client1

./build-key client1

For example, suppose you would like connecting clients to use an internal DNS server at 10.66.0.4 or 10.66.0.5 and a WINS server at 10.66.0.8. Add this to the OpenVPN server configuration:

```
push "dhcp-option DNS 10.66.0.4"
push "dhcp-option DNS 10.66.0.5"
push "dhcp-option WINS 10.66.0.8"
```

To test this feature on Windows, run the following from a command prompt window after the machine has connected to an OpenVPN server:

```
ipconfig /all
```

The entry for the TAP-Windows adapter should show the DHCP options which were pushed by the server.

## Configuring client-specific rules and access policies

Suppose we are setting up a company VPN, and we would like to establish separate access policies for 3 different classes of users:

- **System administrators** -- full access to all machines on the network
- **Employees** -- access only to Samba/email server
- **Contractors** -- access to a special server only

The basic approach we will take is (a) segregate each user class into its own virtual IP address range, and (b) control access to machines by setting up firewall rules which key off the client's virtual IP address.

In our example, suppose that we have a variable number of employees, but only one system administrator, and two contractors. Our IP allocation approach will be to put all employees into an IP address pool, and then allocate fixed IP addresses for the system administrator and contractors.

Note that one of the prerequisites of this example is that you have a software firewall running on the OpenVPN server machine which gives you the ability to define specific firewall rules. For our example, we will assume the firewall is Linux **iptables**.

First, let's create a virtual IP address map according to user class:

| **Class**       | **Virtual IP Range** | **Allowed LAN Access**  | **Common Names** |
|-----------------|----------------------|-------------------------|------------------|
| Employees       | 10.8.0.0/24          | Samba/email server at 10.66.4.4 | [variable]       |
| System Administrators	| 10.8.1.0/24 | Entire 10.66.4.0/24 subnet | sysadmin1 |
| Contractors | 10.8.2.0/24 | Contractor server at 10.66.4.12 | contractor1, contractor2 |

Next, let's translate this map into an OpenVPN server configuration. First of all, make sure you've followed the steps above for making the 10.66.4.0/24 subnet available to all clients (while we will configure routing to allow client access to the entire 10.66.4.0/24 subnet, we will then impose access restrictions using firewall rules to implement the above policy table).

First, define a static unit number for our tun interface, so that we will be able to refer to it later in our firewall rules:

```
dev tun0
```

In the server configuration file, define the Employee IP address pool:

```
server 10.8.0.0 255.255.252.0
```

Add routes for the System Administrator and Contractor IP ranges:

```
route 10.8.1.0 255.255.255.0
route 10.8.2.0 255.255.255.0
```

Because we will be assigning fixed IP addresses for specific System Administrators and Contractors, we will use a client configuration directory:

```
client-config-dir ccd
```

Now place special configuration files in the ccd subdirectory to define the fixed IP address for each non-Employee VPN client.

```
ccd/sysadmin1
    ifconfig-push 10.8.1.2 10.8.1.1

ccd/contractor1
    ifconfig-push 10.8.2.2 10.8.2.1

ccd/contractor2

    ifconfig-push 10.8.2.3 10.8.2.1
```

Each pair of ifconfig-push addresses represent the virtual client and server IP endpoints. They must be taken from successive /30 subnets in order to be compatible with Windows clients and the TAP-Windows driver. Specifically, the last octet in the IP address of each endpoint pair must be taken from this set:

```
[  1,  2] [  5,  6] [  9, 10] [ 13, 14] [ 17, 18]
[ 21, 22] [ 25, 26] [ 29, 30] [ 33, 34] [ 37, 38]
[ 41, 42] [ 45, 46] [ 49, 50] [ 53, 54] [ 57, 58]
[ 61, 62] [ 65, 66] [ 69, 70] [ 73, 74] [ 77, 78]
[ 81, 82] [ 85, 86] [ 89, 90] [ 93, 94] [ 97, 98]
[101,102] [105,106] [109,110] [113,114] [117,118]
[121,122] [125,126] [129,130] [133,134] [137,138]
[141,142] [145,146] [149,150] [153,154] [157,158]
[161,162] [165,166] [169,170] [173,174] [177,178]
[181,182] [185,186] [189,190] [193,194] [197,198]
[201,202] [205,206] [209,210] [213,214] [217,218]
[221,222] [225,226] [229,230] [233,234] [237,238]
[241,242] [245,246] [249,250] [253,254]
```

This completes the OpenVPN configuration. The final step is to add firewall rules to finalize the access policy. For this example, we will use firewall rules in the Linux iptables syntax:

```
# Employee rule
iptables -A FORWARD -i tun0 -s 10.8.0.0/24 -d 10.66.4.4 -j ACCEPT

# Sysadmin rule
iptables -A FORWARD -i tun0 -s 10.8.1.0/24 -d 10.66.4.0/24 -j ACCEPT

# Contractor rule
iptables -A FORWARD -i tun0 -s 10.8.2.0/24 -d 10.66.4.12 -j ACCEPT

# Close remaining of /22 tunnel
iptables -A FORWARD -i tun0 -s 10.8.3.0/24 -j DROP
```

## Using Alternative Authentication Methods

OpenVPN 2.0 and later include a feature that allows the OpenVPN server to securely obtain a username and password from a connecting client, and to use that information as a basis for authenticating the client.

To use this authentication method, first add the `auth-user-pass` directive to the client configuration. It will direct the OpenVPN client to query the user for a username/password, passing it on to the server over the secure TLS channel.

Next, configure the server to use an authentication plugin, which may be a script, shared object, or DLL. The OpenVPN server will call the plugin every time a VPN client tries to connect, passing it the username/password entered on the client. The authentication plugin can control whether or not the OpenVPN server allows the client to connect by returning a failure (1) or success (0) value.

### Using Script Plugins

Script plugins can be used by adding the `auth-user-pass-verify` directive to the server-side configuration file. For example:

```shell
auth-user-pass-verify auth-pam.pl via-file
```

This will use the `auth-pam.pl` perl script to authenticate the username/password of connecting clients. See the description of `auth-user-pass-verify` in the manual page for more information.

The `auth-pam.pl` script is included in the OpenVPN source file distribution in the sample-scripts subdirectory. It will authenticate users on a Linux server using a PAM authentication module, which could in turn implement shadow password, RADIUS, or LDAP authentication. `auth-pam.pl` is primarily intended for demonstration purposes. For real-world PAM authentication, use the `openvpn-auth-pam` shared object plugin described below.

### Using Shared Object or DLL Plugins

Shared object or DLL plugins are usually compiled C modules which are loaded by the OpenVPN server at run time. For example, if you are using an RPM-based OpenVPN package on Linux, the `openvpn-auth-pam` plugin should be already built. To use it, add this to the server-side config file:

```shell
plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login
```

This will tell the OpenVPN server to validate the username/password entered by clients using the login PAM module.

For real-world production use, it's better to use the **openvpn-auth-pam** plugin, because it has several advantages over the **auth-pam.pl** script:

- The shared object **openvpn-auth-pam** plugin uses a split-privilege execution model for better security. This means that the OpenVPN server can run with reduced privileges by using the directives user **nobody, group nobody**, and **chroot**, and will still be able to authenticate against the root-readable-only shadow password file.
- OpenVPN can pass the username/password to a plugin via virtual memory, rather than via a file or the environment, which is better for local security on the server machine.
- C-compiled plugin modules generally run faster than scripts.

If you would like more information on developing your own plugins for use with OpenVPN, see the **README** files in the **plugin** subdirectory of the OpenVPN source distribution.

To build the **openvpn-auth-pam** plugin on Linux, cd to the **plugin/auth-pam** directory in the OpenVPN source distribution and run make.

## Using username/password authentication as the only form of client authentication

By default, using **auth-user-pass-verify** or a username/password-checking **plugin** on the server will enable dual authentication, requiring that both client-certificate and username/password authentication succeed in order for the client to be authenticated.

While it is discouraged from a security perspective, it is also possible to disable the use of client certificates, and force username/password authentication only. On the server:

```bash
client-cert-not-required
```

Such configurations should usually also set:

```bash
username-as-common-name
```

which will tell the server to use the username for indexing purposes as it would use the Common Name of a client which was authenticating via a client certificate.

Note that **client-cert-not-required** will not obviate the need for a server certificate, so a client connecting to a server which uses **client-cert-not-required** may remove the **cert** and **key** directives from the client configuration file, but not the ca directive, because it is necessary for the client to verify the server certificate.

# How to add dual-factor authentication to an OpenVPN configuration using client-side smart cards

### How to Configure Cryptographic Token

To configure a cryptographic token for use with your system, follow these steps:

1. **Install the Necessary Software:**
   - Ensure that the device drivers and provider library for your cryptographic token (smart card or hardware token) are installed on your system. This includes any necessary middleware that facilitates communication between the token and your system.

2. **Locate the PKCS!#11 Provider Library:**
   - As mentioned earlier, the provider library is essential for interfacing with the cryptographic token. Locate the library file which could be named similarly to `opensc-pkcs11.so` or `opensc-pkcs11.dll`, depending on your operating system.

3. **Configure Your Application:**
   - Applications that support PKCS!#11 will have options to configure access to cryptographic tokens. This typically involves specifying the path to the PKCS!#11 provider library within the application settings.
   - For example, in OpenVPN, you would modify the configuration file to include directives such as `pkcs11-providers /usr/lib/pkcs11/opensc-pkcs11.so` and `pkcs11-id 'your-token-id'`.

4. **Initialize the Token:**
   - If your token is new or has been reset, you may need to initialize it. This process involves setting up a PIN, loading certificates, and possibly generating key pairs directly on the device. Tools provided by the token vendor or third-party utilities like OpenSC can be used for this purpose.

5. **Load Certificates:**
   - Depending on your use case, you might need to load one or more certificates onto the token. These certificates could be for authentication, encryption, or signing. Ensure that these certificates are properly formatted and compatible with the token.

6. **Test the Configuration:**
   - After setting up everything, test the configuration to ensure that the token is being correctly accessed by your application. Attempt to authenticate using the token or perform a cryptographic operation.

7. **Secure the Token:**
   - Always keep your cryptographic token secure. Avoid exposing it to potential threats, and ensure that its PIN is not easily guessable. If the token is lost or compromised, take immediate actions to revoke any certificates associated with it and report the incident if necessary.

### Summary

Setting up and configuring a cryptographic token involves multiple steps that include installing necessary software, locating and configuring the PKCS!#11 provider library, initializing and loading certificates onto the token, and ensuring the security of the token. Proper configuration and handling will help in leveraging the robust security features provided by dual-factor authentication mechanisms.You should follow the enrollment procedure:

- Initialize the PKCS!#11 token.
- Generate an RSA key pair on the PKCS!#11 token.
- Create a certificate request based on the key pair, using OpenSC and OpenSSL.
- Submit the certificate request to a certificate authority and receive a certificate.
- Load the certificate onto the token, ensuring that the `id` and `label` attributes of the certificate match those of the private key.

A configured token is one that has both a private key object and a certificate object, where both share the same `id` and `label` attributes.

A simple enrollment utility is Easy-RSA 2.0, which is part of the OpenVPN 2.1 series. Follow the instructions specified in the README file, and then use `pkitool` to enroll.

Initialize a token using the following commands:

```
$ ./pkitool --pkcs11-slots /usr/lib/pkcs11/
$ ./pkitool --pkcs11-init /usr/lib/pkcs11/
```

Enroll a certificate using the following command:

```
$ ./pkitool --pkcs11 /usr/lib/pkcs11/ client1
```

## How to Modify an OpenVPN Configuration to Make Use of Cryptographic Tokens

Ensure you have OpenVPN 2.1 or above to use the PKCS!#11 features.

### Determine the Correct Object

Each PKCS!#11 provider can support multiple devices. To view the available object list, you can use the following command:

```
$ openvpn --show-pkcs11-ids /usr/lib/pkcs11/
```

The following objects are available for use. Each object shown below may be used as a parameter to the `--pkcs11-id` option. Please remember to use single quotation marks.

**Certificate**
- DN: `/CN=User1`
- Serial: `490B82C4000000000075`
- Serialized id: `aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600`

Each certificate/private key pair has a unique "Serialized id" string. The serialized id string of the requested certificate should be specified to the `pkcs11-id` option using single quotation marks.

```
pkcs11-id 'aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600'
```

### Using OpenVPN with PKCS!#11

A typical set of OpenVPN options for PKCS!#11:

```
pkcs11-providers /usr/lib/pkcs11/
pkcs11-id 'aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600'
```

This will select the object which matches the `pkcs11-id` string.

**Advanced OpenVPN options for PKCS#11**

```
pkcs11-providers /usr/lib/pkcs11/provider1.so /usr/lib/pkcs11/provider2.so
pkcs11-id 'aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600'
pkcs11-pin-cache 300
daemon
auth-retry nointeract
management-hold
management-signal
management 127.0.0.1 8888
management-query-passwords
```

This configuration will load two providers into OpenVPN, utilize the certificate specified in the `pkcs11-id` option, and employ the management interface to query passwords. The daemon will enter a hold state if the token cannot be accessed. The token will be valid for 300 seconds after which the password will be re-queried, and the session will disconnect if the management session disconnects.

### PKCS#11 Implementation Considerations

Many PKCS#11 providers utilize threads. To prevent issues caused by the implementation of LinuxThreads (such as setuid and chroot), it is strongly recommended to upgrade to a glibc with Native POSIX Thread Library (NPTL) support if you intend to use PKCS#11.

### OpenSC PKCS#11 Provider

The OpenSC PKCS#11 provider can be found at:
- Unix: `/usr/lib/pkcs11/opensc-pkcs11.so`
- Windows: `opensc-pkcs11.dll`

## Difference between PKCS#11 and Microsoft Cryptographic API (CryptoAPI)

PKCS#11 is a free, cross-platform, vendor-independent standard, whereas CryptoAPI is specific to Microsoft. Most smart card vendors support both interfaces. In the Windows environment, users should choose which interface to use.

The current OpenVPN implementation that uses the MS CryptoAPI (`cryptoapicert` option) functions well unless OpenVPN is run as a service. Running OpenVPN as a service in an administrative environment will likely fail with most smart cards for the following reasons:

- Most smart card providers do not load certificates into the local machine store, preventing access to the user certificate.
- If the OpenVPN client runs as a service without direct user interaction, it cannot prompt the user to provide a password for the smart card, leading to a failure in the password-verification process on the smart card.

Using the PKCS#11 interface allows the use of smart cards with OpenVPN in any implementation, as PKCS#11 does not rely on Microsoft stores and does not always require direct interaction with the end-user.

## Routing all client traffic (including web traffic) through the VPN

### Overview

By default, network traffic to and from the OpenVPN server site will pass over the VPN when an OpenVPN client is active. General web browsing and other internet activities will occur through direct connections that bypass the VPN.In certain cases, this behavior might not be desirable—you might want a VPN client to tunnel all network traffic through the VPN, including general internet web browsing. While this type of VPN configuration will exact a performance penalty on the client, it gives the VPN administrator more control over security policies when a client is simultaneously connected to both the public internet and the VPN at the same time.

## Implementation

Add the following directive to the server configuration file:

```
push "redirect-gateway def1"
```

If your VPN setup is over a wireless network, where all clients and the server are on the same wireless subnet, add the local flag:

```
push "redirect-gateway local def1"
```

Pushing the **redirect-gateway** option to clients will cause all IP network traffic originating on client machines to pass through the OpenVPN server. The server will need to be configured to deal with this traffic somehow, such as by NATing it to the internet, or routing it through the server site's HTTP proxy.

On Linux, you could use a command such as this to NAT the VPN client traffic to the internet:

```
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
```

This command assumes that the VPN subnet is **10.8.0.0/24** (taken from the **server** directive in the OpenVPN server configuration) and that the local ethernet interface is **eth0**.

When **redirect-gateway** is used, OpenVPN clients will route DNS queries through the VPN, and the VPN server will need to handle them. This can be accomplished by pushing a DNS server address to connecting clients which will replace their normal DNS server settings during the time that the VPN is active. For example:

```
push "dhcp-option DNS 10.8.0.1"
```

will configure Windows clients (or non-Windows clients with some extra server-side scripting) to use 10.8.0.1 as their DNS server. Any address which is reachable from clients may be used as the DNS server address.

## Caveats

Redirecting all network traffic through the VPN is not entirely a problem-free proposition. Here are some typical gotchas to be aware of:```markdown
- Many OpenVPN client machines connecting to the internet will periodically interact with a DHCP server to renew their IP address leases. The **redirect-gateway** option might prevent the client from reaching the local DHCP server (because DHCP messages would be routed over the VPN), causing it to lose its IP address lease.
- [Issues exist](wiki:279-are-there-any-issues-related-to-pushing-dhcp-options-to-windows-clients) with respect to pushing DNS addresses to Windows clients.
- Web browsing performance on the client will be noticeably slower.

For more information on the mechanics of the **redirect-gateway** directive, see the manual page.

## Running an OpenVPN server on a dynamic IP address

While OpenVPN clients can easily access the server via a dynamic IP address without any special configuration, things get more interesting when the server itself is on a dynamic address. While OpenVPN has no trouble handling the situation of a dynamic server, some extra configuration is required.

The first step is to get a dynamic DNS address which can be configured to "follow" the server every time the server's IP address changes. There are several dynamic DNS service providers available from which to choose.

The next step is to set up a mechanism so that every time the server's IP address changes, the dynamic DNS name will be quickly updated with the new IP address, allowing clients to find the server at its new IP address. There are two basic ways to accomplish this:

- Use a NAT router appliance with dynamic DNS support (such as the Linksys BEFSR41). Most of the inexpensive NAT router appliances that are widely available have the capability to update a dynamic DNS name every time a new DHCP lease is obtained from the ISP. This setup is ideal when the OpenVPN server box is a single-NIC machine inside the firewall.
- Use a dynamic DNS client application such as ddclient to update the dynamic DNS address whenever the server IP address changes. This setup is ideal when the machine running OpenVPN has multiple NICs and is acting as a site-wide firewall/gateway. To implement this setup, you need to set up a script to be run by your DHCP client software every time an IP address change occurs. This script should (a) run ddclient to notify your dynamic DNS provider of your new IP address and (b) restart the OpenVPN server daemon.

The OpenVPN client by default will sense when the server's IP address has changed, if the client configuration is using a **remote** directive which references a dynamic DNS name. The usual chain of events is that (a) the OpenVPN client fails to receive timely keepalive messages from the server's old IP address, triggering a restart, and (b) the restart causes the DNS name in the **remote** directive to be re-resolved, allowing the client to reconnect to the server at its new IP address.

More information can be found in the [FAQ](wiki:FAQ).

## Connecting to an OpenVPN server via an HTTP proxy

OpenVPN supports connections through an HTTP proxy, with the following authentication modes:

- No proxy authentication
- Basic proxy authentication
- NTLM proxy authentication

First of all, HTTP proxy usage requires that you use TCP as the tunnel carrier protocol. So add the following to both client and server configurations:

```
proto tcp
```

Make sure that any **proto udp** lines in the config files are deleted.

Next, add the **http-proxy** directive to the client configuration file (see the manual page for a full description of this directive).

For example, suppose you have an HTTP proxy server on the client LAN at **192.168.4.1**, which is listening for connections on port **1080**. Add this to the client config:

```
http-proxy 192.168.4.1 1080
```

Suppose the HTTP proxy requires Basic authentication:

```
http-proxy 192.168.4.1 1080 stdin basic
```

Suppose the HTTP proxy requires NTLM authentication:

```
http-proxy 192.168.4.1 1080 stdin ntlm
```

The two authentication examples above will cause OpenVPN to prompt for a username/password from standard input. If you would instead like to place these credentials in a file, replace **stdin** with a filename, and place the username on line 1 of this file and the password on line 2.

# Connecting to a Samba share over OpenVPN

This example is intended to show how OpenVPN clients can connect to a Samba share over a routed **dev tun** tunnel. If you are ethernet bridging (**dev tap**), you probably don't need to follow these instructions, as OpenVPN clients should see server-side machines in their network neighborhood.

For this example, we will assume that:

 * the server-side LAN uses a subnet of **10.66.0.0/24**,
 * the VPN IP address pool uses **10.8.0.0/24** (as cited in the **server** directive in the OpenVPN server configuration file),
 * the Samba server has an IP address of **10.66.0.4**, and* The Samba server has already been configured and is reachable from the local LAN.

If the Samba and OpenVPN servers are running on different machines, ensure you have followed the section on expanding the VPN's scope to include additional machines.

Next, edit your Samba configuration file (`smb.conf`). Ensure the `hosts allow` directive permits OpenVPN clients from the `10.8.0.0/24` subnet to connect. For example:

```
hosts allow = 10.66.0.0/24 10.8.0.0/24 127.0.0.1
```

If you are running the Samba and OpenVPN servers on the same machine, you might want to edit the `interfaces` directive in the `smb.conf` file to also listen on the TUN interface subnet of `10.8.0.0/24`:

```
interfaces  = 10.66.0.0/24 10.8.0.0/24
```

If you are running the Samba and OpenVPN servers on the same machine, connect from an OpenVPN client to a Samba share using the folder name:

```
\\10.8.0.1\sharename
```

If the Samba and OpenVPN servers are on different machines, use the folder name:

```
\\10.66.0.4\sharename
```

For example, from a command prompt window:

```
net use z: \\10.66.0.4\sharename /USER:myusername
```

## Implementing a load-balancing/failover configuration

### Client

The OpenVPN client configuration can refer to multiple servers for load balancing and failover. For example:

```
remote server1.mydomain
remote server2.mydomain
remote server3.mydomain
```

This configuration will direct the OpenVPN client to attempt a connection with server1, server2, and server3 in that order. If an existing connection is broken, the OpenVPN client will retry the most recently connected server, and if that fails, will move on to the next server in the list. You can also direct the OpenVPN client to randomize its server list on startup, so that the client load will be probabilistically spread across the server pool.

```
remote-random
```

If you would also like DNS resolution failures to cause the OpenVPN client to move to the next server in the list, add the following:

```
resolv-retry 60
```

The `60` parameter tells the OpenVPN client to try resolving each remote DNS name for 60 seconds before moving on to the next server in the list.

The server list can also refer to multiple OpenVPN server daemons running on the same machine, each listening for connections on a different port, for example:

```
remote smp-server1.mydomain 8000
remote smp-server1.mydomain 8001
remote smp-server2.mydomain 8000
remote smp-server2.mydomain 8001
```

If your servers are multi-processor machines, running multiple OpenVPN daemons on each server can be advantageous from a performance standpoint.

OpenVPN also supports the remote directive referring to a DNS name which has multiple `A` records in the zone configuration for the domain. In this case, the OpenVPN client will randomly choose one of the `A` records every time the domain is resolved.

## Server

The simplest approach to a load-balanced/failover configuration on the server is to use equivalent configuration files on each server in the cluster, except use a different virtual IP address pool for each server. For example:
```
server1

    server 10.8.0.0 255.255.255.0

server2

    server 10.8.1.0 255.255.255.0

server3

    server 10.8.2.0 255.255.255.0
```

# Hardening OpenVPN Security

One of the often-repeated maxims of network security is that one should never place so much trust in a single security component that its failure causes a catastrophic security breach. OpenVPN provides several mechanisms to add additional security layers to hedge against such an outcome.

## tls-auth

The **tls-auth** directive adds an additional HMAC signature to all SSL/TLS handshake packets for integrity verification. Any UDP packet not bearing the correct HMAC signature can be dropped without further processing. The tls-auth HMAC signature provides an additional level of security above and beyond that provided by SSL/TLS. It can protect against:

 * DoS attacks or port flooding on the OpenVPN UDP port.
 * Port scanning to determine which server UDP ports are in a listening state.
 * Buffer overflow vulnerabilities in the SSL/TLS implementation.
 * SSL/TLS handshake initiations from unauthorized machines (while such handshakes would ultimately fail to authenticate, **tls-auth** can cut them off at a much earlier point).

Using **tls-auth** requires that you generate a shared-secret key that is used in addition to the standard RSA certificate/key:

```
openvpn --genkey --secret ta.key
```This command will generate an OpenVPN static key and write it to the file `ta.key`. This key should be copied over a pre-existing secure channel to the server and all client machines. It can be placed in the same directory as the RSA `.key` and `.crt` files.

In the server configuration, add:
```
tls-auth ta.key 0
```
In the client configuration, add:
```
tls-auth ta.key 1
```

## proto udp

While OpenVPN allows either the TCP or UDP protocol to be used as the VPN carrier connection, the UDP protocol will provide better protection against DoS attacks and port scanning than TCP:
```
proto udp
```

## user/group (non-Windows only)

OpenVPN has been very carefully designed to allow root privileges to be dropped after initialization, and this feature should always be used on Linux/BSD/Solaris. Without root privileges, a running OpenVPN server daemon provides a far less enticing target to an attacker.
```
user nobody
group nobody
```

## Unprivileged mode (Linux only)

On Linux, OpenVPN can be run completely unprivileged. This configuration is a little more complex, but provides the best security.To work with this setup, OpenVPN must be configured to use the iproute interface. This can be done by specifying `--enable-iproute2` in the configure script. Also, ensure that the `sudo` package is installed on your system.

This configuration leverages Linux's capability to change the permissions of a tun device, allowing an unprivileged user to access it. It also utilizes `sudo` to execute `iproute`, enabling modifications to interface properties and the routing table.

**OpenVPN Configuration:**

Create the following script and save it at: `/usr/local/sbin/unpriv-ip`:
```bash
#!/bin/sh
sudo /sbin/ip $*
```
Run `visudo` and add the following lines to allow the user 'user1' to execute `/sbin/ip` without a password:
```plaintext
user1 ALL=(ALL) NOPASSWD: /sbin/ip
```
To enable a group of users to execute `/sbin/ip` without a password, add:
```plaintext
%users ALL=(ALL) NOPASSWD: /sbin/ip
```
Add these lines to your OpenVPN configuration file:
```plaintext
dev tunX/tapX
iproute /usr/local/sbin/unpriv-ip
```
Please ensure you choose either 'tun' or 'tap' and replace `X` with a constant.

To set up a persistent interface as root and allow a user and/or group to manage it, use the following command (replace `tunX` with your chosen device):
```bash
openvpn --mktun --dev tunX --dev-type tun --user user1 --group users
```
Ensure that you replace `X` with the appropriate device number and specify either 'tun' or 'tap' in your configuration.## Run OpenVPN as an Unprivileged User

Further security measures can be enforced by modifying parameters in the `/usr/local/sbin/unpriv-ip` script.

## Chroot (Non-Windows Only)

The **chroot** directive confines the OpenVPN daemon within a chroot jail, limiting its file system access to a specified directory. For instance:

```plaintext
chroot jail
```

This command changes the working directory of the OpenVPN daemon to the `jail` subdirectory upon initialization. It then redefines its root filesystem to this directory, preventing any access to files outside the `jail` and its subdirectories. This is crucial for security, as any compromised server remains isolated from the rest of the server's filesystem.

### Caveats:

Since **chroot** changes the daemon's filesystem perspective, any necessary files for OpenVPN post-initialization should be placed within the `jail` directory, such as:
- the `crl-verify` file, or
- the `client-config-dir` directory.

## Larger RSA Keys

The size of the RSA key is determined by the **KEY_SIZE** variable in the `easy-rsa/vars` file, which should be set prior to key generation. The default is set to 1024, but it can be safely increased to 2048. This enhances security with minimal impact on the performance of the VPN tunnel, although it does slow down the SSL/TLS renegotiation handshake that happens once per client per hour and the initial Diffie Hellman parameters generation in the `easy-rsa/build-dh` script.

## Larger Symmetric Keys

By default, OpenVPN employs **Blowfish**, a 128-bit symmetric cipher.

OpenVPN supports any cipher available in the OpenSSL library, including those with larger key sizes. For instance, to use a 256-bit AES cipher, add the following line to both the server and client configuration files:

```plaintext
cipher AES-256-CBC
```

## Secure Root Key Management

Always keep the root key (`ca.key`) on a standalone machine that is not connected to any network. This enhances the security of your root key by isolating it from potential network-based threats.One of the security benefits of using an X509 PKI (as OpenVPN does) is that the root CA key (`ca.key`) does not need to be present on the OpenVPN server machine. In a high-security environment, you might want to designate a machine specifically for key signing purposes, keep the machine well-protected physically, and disconnect it from all networks. Floppy disks can be used to move key files back and forth, as necessary. Such measures make it extremely difficult for an attacker to steal the root key, short of physical theft of the key signing machine.

# Revoking Certificates

**Revoking a certificate** means to invalidate a previously signed certificate so that it can no longer be used for authentication purposes.

Typical reasons for wanting to revoke a certificate include:

- The private key associated with the certificate is compromised or stolen.
- The user of an encrypted private key forgets the password on the key.
- You want to terminate a VPN user's access.

## Example

As an example, we will revoke the **client2** certificate, which we generated above in the "key generation" section of the HOWTO.

First, open up a shell or command prompt window and change directory to the **easy-rsa** directory as you did in the "key generation" section above. On Linux/BSD/Unix:
```
. ./vars
./revoke-full client2
```
On Windows:
```
vars
revoke-full client2
```
You should see output similar to this:
```
Using configuration from /root/openvpn/20/openvpn/tmp/easy-rsa/openssl.cnf
``````markdown
### Debugging Certificate Revocation

**Debug Log:**
```
DEBUG[load_index]: unique_subject = "yes"
Revoking Certificate 04.
Data Base Updated
Using configuration from /root/openvpn/20/openvpn/tmp/easy-rsa/openssl.cnf
DEBUG[load_index]: unique_subject = "yes"
client2.crt: /C=KG/ST=NA/O=OpenVPN-TEST/CN=client2/emailAddress=me@myhost.mydomain
error 23 at 0 depth lookup:certificate revoked
```
Note the "error 23" in the last line, indicating that a certificate verification of the revoked certificate failed.

The **revoke-full** script will generate a Certificate Revocation List (CRL) file named **crl.pem** in the **keys** subdirectory. This file should be copied to a directory accessible by the OpenVPN server, and CRL verification should be enabled in the server configuration:
```
crl-verify crl.pem
```
Now all connecting clients will have their certificates verified against the CRL, and any matching revoked certificates will result in the connection being dropped.

### CRL Notes

- When using the `crl-verify` option in OpenVPN, the CRL file is re-read every time a new client connects or an existing client renegotiates the SSL/TLS connection (typically once per hour). This allows updates to the CRL file while the OpenVPN server daemon is running, and the new CRL will take effect immediately for new connections. If a client whose certificate has been revoked is already connected, you can restart the server using a signal (SIGUSR1 or SIGHUP) to flush all clients, or you can telnet to the management interface and explicitly kill the specific client instance on the server without affecting other clients.
- The `crl-verify` directive can be used on both the OpenVPN server and clients, but distributing a CRL file to clients is generally unnecessary unless a server certificate has been revoked.
- The CRL file is not confidential and should be world-readable so that the OpenVPN daemon can access it after root privileges are dropped.
- If using the `chroot` directive, ensure a copy of the CRL file is placed in the chroot directory, as the CRL file is read after the `chroot` call is executed.
- A common reason for certificate revocation is that a user forgets the password used to encrypt their private key. Revoking the original certificate allows for the generation of a new certificate/key pair with the same common name.

### Important Note on Mitigating "Man-in-the-Middle" Attacks

To prevent a potential Man-in-the-Middle attack where an authorized client tries to impersonate the server to connect to another client, it is crucial to enforce server certificate verification by clients. For OpenVPN 2.1 and above, you can secure server certificates with specific key usage and extended key usage as outlined by RFC3280 for TLS connections:
```
{Your HTML or other content here}
```
``````markdown
| Mode   | Key usage                          | Extended key usage           |
|--------|------------------------------------|------------------------------|
| Client | digitalSignature                   | TLS Web Client Authentication |
| Client | keyAgreement                       |                              |
| Client | digitalSignature, keyAgreement     |                              |
| Server | digitalSignature, keyEncipherment  | TLS Web Server Authentication |
| Server | digitalSignature, keyAgreement     |                              |
```

You can build your server certificates with the `build-key-server` script (see the easy-rsa documentation for more info). This will designate the certificate as a server-only certificate by setting the right attributes. Now add the following line to your client configuration:

```
remote-cert-tls server
```### Option 2, for OpenVPN 2.0 and below:
Build your server certificates with the **build-key-server** script (see the easy-rsa documentation for more info). This will designate the certificate as a server-only certificate by setting **nsCertType=server**. Now add the following line to your client configuration:
```
ns-cert-type server
```
This will block clients from connecting to any server which lacks the **nsCertType=server** designation in its certificate, even if the certificate has been signed by the **ca** file in the OpenVPN configuration file.

### Option 3:
Use the **tls-remote** directive on the client to accept/reject the server connection based on the common name of the server certificate.

### Option 4:
Use a **tls-verify** script or plugin to accept/reject the server connection based on a custom test of the server certificate's embedded X509 subject details.

### Option 5:
Sign server certificates with one CA and client certificates with a different CA. The client configuration **ca** directive should reference the server-signing CA file, while the server configuration **ca** directive should reference the client-signing CA file.

## Sample OpenVPN 2.0 Configuration Files

Latest sample configuration files are available on [GitHub](https://github.com/OpenVPN/openvpn/tree/master/sample/sample-config-files).

---
Copyright © 2002-2019 by OpenVPN Technologies, Inc. <info@openvpn.net>. OpenVPN is a trademark of OpenVPN Technologies, Inc.