Chapter 5: OpenVPN OpenVPN Configuration 351

3 When the two endpoints want to establish the VPN tunnel, the OpenVPN process on
the one endpoint authenticates the other endpoint. Authentication is based on the
assumption that the pre-shared secret is known only to the other endpoint; that is,
authentication is based on the assumption that if any host knows the shared secret,
that host must be the other endpoint.
4 Once the endpoints are authenticated, the OpenVPN process on each side derives a
set of keys from the pre-shared secret. These keys are used for two purposes:
— Some are used in an encryption algorithm to encrypt the tunnel data. This
provides data confidentiality.
— The others are used in a message authentication code (MAC) that uses a hash
algorithm with the keys on the tunnel data. This provides data integrity.

TLS
Transport Layer Security (TLS) is a cryptographic protocol that uses public key
cryptography and does not require the two endpoints to have a pre-shared secret.
OpenVPN uses TLS with X.509 certificates, and requires public key infrastructure (PKI)
to generate the certificates. (For a brief overview of X.509 certificates, please see
“Remote VPN Access Using L2TP/IPsec with X.509 Certificates” on page 253.) When
TLS is used, OpenVPN works as follows:
1 Using PKI, the adminstrator generates a certificate and the associated files for each
endpoint. All certificates are “signed” by the certificate authority (CA) of the PKI.
The certificate for an endpoint contains many pieces of information, one of which is
the endpoint’s name, which is stored in the Common Name field of the certificate.

2 The adminstrator transfers each certificate and the associated files to the
corresponding endpoint using a pre-established, secure channel (for example,
SCP).
3 When two endpoints want to establish the VPN tunnel, one takes a passive role
while the other endpoint must take an active role and initiate the TLS session with
the passive endpoint.
4 Once the active endpoint initiates the TLS session, the two sides authenticate one
another using their public/private key pairs and the CA’s public key, which is known
to both endpoints.
5 After the two endpoints have authenticated each other, they establish a shared secret
using public key cryptography. Each endpoint then derives a set of keys for the
session. As for the pre-shared secret mechanism, these keys are then used for
encryption and MAC on the tunnel data to provide data confidentiality and integrity.
However, unlike the pre-shared secret mechanism, these keys are only used for the
one session, and for this reason they are called “session keys.”
Certificate generation and distribution using PKI involves numerous complex
security issues, which are outside the scope of this document.

VPN 6.5R1 v01 Vyatta

Chapter 5: OpenVPN OpenVPN Configuration 352

OpenVPN Modes of Operation

OpenVPN supports both site-to-site and remote access operation. In addition, client-side
remote access support is available for accessing configuration information from an
OpenVPN Access Server.
NOTE If client‐side access to an OpenVPN Access Server is configured, all openvpn
configuration parameters other than those used to connect to the OpenVPN Access Server (i.e.
those within interfaces openvpn <vtunx> remote‐configuration) will be ignored.
This section presents more details about these modes of operation, in the following
topics:
• Site-to-Site Operation
• Remote Access Operation
• Client-Side Access to an OpenVPN Access Server

Site‐to‐Site Operation
Figure 5-1 illustrates a simple site-to-site VPN scenario. This scenario could
represent, for example, a connection between a branch office and a data center.

Figure 5‐1 Site‐to‐site operation

OpenVPN tunnel

OpenVPN interface OpenVPN interface

Physical interfaces
192.168.200.1 192.168.200.2
12.34.56.78 87.65.43.21

VPN endpoint 1 VPN endpoint 2

192.168.100.0/24 192.168.101.0/24

Private Network 1 Private Network 2

VPN 6.5R1 v01 Vyatta

Chapter 5: OpenVPN OpenVPN Configuration 353

At each of the two VPN tunnel endpoints, the OpenVPN process creates a routable
“tunnel interface” and establishes a secure tunnel with the other endpoint. Subsequently,
the two interfaces appear to be on the same network, although packets flowing between
these two interfaces are actually processed and sent through the secure tunnel by the
OpenVPN process.
Note that there are two relevant IP addresses on each endpoint:
• The tunnel IP address: This address is the virtual IP address (VIP) on each end of the
tunnel. The tunnel IP addresses at each end of the tunnel must be on the same subnet.
In the example in Figure 5-1, the tunnel IP addresses of the two endpoints are
192.168.200.1 and 192.168.200.2.
• The physical IP address: This is the IP address configured for the physical
network interface over which the VPN tunnel is established. In the example
above, the physical IP addresses of the two endpoints are 12.34.56.78 and
87.65.43.21.
In most scenarios, the VPN tunnel is used to transport traffic from different private
subnets across the wide area network (WAN). In the example above, the private subnets
192.168.100.0/24 and 192.168.101.0/24 are each “behind” a VPN tunnel endpoint.
Therefore, on each endpoint, you must add a static route that directs traffic to and from
the remote private subnet through the tunnel interface.
In site-to-site mode, a single host can establish multiple OpenVPN tunnels, each of
which may be to distinct sites. Even if all tunnels originate from a single physical
interface, each tunnel is represented by a different tunnel interface IP address and
operates independently.

Remote Access Operation

OpenVPN also supports remote access VPN using a client-server mode. In this mode,
one OpenVPN endpoint acts as the server and all remote endpoints operate as clients,
which connect to the OpenVPN server to establish VPN tunnels, so that each client
establishes has an independent tunnel to the server. A simple remote access VPN setup is
shown in Figure 5-2.

VPN 6.5R1 v01 Vyatta

Chapter 5: OpenVPN OpenVPN Configuration 354

Figure 5‐2 Remote access operation

OpenVPN tunnel

OpenVPN interface OpenVPN interface

192.168.200.1 192.168.200.x
(assigned by server)

OpenVPN server OpenVPN client

One major difference between site-to-site mode and client-server mode is that in client-
server mode, all the VPN tunnels on the server side terminate at a single tunnel interface.
Having a single termination point eliminates the need to set up separate tunnel interface
IP addresses for each VPN tunnel. This is more convenient and operationally simpler for
a remote access setup.
Another difference is that in client-server mode, the server-side OpenVPN process
dynamically allocates all tunnel IP addresses from a configured subnet
(192.168.200.0/24 in the example) instead of using fixed tunnel IP addresses for tunnel
endpoints. Thus, when the OpenVPN process is started on the server, it creates the
tunnel interface and assigns it an IP address from the subnet to the interface (for
example, 192.168.200.1). Then, when a client establishes a VPN tunnel with the server,
the server-side OpenVPN process also allocates the client an IP address from the same
subnet (for example, 192.168.200.4) and the tunnel interface on the client adopts this
address.

Client‐Side Access to an OpenVPN Access Server

This feature is available only in the Vyatta Subscription Edition.

OpenVPN Access Server is a server that authenticates remote client access requests
(either locally or via an authentication server) and provides OpenVPN tunnel
configuration information to the requesting client. It can also provide OpenVPN

VPN 6.5R1 v01 Vyatta

Chapter 5: OpenVPN OpenVPN Configuration 355

client software if the client requires it, though this is not required for Vyatta clients. The
configuration information allows the client to then establish an OpenVPN tunnel with an
OpenVPN server with minimal configuration on the client side.
The sequence of events is as follows:
1 An administrator configures an OpenVPN Access Server for Vyatta client access
and, potentially, configures a separate authentication server and OpenVPN server.
The Vyatta client only requires configuration information from the server. It does not
require client software.
NOTE It is possible for the OpenVPN Access Server to act as the access server, the
authentication server, and the OpenVPN server.
NOTE The OpenVPN Access Server product is not available from Vyatta. It is available from
OpenVPN at http://openvpn.net.
2 The Vyatta client accesses the OpenVPN Access Server and provides a username
and password.
3 The OpenVPN Access Server authenticates the user, either acting as its own
authentication server or using an external authentication server such as a
RADIUS server.
4 After authentication, the OpenVPN Access Server sends the Vyatta client device the
configuration information necessary to establish an OpenVPN tunnel with an
OpenVPN server.
5 The Vyatta client then establishes an OpenVPN tunnel with the OpenVPN server
specified in the downloaded configuration and is provided an IP address on the
OpenVPN tunnel subnet.
NOTE If the OpenVPN server is configured such that Autologin is enabled then a tunnel‐username and
tunnel‐password are not required, otherwise they are required to establish the VPN tunnel.

The Vyatta system has the OpenVPN client software preloaded and can use the
OpenVPN Access Server to obtain the information necessary to establish an OpenVPN
tunnel with an OpenVPN server. The only required configuration information is the
OpenVPN Access Server’s IP address or hostname, a username and password for the
OpenVPN Access Server, and, potentially, the tunnel-username and tunnel-password for
establishing the tunnel with the OpenVPN server.
An OpenVPN setup using an OpenVPN Access Server, an authentication server, and
OpenVPN server is shown in Figure 5-3.

VPN 6.5R1 v01 Vyatta

Chapter 5: OpenVPN OpenVPN Configuration 356

Figure 5‐3 Client‐side access to an OpenVPN Access Server

Authentication Server OpenVPN Access Server

12.34.56.78

OpenVPN tunnel

OpenVPN interface OpenVPN interface

192.168.200.1 192.168.200.x

OpenVPN Server Vyatta device (V2)

192.168.100.0/24

Private Network 1 Private Network 2

You can use the operational command show interfaces to show the assigned IP
address on the client side of the OpenVPN tunnel.

Configuration Examples for Basic Usage

This section describes several basic scenarios of OpenVPN usage and explains how to
configure them. This section presents the following topics:
• Site-to-Site Mode with Pre-Shared Secret
• Site-to-Site Mode with TLS
• Client-Server Mode
• Setting Up OpenVPN Clients on Windows Hosts
• Firewall Configuration
• Using an OpenVPN Access Server

Site‐to‐Site Mode with Pre‐Shared Secret

Figure 5-4 shows the site-to-site scenario configured with pre-shared secret.
In this example:
• The physical IP addresses for V1 and V2 are 12.34.56.78 and 87.65.43.21,
respectively.

VPN 6.5R1 v01 Vyatta

Chapter 5: OpenVPN OpenVPN Configuration 357

• The tunnel IP addresses for V1 and V2 are 192.168.200.1 and 192.168.200.2,

respectively.
• The subnet to be accessed from V1 (via V2 over the VPN) is 192.168.100.0/24.
• The subnet we want to access on V2 (via V1over the VPN) is 192.168.101.0/24.
To configure an OpenVPN tunnel, you create an interface of type openvpn.The
interface name is in the form of vtunnum; for example, vtun0, vtun1, and so on.
In addition, you must add a static interface route to direct traffic for the remote
subnet through the tunnel interface vtun0. (For information on setting up static
routes, see the Vyatta Basic Routing Reference Guide.)

Figure 5‐4 Site‐to‐site VPN with pre‐shared secret

OpenVPN tunnel

OpenVPN interface OpenVPN interface

Physical interfaces
192.168.200.1 192.168.200.2
12.34.56.78 87.65.43.21

V1 V2

192.168.100.0/24 192.168.101.0/24

This section presents the following examples:

• Example 5-1 Site-to-site OpenVPN with pre-shared secret: V1 endpoint
• Example 5-2 Site-to-site OpenVPN with pre-shared secret: V1 static route
• Example 5-3 Site-to-site OpenVPN with pre-shared secret: V2 endpoint
• Example 5-4 Site-to-site OpenVPN with pre-shared secret: V2 static route
To configure the V1 endpoint, perform the following steps in configuration mode.

Example 5‐1 Site‐to‐site OpenVPN with pre‐shared secret: V1 endpoint

Step Command

Create the vtun0 configuration vyatta@V1# set interfaces openvpn vtun0

node.

VPN 6.5R1 v01 Vyatta

Chapter 5: OpenVPN OpenVPN Configuration 358

Example 5‐1 Site‐to‐site OpenVPN with pre‐shared secret: V1 endpoint

Set the tunnel IP address for the vyatta@V1# set interfaces openvpn vtun0 local‐address
local endpoint. 192.168.200.1

Set the OpenVPN mode to vyatta@V1# set interfaces openvpn vtun0 mode site‐to‐site
“site‐to‐site”.

Set the tunnel IP address of the vyatta@V1# set interfaces openvpn vtun0 remote‐address
remote endpoint. 192.168.200.2

Specify the physical IP address vyatta@V1# set interfaces openvpn vtun0 remote‐host
of the remote host. 87.65.43.21

Specify the location of the file vyatta@V1# set interfaces openvpn vtun0
containing the pre‐shared shared‐secret‐key‐file /config/auth/secret
secret.

Commit the change. vyatta@V1# commit

Show the OpenVPN vyatta@V1# show interfaces openvpn vtun0

configuration. local‐address 192.168.200.1
mode site‐to‐site
remote‐address 192.168.200.2
remote‐host 87.65.43.21
shared‐secret‐key‐file /config/auth/secret

To configure a static route to access the remote subnet via the OpenVPN tunnel,
perform the following steps in configuration mode.

Example 5‐2 Site‐to‐site OpenVPN with pre‐shared secret: V1 static route

Step Command

Create the static route to vyatta@V1# set protocols static interface‐route

access the remote subnet via 192.168.101.0/24 next‐hop‐interface vtun0
the OpenVPN tunnel.

Commit the change. vyatta@V1# commit

Show the static routing vyatta@V1# show protocols static

configuration. interface‐route 192.168.101.0/24 {
next‐hop‐interface vtun0 {
}
}

The VPN endpoint V2 is identically to endpoint V1, except that local and remote
tunnel IP addresses are reversed. To configure the V2 endpoint, perform the following
steps in configuration mode.

VPN 6.5R1 v01 Vyatta

Chapter 5: OpenVPN OpenVPN Configuration 359

Example 5‐3 Site‐to‐site OpenVPN with pre‐shared secret: V2 endpoint

Step Command

Create the vtun0 configuration vyatta@V2# set interfaces openvpn vtun0

node.

Set the tunnel IP address for the vyatta@V2# set interfaces openvpn vtun0 local‐address
local endpoint. 192.168.200.2

Set the OpenVPN mode to vyatta@V2# set interfaces openvpn vtun0 mode site‐to‐site
“site‐to‐site”.

Set the tunnel IP address of the vyatta@V2# set interfaces openvpn vtun0 remote‐address
remote endpoint. 192.168.200.1

Specify the physical IP address vyatta@V2# set interfaces openvpn vtun0 remote‐host
of the remote host. 12.34.56.78

Specify the location of the file vyatta@V2# set interfaces openvpn vtun0
containing the pre‐shared shared‐secret‐key‐file /config/auth/secret
secret.

Commit the change. vyatta@V2# commit

Show the OpenVPN vyatta@V2# show interfaces openvpn vtun0

configuration. local‐address 192.168.200.2
mode site‐to‐site
remote‐address 192.168.200.1
remote‐host 12.34.56.78
shared‐secret‐key‐file /config/auth/secret

Again, the shared secret file (created using generate vpn openvpn-key <filename> on one
system and copied to the other) must be the same on both endpoints (the path need not be
the same, but the content must be). Note also that the remote-host option is only
required on one of the endpoints; that is, the site-to-site tunnel can be established as long
as even one endpoint has enough information to contact the other.

To configure a static route to access the remote subnet via the OpenVPN tunnel,
perform the following steps in configuration mode.

Example 5‐4 Site‐to‐site OpenVPN with pre‐shared secret: V2 static route

Step Command

Create the static route to vyatta@V2# set protocols static interface‐route

access the remote subnet via 192.168.100.0/24 next‐hop‐interface vtun0
the OpenVPN tunnel.

Commit the change. vyatta@V2# commit

VPN 6.5R1 v01 Vyatta

Chapter 5: OpenVPN OpenVPN Configuration 360

Example 5‐4 Site‐to‐site OpenVPN with pre‐shared secret: V2 static route

Show the static routing vyatta@V2# show protocols static

configuration. interface‐route 192.168.100.0/24 {
next‐hop‐interface vtun0 {
}
}

Site‐to‐Site Mode with TLS

When TLS is used in site-to-site mode, the Vyatta configuration is the same as the
previous section, except that you must configure TLS-related options instead of the
shared-secret-key-file option. As discussed above, one endpoint takes the passive role
and the other takes the active role.
Each endpoint must also have the following files, which are required for the TLS
protocol.
• CA certificate file: This file contains the certificate authority's certificate, which
will be used to validate the other endpoint's certificate.
• Host certificate file: This file contains the endpoint's own certificate, which will be
presented to the other endpoint during the TLS negotiation.
• Host key file: This file contains the endpoint's own private key, which is kept
secret from anybody else.
• Certificate revocation list (CRL) file: (Optional) This file contains a list of
certificates that have been revoked, which will prevent endpoints with these
certificates from establishing a VPN tunnel.
• DH parameters file: (Only needed by the passive endpoint) This file contains
Diffie Hellman parameters that are required only by the endpoint taking the
passive role in the TLS negotiation.
More information about these files is available in the OpenVPN documentation.
The configuration that follows corresponds to the configuration for the example in the
previous section. Assumed that the necessary files have been generated and distributed
to each endpoint and that V1 and V2 are passive and active, respectively.
To configure V1 for a site-to-site VPN with TLS, perform the following steps in
configuration mode.

Example 5‐5 V1 OpenVPN configuration ‐ site‐to‐site with TLS

Step Command

Create the vtun0 configuration vyatta@V1# set interfaces openvpn vtun0

node.
VPN 6.5R1 v01
Vyatta