Open VPN

OPENVPN
Created in 2002, OpenVPN is an open source tool used to build site-to-site VPNs with the
SSL/TLS protocol or with pre-share keys. It has the role to securely tunnel the data through a
single TCP/UDP port over an unsecured network such as Internet and thus establish VPNs.
EASINESS
The big strength of OpenVPN is to be extremely easy to install and configure which is rarely the
case for tools used to create VPNs
PORTABILITY
OpenVPN can be installed on nearly any platform including Linux, Windows 2000/XP/Vista,
OpenBSD, FreeBSD, NetBSD, Mac OS X, and Solaris.
The Linux systems must have a 2.4 kernel or higher. The configuration principle remains the
same on any platform.
CLIENT/SERVER ARCHITECTURE
OpenVPN is based on a client/server architecture. It must be installed on both VPN extremities,
one is designated as server the other one as client.
TUNNELLING
OpenVPN creates a TCP or UDP tunnel and then encrypts the data inside the tunnel.
OpenVPN's default port number is UDP 1194, based on an official port number assignment by
IANA. You can use any other TCP or UDP port and since the 2.0 release, a unique port can be
used for several tunnels on the OpenVPN server.
SECURITY MODES:
When using static keys the two VPN gateways share the same key to cipher and decipher the
data. In this case, the configurations will be very simple but the problem is you may need to give
the key (over a secure channel) to somebody you don't necessarily trust at the other end of the
tunnel.
The Public Key Infrastructure (PKI) is used to solve this problem. It is based on the fact that each
party owns two keys, a public key known by everybody and a private key kept secret. This
process is used by OpenSSL, the free and open source SSL version intagrated in OpenVPN, to
authenticate the VPN peers before proceeding to the data encryption.
Let's see the advantages of the two modes:
OpenVPN mode
Pre-shared
keys
SSL
Cryptography
mode
Symmetric
Asymmetric/Symmetric
Implementation
Easier
Harder
Speed:
Quicker
Slower
CPU consumption: Smaller
Higher
Key exchange:
YES
NO
Encryption keys
renewal:
NO
YES
Peers
authentication:
NO
YES
In the next section, we will focus our explanations on OpenVPN in SSL mode (asymmetric
cryptography) which is recommended over the pre-shared mode (symmetric cryptography).
BRIDGING/ROUTING
You can choose to build either Ethernet (Bridged) or IP (Routed) VPNs with the help of,
respectively, the TAP or TUN network drivers. TAP/TUN are available on all the platforms and
are already bundled with the Linux 2.4 kernel or higher.
OPTIONS
The OpenVPN options are particularly important, for example the server can push network routes
on the client or can be used as DHCP server.
Have a look at the OpenVPN man page for information.
Check the OpenVPN tutorial to learn how to configure OpenVPN or continue below by reading
explanations about the SSL protocol.
Let's look at network and security key concepts to understand better the OpenVPN tool.
Top of the page
1. SSL
2. VPN
3. OPENSSL
4. IPSEC & SSL
5. IPSEC
SSL
INTRODUCTION:
For many years, IPSec was the only security protocol available to secure the site-to-site or clientto-server VPNs. By chance, this is now changed with the release of the SSL protocol. Available at
the beginning to secure specific protocols like HTTP, SSL is now able to secure any application
and encrypt TCP or UDP tunnels to create site-to-site or client-to-site VPNs.
In this tutorial, we will focus our work on SSL site-to-site VPNs with the help of an excellent tool
called OpenVPN ...
SSL DESCRIPTION:
SSL (for Secure Sockets Layers) has been created by Netscape in the 90s. Two SSL versions have
been released v2 (1994) and v3 (1995). The patent was then bought and updated by the IETF in
2001. At the same time it was renamed as TLS which stands for Transport Layer Security (RFC
2246).
The SSL word is commonly used to designate both the SSL and TLS protocols. The last version
of TLS is v1.1
SSL GOALS:
The two main SSL goals are the following:
- Authenticate the server and the client using the Public Key Infrastructure (PKI).
- Provide an encrypted connection for the client and server to exchange messages.
OpenVPN AND THE OSI MODEL:
Where could we place the SSL protocol in the OSI model?
The standard OSI model is composed of seven layers while a four layer model matches more
closely the TCP/IP architecture used by the large majority of the applications.
SSL is located between the application and transport layers and will encrypt the application layer.
TYPE OF SSL VPN:

In the past, SSL was a protocol used with specific applications like HTTP; however for some
years able it has been able to potentially secure the transactions of any applications over Internet
and to create encrypted tunnel (VPNs) in the same manner than IPSec does.
Two types of VPNs are available:
- Client-to-server (or remote access) VPNs where the client needs a web browser such as Firefox.
- Site-to-site where a specific software is required such as OpenVPN
SSL process:
Here are the four SSL/TLS steps:
SSL Handshake:
SSL Change Cipher Spec:
SSL Alert:
SSL Record:
Negotiate the Cipher Suite to be used during data transfer

Establish and share a session key between client and server
Conveying SSL error messages between client and server
Transfer Data
Top of the page Key concepts Menu
VPN PRINCIPLES:
VPN (Virtual Private Network) is an acronym used to designate the encrypted tunnel between
two devices over an unsecured network, typically Internet.
The VPN will group together the two local networks behind the VPN devices and thus will create
a unique private network.
The word "VPN" can be used for site-to-site as well as client-to-server secure links. As a
reminder, we will use OpenVPN to create site-to-Site VPNs.
To be considered as secure a VPN must respect the following key concepts:
- Confidentiality or privacy:
The data cannot be seen in a readable format.
Typical symmetric cipher algorithm: DES, 3DES, AES, Blowfish
- Integrity:
The data cannot be altered.
Typical hash-functions algorithms: sha1, md5
- Authentication:
The VPN gateways are sure about the identity of the other.
Typical algorithm: RSA, DH
The picture below provides the status of a packet state when travelling inside the LAN and the
VPN.
Also just to remind everyone VPN is different from VPS.

Top of the page
OPENSSL:
Key concepts Menu
OpenVPN uses a free and open source version of SSL called OpenSSL for the encryption and
authentication tasks. OpenSSL is a toolkit composed of the:
- SSL library.
- Crypto library.
- Command line tool.
The cryptography library implements a wide range of cryptographic algorithms such as:
- Symmetric algorithms: Blowfish, DES, 3DES, AES, etc...
- Certificates: x509
- Hash function: HMAC, MD5
Top of the page
Key concepts Menu
IPSEC - SSL COMPARISON:

The goal of SSL and IPSec is the same: create VPNs and thus encrypt traffic between two devices
with the same algorithms. But as you will see, the way to accomplish this task is very different.
Of course, IPSec and SSL are not compatible.
Let's look first at a basic SSL-IPSec comparison table.
IPSEC
SSL
RFC:
2401
4346 (TLS 1.1)
OSI position:
Internet Layer
Between Transport and

Application Layers
Software
location:
Kernel space
User space
Installation:
Vendor nonspecific
Vendor specific
Configuration:
Complex
Simple
NAT:
Problematic
No problem
Firewall:
Not friendly
Friendly
Interoperability: YES
NO
Let's give some more explanations about the comparison table:

IPSec is a layer 3 protocol. In order to be implemented it will require a modification to the IP
stack in the IPSec device kernel space. Because of this kernel related change, each operating
system (i.e.: Cisco, Windows, Nortel, Linux, etc.) needs its own implementation of IPSec.
OpenVPN will behave much more like a standard application. It is implemented in the user space
and thus has the advantage to be much more secure and portable.
- Secure because in the IPSec case when the software is closely linked with the kernel, an
application crash can damage the kernel and thus the entire system. No problem with OpenVPN
because it is completely separated from the kernel. Another thing to underline concerning
security is that, in case of software hacking, with IPSec the pirate will get kernel access, in
other words the root access. With OpenVPN, a specific user will run the application with
limited rights only.
- Portable because OpenVPN can be installed on virtually any platform and this will therefore
spare you time because you will have always the same software to configure.
A very common problem with IPSec is the need to change firewall rules to permit the protocol
and the address translation (NAT) processing but even this has been partially solved by the NAT
Traversal protocol.
Read details about problems associated with Using IPSec over NAT.
With OpenVPN, you just need to open a TCP or UDP port on a Firewall if it is not already open.
OpenVPN can even work through proxy servers meaning that no firewall changes at all!
As the IP Layer is not modified by SSL, there is no problem with the NAT protocol.
Building a site-to-site SSL tunnel is much simpler than under IPSec. The complexity of the IPSec
configurations leads often to security holes or missed configurations even when built by a
network administrator. Furthermore, the IPSec configurations are always different for each
manufacturer, whereas with SSL and OpenVPN, the configurations are very similar on any
system.
The big advantage of IPSec remains that it can virtually be used on any manufacturers supporting
its RFC. For example, it is normally possible to establish a VPN between a Cisco and a Nortel
router. Normally, because the time has shown that even if the different manufacturers are
supposed to respect the IPSec standards, it remains sometimes compatibility problems.
With OpenVPN it is, of course, not possible to install the software on the major manufacturers
such as Cisco, Checkpoint, Juniper or Nortel.
SSL has now progressed very quickly in the client-to-server VPN segment compared to IPSec
and will progressively replace it in the future.
In the site-to-site VPN segment, this is different because, as explained immedialely above, there
are for the moment no standardized papers (RFCs) to create site-to site SSL VPNs on closed code
manufacturers such as Cisco. As the big majority of site-to-site VPNs are created on closed code
devices, IPSec remains for the moment king in this sector.
Top of the page
IPSEC:
Key concepts Menu
IPSec can be composed by one of the following layer 3 protocols or both of them: ESP (IP
protocol 50, RFC 2406), AH (IP protocol 51, RFC 2402). ESP can be used for integrity and
confidentiality and AH for integrity only.
Two protocols are closely linked with IPSec: ISAKMP (RFC 2408) and IKE (RFC 2409).
ISAKMP (Internet Security Association and Key Management Protocol) is used to establish
security associations and IKE (Internet Key Exchange) for automatic key exchange management
via the UDP port 500.
UBUNTU / DEBIAN
To see the OpenVPN version available:
#apt-cache policy openvpn
openvpn:
Installed: (none)
Candidate: 2.0.9-8
Version table:
2.0.9-8 0
500 http://ch.archive.ubuntu.com gutsy/universe Packages
To download and install OpenVPN:
#apt-get install openvpn
To see the OpenVPN dependencies:
#apt-cache depends openvpn
openvpn
|Depends: debconf
Depends:
cdebconf
debconf
Depends: libc6
Depends: liblzo2-2
Depends: libssl0.9.8
Suggests: openssl
Suggests: resolvconf
WINDOWS
It is of course always better to install OpenVPN on an open source system such as Linux but in
some circumstances, you may need to install it on Microsoft Windows...
The Installation is extremely easy: just download the .exe file, execute it and click on the "next"
buttons with the default settings.
There is no prerequisite to install OpenVPN on Windows.
Top of the page
INSTALL OPENVPN:
Follow the OpenVPN installation tutorial.
CLIENT/SERVER ARCHITECTURE:
Upon the two OpenVPN boxes, you have to declare one as server and the other as client. In some
scenarios, each box can be declared as server or client, but in other scenarios you must
specifically choose a device as client and the other as server. Let us see when.
Before establishing the SSL VPN, the client first reaches the server on a specific port, whereas
the server doesn't need to reach the client. Let's take an example where you are in a professional
environment and want to establish a VPN with a device connected directly to the Internet, let's
say a box at your home.
In this frequent case, the client can reach the server but not the contrary. This is due to the fact
that the client is located in a local network and reaches the internet via a proxy or Firewall which
will substitute its own IP address or another one (Hide NAT) for the source IP address.
Nevertheless, when the tunnel is created, the bi-directional traffic inside it is of course possible.
CONFIGURATION FILE:
Create a file where you store your OpenVPN configuration.
In our example, we will call this file config.txt and save it in the /home/user/ or "C:\Program
Files\OpenVPN\config\" directory depending on whether it is a Linux/Unix or Microsoft
machine.
The configuration settings are presented in the next paragraphs.
CLIENT/SERVER DESIGNATION:
SERVER
# SERVER IP ADDRESS
# The Client WAN IP address is
CLIENT
# SERVER IP ADDRESS
remote 100.0.0.1
not
# needed
TUNNEL MODE:
You can choose between an IP (TUN driver) and an Ethernet (TAP driver) tunnel.
IP tunneling is also referred as routing mode, and Ethernet tunneling as bridging mode.
Prefer the IP tunnel mode (default setting) unless you need to pass Ethernet traffic such as
NetBIOS inside the tunnel.
TUNNEL PORT:
Default source and destination tunneling port is UDP 1194. You should keep the default setting
unless you need to change it for Firewall reasons otherwise you can keep it.
Prefer UDP ports. The use of TCP can lead to degraded performances.
As the majority of the applications uses TCP, if you opt for TCP tunneling, you will create a TCP
over TCP tunnel. This is not recommended because in case of packets retransmissions on the
interior TCP tunnel, recomputation will occur in both tunnels leading to slow performances such
as high response time. Thus, prefer the UDP protocol to tunnel your application since contrary to
TCP, it does not suffer from an overhead error checking mechanism..
Read this article to get details about the problems with TCP over TCP tunnels.
SERVER and CLIENT
# TCP OR UDP TUNNEL
# TCP tunnel
proto tcp
# UDP tunnel is recommended
proto udp
# use TCP or UDP but not both
#
# TCP OR UDP PORT
port 1194
FIREWALL SETTINGS:
You must ascertain that your OpenVPN client IP address can reach the OpenVPN server IP
address and the TCP/UDP port.
Here is an example of a security rule that can be implemented on the Firewall illustrated in the
picture below.
Because of to the simplicity of the OpenVPN configurations, problems establishing a connection

are often due to IP or port restrictions on the client and/or server side.
ETHERNET/IP TUNNEL:
You can choose to build either Ethernet (Bridged) or IP (Routed) VPNs with the help of
respectively the TAP or TUN network drivers. TAP/TUN are available on all the platforms and
are already bundled with the Linux 2.4 kernel or higher.
Prefer TUN (default setting) unless you need to pass Ethernet traffic such as NetBIOS inside the
VPN.
To check whether or not the TUN/TAP drivers are properly loaded:
#lsmod | grep tun
tun 12672 1
Note that the "tun" driver is also the TAP driver.
If you don't receive any answer, you can load the kernel module as follows:
#modprobe tun
SERVER and CLIENT
# ETHERNET OR IP TUNNEL
# "dev tun" will create a routed IP
tunnel
dev tun
# "dev tap" will create an Ethernet
tunnel
dev tap
# use "dev tun" or "dev tap" but not
both
OPENVPN SECURITY ARCHITECTURE:
Transparent tunnel:
OpenVPN just tunnels the data without authentication, confidentiality, or integrity. In other words
there is no security checks whatsoever, and the data can be read as it passes through the tunnel.
SERVER and CLIENT
# Client AND Server configs
# No integritiy (hash function
# algorithm)
auth none
# No encryption (cipher
algorithm)
cipher none
Preshared keys:
A secret and permanent key is shared between the VPN gateways.
First create the preshared keys with the preshared keys creation tutorials.
SERVER and CLIENT
# PRESHARED KEYS
# Linux system
static /home/user/openvpn/key.txt
# Windows system
static "C:\\Program
Files\\OpenVPN\\config\\key.txt"
#openvpn /home/teddybear/openvpn/config.txt
>openvpn "C:\Program Files\OpenVPN\config\config.txt"
SSL/TLS:
- SSL/TLS server or client:
SERVER
# SSL/TLS SERVER
tls-server
CLIENT
# SSL/TLS CLIENT
tls-client
- Certificates and public keys:

Each device must have its private and public keys, the latter being included in a certificate.
The CA (Certification Authority) certificate must also be owned by each OpenVPN device.
See the PKI Tutorial to understand the Public Key Infrastructure and know how to create
private keys and certificates.
CLIENT
SERVER
# CERTIFICATES AND PRIVATE
# CERTIFICATES AND PRIVATE
KEY
KEY
# Authority certificate (CA public
# Authority certificate (CA public
key)
key)
ca ca.key
ca ca.key
# Server certificate (server public
# Client certificate (client public
key)
key)
cert server.crt
cert client.crt
# Server private key
# Client private key
key server.key
key client.key
- Diffie-Hellmann (DH) settings:

Once the OpenVPN peers are sure about each other's identity, DH can be used to create a shared
secret key for the hash function and the cipher algorithm.
By combining a DH private key with the other OpenVPN box DH public key, it is possible to
calculate a shared secret that only the two OpenVPN peers know.
See the SSL Tutorial to get information about how to create the DH settings.
SERVER
# Diffie-Hellman settings
dh dh1024.pem
CLIENT
# No DH setting on the client
#
This DH shared secret could be compared to the OpenVPN preshared key.

These keys will be used by the symmetric ciphers and hash functions algorithms as shown in the
two next paragraphs.
CIPHER ALGORITHM
SERVER and CLIENT
# CIPHER ALGORITHM
cipher AES-256-CBC
- The confidentiality is ensured with symmetric ciphers such as 3DES or AES to protect the data
from being read.
The OpenVPN default cipher algorithm is Blowfish.
To check the available algorithms:
#openvpn --show-ciphers
DES-CBC 64 bit default key (fixed)
IDEA-CBC 128 bit default key (fixed)
RC2-CBC 128 bit default key (variable)
DES-EDE-CBC 128 bit default key (fixed)
DES-EDE3-CBC 192 bit default key (fixed)
DESX-CBC 192 bit default key (fixed)
BF-CBC 128 bit default key (variable)
RC2-40-CBC 40 bit default key (variable)
CAST5-CBC 128 bit default key (variable)
RC5-CBC 128 bit default key (variable)
RC2-64-CBC 64 bit default key (variable)
AES-128-CBC 128 bit default key (fixed)
CBC for Cipher Block Chaining is a cryptography operational modes used to encrypt data with a
cipher block algorithm like the AES, DES or Blowfish. CBC uses small piece of data, instead of
processing an entire block at a time, other cryptography operational mode are EBC, OFB, CFB.
CBC mode is recommended.
HASH FUNCTION ALGORITHM

- The Integrity uses hash function algorithms to protect the data from being altered.
HMAC is often used in addition with SHA1 or MD5.
The OpenVPN default hash functions are HMAC-SHA1.
To check the available algorithms:
#openvpn --show-digests
MD2 128 bit digest size
RSA-MD2 128 bit digest size
SHA 160 bit digest size
RSA-SHA 160 bit digest size
SHA1 160 bit digest size
RSA-SHA1 160 bit digest size
DSA-SHA 160 bit digest size
DSA-SHA1-old 160 bit digest size
MDC2 128 bit digest size
RSA-MDC2 128 bit digest size
DSA-SHA1 160 bit digest size
RSA-SHA1-2 160 bit digest size
DSA 160 bit digest size
RIPEMD160 160 bit digest size
RSA-RIPEMD160 160 bit digest size
SERVER and CLIENT
# HASH FUNCTION
ALGORYTHM
auth MD5
"openvpn --show-tls" displays the cipher and message authentication code (MAC) used during
the SSL/TLS negotiation. They should not be confounded with the cipher and MAC used to
secure the OpenVPN tunnel.
IP ADDRESSES:
Choose the IP addresses you want to use inside the tunnel.
Static IP addresses:
In routed mode, two IP addresses (local and remote) inside a 30 bits subnet mask must be chosen.
In bridge mode, one IP address for the local OpenVPN box and a subnet mask including the
server IP address are chosen.
SERVER
# IP ADDRESSING
# IP mode example:
# Server IP: 10.8.0.1 ; Client IP:
10.8.0.2
ifconfig 10.8.0.1 10.8.0.2
# Bridge mode example
# Server IP: 10.8.0.1
ifconfig 10.8.0.1 255.255.255.0
# Use bridged or routed settings
but not
# both
# Client and Server must use the
same
# tunnel mode
CLIENT
# IP ADDRESSING
# IP mode example:
# Server IP: 10.8.0.1 ; Client IP:
10.8.0.2
ifconfig 10.8.0.2 10.8.0.1
# Bridge mode example
# Client IP: 10.8.0.2
ifconfig 10.8.0.2 255.255.255.0
# Use bridged or routed settings
but not
# both
# Client and Server must use the
same
# tunnel mode
Dynamic IP addresses:
In this case, the server owns a static IP address and provides IP addresses to the clients as a
DHCP server.
SERVER
# DHCP SETTINGS
# DHCP range
# Server will take the first IP
address
server 10.8.0.0 255.255.255.0
CLIENT
# CLIENT ACCEPTS SERVER
OPTIONS
# The client should accept options
pushed
# by the server
pull
OPTIONAL SETTINGS:
OpenVPN offers a very large number of optional settings.
Refer to the OpenVPN man page for assistance.
LOG SETTINGS:
The log verbosity is configured from 0 (minimum) to 15 (maximal). For a normal use, the "2"
and "4" verbose levels will already provide sufficient logs.
# Verbosity level.
# 0 -- quiet except for fatal errors.
# 1 -- mostly quiet, but displays non-fatal network errors.
# 3 -- medium output, good for normal operation.
# 9 -- verbose, good for troubleshooting
SERVER and CLIENT
# LOG VERBOSITY
# log verbosity setting, 0=min
15=max
verb 3
OPENVPN USER:
For security reasons, it's always better to run a software without the root privileges.
You can reduce the OpenVPN daemon's privileges after initialization in order to operate as user
"nobody".
Another interesting security point is to limit the right OpenVPN has to access files after
initialization with "chroot".
Note that these two security settings are available under Linux/UNIX systems, but not under
Windows. Another reason to prefer opens source tools like Linux OS ...
SERVER and CLIENT
# OPENVPN SECURITY - Linux
only
# OpenVPN User
user nobody
# After initialization, OpenVPN can
only
# access a directory
# The directory can be empty
# OpenVPN process limitation
chroot /etc/openvpn/
LAUNCH OPENVPN:
Use the following syntax to launch OpenVPN.
#openvpn path-to-config-file
Below are two examples with Linux and Windows. The config file is "config.txt":
#openvpn /home/teddybear/openvpn/config.txt
>openvpn "C:\Program Files\OpenVPN\config\config.txt"
LOG CHECK:
The log should end will the following line:
Initialization Sequence Completed
This indicates that the OpenVPN tunnel has been created successfully.
CONNECTIVITY TESTS:
Ping is a common utility to check IP connectivities.
The VPN gateway should ping the tunnel IP address of the other.
For example, in our scenario, we ping the client tunnel IP address from the server:
ping 10.8.0.2
OPENVPN PROCESS CHECK:
Coming soon ...
Here are some OpenVPN default values:

SETTING:
VALUE:
Src & dest port:
UDP 1194
Tunnel mode:
IP tunnel (tun mode)
Symmetric
cipher:
Blowfish - CBC (128 bits)
Hash functions:
HMAC - SHA1 (160 bits)
Compression:
NO
Tunnel MTU:
1500 bytes
Verbose mode:
Top of the page

OpenVPN - Transparent mode
Even though this is not very useful, OpenVPN is able to establish a tunnel
without encrypting the data inside it meaning that it is possible to read the
data inside the tunnel.
Transparent tunnel:
If you want to secure the tunneled data, use the OpenVPN pre-shared key or
SSL modes:
Encrypted tunnel:
It should be obvious that the OpenVPN transparent mode must be used only
inside a secure network for testing.
Look at the case studies to find examples with OpenVPN in transparent mode.
OpenVPN - Preshared or static keys

The preshared keys OpenVPN mode is easier to implement than the SSL/TLS mode but
with the following disadvantages:
- The shared secret is not renewed.
- The shared secret has be transported on the two peers.
- The VPN peers are not authenticated.
You can create a preshared key very easily with OpenVPN on any platform. Once you
have created a preshared key, you have to copy it onto the other OpenVPN peer.
You should transmit it only via a secure media like SSH or physically with a floppy disk
or an USB key.
To create a key, proceed as follows:
On Linux:
##openvpn --genkey --secret /home/user/key.txt
On Windows:
Let's open the key file we have just created:
The OpenVPN key is composed by hexadecimal characters and divided into four parts.
The first part is used as a key to cipher the data, the second for the hash algorithm key. By
default the key to cipher and decipher the data are similar, the principle being the same for
the Hash algorithm.
The third and fourth part of the OpenVPN key is used in case you want different cipher
(1st part) and decipher (3rd part) keys and different keys to hash the outgoing (2nd part)
or incoming (4th part) data.
Do not confuse the OpenVPN key which is composed of 512 hexadecimal characters with
the keys used by the cipher and hash function algorithm to secure the OpenVPN tunnel
which are composed by hexadecimal characters inside the OpenVPN key.
By default, the blowfish encryption algorithm is used with a 128 bits keys (cipher and
decipher), 160 bits being used for the hash algorithm (outgoing and incoming data).
Each hexadecimal character represents 4 bits of the key meaning, that 128 and 160 bits
will represent respectively (128/4) 32 and (160/4) 40 hexadecimal characters.
In our example (default setting), the hexadecimal characters used for the keys are
displayed in the red squares above.
The characters not used for the keys can be different on the two OpenVPN key files.
If you want to finish your OpenVPN configuration go on with the OpenManiak OpenVPN
configuration tutorial.
Examples with OpenVPN in preshared keys can be found in the case studies.
Public Key Infrastructure (PKI):
PKI is a set of physical devices used to create certificates which bind a user public key to its real
identity.
Concept:
The concept of the PKI (also known as asymmetric cryptography) is based on the fact that each
peer has its own set of private and public key. SSL will use the PKI to authenticate the
OpenVPN peers before transmitting ciphered data.
Private keys and certificates:
The private key of a peer is kept secret and its public key publicly diffused via Certificates.
The goal of a certificate is to certify that a public key belongs to the person who claims to be its
owner (ie: the people owning the mathing private key).
Without certificates, you couldn't be sure that a public key really matches the people who owns
the matching private key.
Certification Authority (CA):
To certify its identity, a certificate is signed by an authority that can be trusted by everyone: the
Certification Autority (CA).
Some companies like VeriSign (No1) and Comodo (No2) have made their business selling
certificates.
It is also possible to create a private CA in an internal network for testing purposes. As a matter
of fact, this is what will be done in our tutorials.
CA certificate:
The CA signs certificates with its private key and publishes its public key under the shape of a
certificate to everyone. (The CA certificate is signed by its own private).
For example, you can check your CA certificates, also called root certificates, on your web
browsers. (click on the web links to see screenshots)
Opera 9: Tools -> Preferences -> Advanced tab -> Security -> Manage certificates Authorities
tab.
FireFox 2: Tools -> Options -> Advanced -> View Certificates -> Authorities tab.
IE 7:
Tools -> Internet Options -> Content tab -> Encryption tab -> Certificates -> Trusted
Root Certification Authorities.
Private key and certificate creation:
The client first creates a private key and a certificate request file using the RSA algorithm. This
file is sent to the CA which will build the client certificate and send it back to the client.
In our scenario, we will use a simpler process as we are in a laboratory.
The client private key is created on the CA machine together with the certificate. The client no
longer needs to send a certificate request to the CA.
The client private key and certificate are transferred from the CA to the client.
Of course this way of creating certificates must only be used in test environements for obvious
security reasons. Indeed, the private key could be captured during its transfer.
In the first process described above, the private key never leaves the client machine.
Asymmetric keys usage:
Two peers called Alice and Bob are used to illustrate the asymmetric keys usages.
- To sign a document
Alice signs a file with her private key. The signature will have the forms of a series of
unreadable characters that can only be decrypted with Alice's public key. So Bob will need
Alice's public key to read in clear text the signature file.
To build a shared key used for the symmetric cryptography

Alice uses her private key with Bob's public key to generate a shared key which will be the
same one generated by Bob using his private key and Alice's public key. This shared secret is
then used by a symmetric algorithms such as DES or AES. It has the advantage of being much
quicker than asymmetric encryption.
To cipher data
When Alice wants to send encrypted data to Bob, Alice uses Bob's certificate to cipher the data.
Thank to his private, Bob will be the only people able to decipher that data.
PKI building:
OpenVPN provides a set of scripts based on OpenSSL in order to make the certificates and keys
generation process easier. We will study the PKI building under Linux and Windows platforms.
To get full details about OpenSSL use, see the OpenSSL website.
On Linux, copy the OpenVPN files in your user directory:
#cp /usr/share/doc/openvpn/examples/easy-rsa/2.0/ /home/user/openvpn/ -R
#cd /home/user/openvpn/
Start the PKI building:
On Windows you may need to create two files:
C:\Program Files\OpenVPN\easy-rsa>init-config.bat
C:\Program Files\OpenVPN\easy-rsa>copy vars.bat.sample vars.bat
The system cannot find the file specified.
C:\Program Files\OpenVPN\easy-rsa>copy openssl.cnf.sample openssl.cnf
1 file(s) copied.
Set the variables:
Edit the "C:\Program Files\OpenVPN\easy-rsa\vars.bat" (Microsoft Windows) or the
"/home/user/openvpn/vars" (Linux) file and set your variables:
set KEY_COUNTRY=US
set KEY_PROVINCE=CA
set KEY_CITY=San Francisco
set KEY_ORG=OpenManiak
set KEY_EMAIL=webmaster@openvpntest.com
Initialise the variables:
C:\Program Files\OpenVPN\easy-rsa>vars
/home/user/openvpn/#. ./vars
Clean the keys folder and remove any old key.
#clean-all.bat
/home/user/openvpn/#./clean-all
1 file(s) copied.
1 file(s) copied.
Certification authority creation:
Create the CA private key and certificate. The certificate includes the public key.
C:\Program Files\OpenVPN\easy-rsa>build-ca.bat
/home/user/openvpn/#./build-ca
Loading 'screen' into random state - done
Generating a 1024 bit RSA private key
...++++++
.........++++++
writing new private key to 'keys\ca.key'
----You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
----Country Name (2 letter code) [US]:
State or Province Name (full name) [CA]:
Locality Name (eg, city) [SanFrancisco]:
Organization Name (eg, company) [OpenManiak]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:master-openmaniak
Email Address [TeddyBear@openvpntest.com]:
Two files will be created:
The CA private key and the CA certificate
The CA certificate which includes the CA public key, is signed by its own private key.
Create the OpenVPN server private key and certificate.
C:\Program Files\OpenVPN\easy-rsa>build-key-server.bat server
/home/user/openvpn/#./build-key-server server

........................................................++++++
.........................++++++
writing new private key to 'keys\server.key'
Common Name (eg, your name or your server's hostname) []:server
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from openssl.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'US'
stateOrProvinceName :PRINTABLE:'CA'
localityName :PRINTABLE:'SanFrancisco'
organizationName :PRINTABLE:'OpenManiak'
commonName :PRINTABLE:'server'
emailAddress :IA5STRING:'TeddyBear@openvpntest.com'
Certificate is to be certified until Sep 6 17:36:18 2017 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
This script has two openssl commands, the first will create a private key and a request certificate
file and the second will create the certificate with the CA private key.
Create the OpenVPN client private key and certificate.

C:\Program Files\OpenVPN\easy-rsa>build-key.bat client
/home/user/openvpn/#./build-key client
........................................................++++++
.........................++++++
writing new private key to 'keys\client.key'
Common Name (eg, your name or your server's hostname) []:client
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from openssl.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'US'
stateOrProvinceName :PRINTABLE:'CA'
localityName :PRINTABLE:'SanFrancisco'
organizationName :PRINTABLE:'OpenManiak'
commonName :PRINTABLE:'server'
emailAddress :IA5STRING:'TeddyBear@openvpntest.com'
Certificate is to be certified until Sep 6 17:36:18 2017 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y

Write out database with 1 new entries
Data Base Updated
That's it!!!
We now have the OpenVPN client and server certificates and private keys. You need to copy the
private keys and certificates on the appropriate Open devices, i.e. the client private key and
certificate must be copied onto the OpenVPN client and same thing for the server.
Very important notice:
As already explained earlier, we used the Certificat Autority (CA) to generate the private keys
and certificates. This process should be only used in a laboratory environment due to the fact that
the CA must transfer the client's private key.
Diffie-Hellmann key exchange
The Diffie-Hellman key exchange is a cryptography process used by two peers to establish a
shared secret known to them only.
Let's create the Diffie-Hellman (DH) settings.
C:\Program Files\OpenVPN\easy-rsa>build-dh.bat
/home/user/openvpn/#./build-dh
Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time
.................................................................
....+.................................................+..........
.....................+.....+......................+..............
.............................................+...................
.....+...........................................................
..............................................................+..
.................+............+............................+.....
.......+.....................................................+...
...+......+..+...........................+.........+...+.........
..............................++*++*++*
Only the OpenVPN server needs the DH settings, not the OpenVPN client.
Top of the page
IP VPN
In this scenario, we will create an OpenVPN tunnel in IP or routed mode with the minimum
required settings.
A Microsoft Windows machine is used as the OpenVPN client, a Linux system as the OpenVPN
server.
The other OpenVPN tunnel mode is called Ethernet or bridge mode. See a case study about this
mode.
1. NO SECURITY
2. PRESHARED KEYS
3. SSL
1. NO SECURITY
Read more information about OpenVPN in transparent mode.
Refer to the OpenVPN tutorial for explanations about the configurations.
WINDOWS VPN BOX - OPENVPN CLIENT:
Configuration file:
The configuration below is stored in the "C:\Program Files\OpenVPN\config\client.txt" file.
# OpenVPN server
remote 100.0.0.2
# Tunnel mode
dev tun
# IP addresses
ifconfig 10.9.0.2 10.9.0.1
# Cipher mode
cipher none
# Authentication mode
auth none
# Log verbosity
verb 2
Lauch OpenVPN
C:\Program Files\OpenVPN\config>openvpn client.txt

Log output:
1
OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct 1 2006

IMPORTANT: OpenVPN's default port number is now 1194, based on an official
port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the
default port.
2
******* WARNING *******: all encryption and authentication features disabled -- all data
will be tunnelled as cleartext
TAP-WIN32 device [Connexion au rseau local 3] opened: \\.\Global\{928ACEB1-D160420A-ADD6-A72E816FC022}.tap
5/
TAP-Win32 MTU=1500
6
Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.9.0.2/255.255.255.252 on
7
interface {928ACEB1-D160-420A-ADD6-A72E816FC022} [DHCP-serv: 10.9.0.1,
8
lease-time:31536000]
Successful ARP Flush on interface [3] {928ACEB1-D160-420A-ADD6-A72E816FC022}
Data Channel MTU parms [ L:1500 D:1450 EF:0 EB:4 ET:0 EL:0 ]
Local Options hash (VER=V4): '00f97e1a'
Expected Remote Options hash (VER=V4): '7cef60b0'
UDPv4 link local (bound): [undef]:1194
9
UDPv4 link remote: 100.0.0.2:1194
10
Peer Connection Initiated with 100.0.0.2:1194
11
12
Legend:
1.
2.
3.
4.
OpenVPN version
Security mode
Cipher algorithm
Hash algorithm
5.
6.
7.
8.
TUN/TAP drivers
Tunnel MTU
Tunnel Local IP
Tunnel Remote IP
9.
10.
11.
12
TCP or UDP port

OpenVPN server IP
Remote OpenVPN peer
OpenVPN status
LINUX VPN BOX - OPENVPN SERVER:

The configuration below is stored in the "/etc/openvpn/server.txt" file.
# Tunnel mode
dev tun
# IP addresses
ifconfig 10.9.0.1 10.9.0.2
# Cipher mode
cipher none
auth none
# Log verbosity
verb 2
Lauch OpenVPN
/etc/openvpn#openvpn server.txt
Read information about how to use OpenVPN startup scripts.
Log output:
1 OpenVPN 2.0.9 i486-pc-linux-gnu [SSL] [LZO] [EPOLL] built on May 21 2007
IMPORTANT: OpenVPN's default port number is now 1194, based on an official port
number
assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
5 will be tunnelled as cleartext
7/ TUN/TAP device tun0 opened
8 ifconfig tun0 10.9.0.1 pointopoint 10.9.0.2 mtu 1500
6 Data Channel MTU parms [ L:1500 D:1450 EF:0 EB:4 ET:0 EL:0 ]
Local Options hash (VER=V4): '7cef60b0'
Expected Remote Options hash (VER=V4): '00f97e1a'
9 UDPv4 link local (bound): [undef]:1194
UDPv4 link remote: [undef]
10 Peer Connection Initiated with 50.0.0.2:1194
12 Initialization Sequence Completed
Continue with the network statistics
Top of the page
2. PRESHARED KEYS
Read explanation about OpenVPN in preshared key mode to know how to create static keys or to
get more information.
Configuration file:
# openVPN server
remote 100.0.0.2
# Tunnel mode
dev tun
# Ip addresses
ifconfig 10.9.0.2 10.9.0.1
# shared key
secret "C:\\Program Files\\OpenVPN\\config\\key.txt"
# Log verbosity
verb 2
Lauch OpenVPN
Log output:
1 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct 1 2006
IMPORTANT: OpenVPN's default port number is now 1194, based on an official port num.
2/3 Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
4 Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
5 TAP-WIN32 device [Local Area Connection 5] opened:
\\.\Global\{E2D87AAD-28F7-432E-8A00-5E67BE6DD464}.tap
6 TAP-Win32 MTU=1500
7 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.9.0.2/255.255.255.252 on
8 interface {E2D87AAD-28F7-432E-8A00-5E67BE6DD464} [DHCP-serv: 10.9.0.1,
lease-time: 31536000]
Successful ARP Flush on interface [4] {E2D87AAD-28F7-432E-8A00-5E67BE6DD464}
Local Options hash (VER=V4): 'd3880969'
Expected Remote Options hash (VER=V4): 'c41bf3b8'
10 UDPv4 link remote: 100.0.0.2:1194
Legend:
1.
2.
3.
4.
OpenVPN version
Security mode
Cipher algorythm
Hash algorythm
5.
6.
7.
8.
TUN/TAP drivers
Tunnel MTU
Tunnel Local IP
Tunnel Remote IP
9.
10.
11.
12
TCP or UDP port

OpenVPN server IP
Remote OpenVPN peer
OpenVPN status

# Tunnel mode
dev tun
# Ip addresses
ifconfig 10.9.0.1 10.9.0.2
# shared key
secret /home/user/key.txt
# Log verbosity
verb 2
Lauch OpenVPN
Log output:
1 OpenVPN 2.0.9 i486-pc-linux-gnu [SSL] [LZO] [EPOLL] built on Mar 2 2007
WARNING: file '/home/po/key.txt' is group or others accessible
5 TUN/TAP device tun0 opened
6/7 ifconfig tun0 10.9.0.1 pointopoint 10.9.0.2 mtu 1500
Local Options hash (VER=V4): 'c41bf3b8'
Expected Remote Options hash (VER=V4): 'd3880969'
Top of the page
3. SSL
Read the SSL OpenVPN mode to know how to create keys and certificates or to get more
information.
Configuration file:
# TLS mode - client
tls-client
# openVPN server
remote 100.0.0.2
# Tunnel mode
dev tun
# IP addresses
ifconfig 10.9.0.2 10.9.0.1
# CA certificate
ca "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\ca.crt"
# client certificate
cert "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\server.crt"
# client private key
key "C:\\Program Files\\OpenVPN\easy-rsa\\keys\\server.key"
# Log verbosity
verb 2
Lauch OpenVPN
Log output:
number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default
port.
WARNING: No server certificate verification method has been enabled. See
http://openvpn.net/howto.html#mitm for more info.
Control Channel MTU parms [ L:1541 D:138 EF:38 EB:0 ET:0 EL:0 ]
5 TAP-WIN32 device [Connexion au rseau local 3] opened: \\.\Global\{928ACEB1-D160420A-ADD6-A72E816FC022}.tap
8 interface {928ACEB1-D160-420A-ADD6-A72E816FC022} [DHCP-serv: 10.9.0.1,
Local Options hash (VER=V4): '4685920e'
9 Expected Remote Options hash (VER=V4): '2e130e6f'
0 UDPv4 link remote: 100.0.0.2:1194
1 TLS Error: local/remote TLS keys are out of sync: 100.0.0.2:1194 [0]
5 VERIFY OK: depth=1, /C=US/ST=CA/L=SanFrancisco/O=OpenManiak/
CN=OpenManiak_CA/emailAddress=me@myhost.mydomain
4 CN=server/emailAddress=me@myhost.mydomain
Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
3 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
4 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
2 [server] Peer Connection Initiated with 100.0.0.2:1194
1
2
Legend:
1.
2.
3.
4.
OpenVPN version
Security mode
Cipher algorithm
Hash algorithm
5.
6.
7.
8.
TUN/TAP drivers
Tunnel MTU
Tunnel Local IP
Tunnel Remote IP
9.
10.
11.
12
TCP or UDP port

13. Client certificat
OpenVPN server IP
14. Server certificat
Remote OpenVPN peer 15. CA certificate
OpenVPN status

# TLS mode - server
tls-server
# Tunnel mode
dev tun
# IP addresses
ifconfig 10.9.0.1 10.9.0.2
# CA certificate
ca ca.crt
# server certificate
cert client.crt
# server private key
key server.key
# Diffie-Hellman Settings
dh dh1024.pem
# Log verbosity
verb 2
Lauch OpenVPN
Log output:
port.
5 TUN/TAP device tun0 opened
6/7 ifconfig tun0 10.9.0.1 pointopoint 10.9.0.2 mtu 1500
Local Options hash (VER=V4): '2e130e6f'
Expected Remote Options hash (VER=V4): '4685920e'
CN=client/emailAddress=me@myhost.mydomain
3 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
2 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
11 [client] Peer Connection Initiated with 50.0.0.2:1194
Top of the page
NETWORK STATISTICS: (similar for the three case studies)

INTERFACES:
C:\>ipconfig
OpenVPN client
Windows IP Configuration
Ethernet adapter Local Area Connection:
Connection-specific DNS
Suffix .
IP Address. . . . . . . . . . . . . . .
Subnet Mask . . . . . . . . . . . . .
Default Gateway . . . . . . . . . . .
:
: 50.0.0.2
: 255.255.255.0
: 50.0.0.1
Ethernet adapter Local Area Connection 1:

Suffix .
IP Address. . . . . . . . . . . . . . . : 10.9.0.2
Subnet Mask . . . . . . . . . . . . . : 255.255.255.252
Default Gateway . . . . . . . . . . . :
OpenVPN server
#ifconfig
eth0 Link encap:Ethernet HWaddr 11:22:33:44:55:66

inet adr:100.0.0.2 Bcast:100.0.0.255 Mask:255.255.255.0
adr inet6: fe80::212:3fff:3344:5566/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX Packets:1641 errors:0 :0 overruns:0 frame:0
TX packets:2130 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:186894 (182.5 KiB) Octets transmis:231430 (226.0 KiB)
Interrupt:16
lo
Link encap:Local Loopback

inet adr:127.0.0.1 Mask:255.0.0.0
adr inet6: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1

RX bytes:128263 (125.2 KiB) TX bytes:128263 (125.2 KiB)
tun Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-000
00-00-00-00
inet adr:10.9.0.1 P-t-P:10.9.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500
Metric:1
ROUTING TABLE:
OpenVPN client
C:\>route print
=========================================================
=====
Interface List
0x1
MS TCP Loopback interface
00 08 02 94
0x2
Intel(R) PRO/100 VM Network Connection - Packet
c1 eb
Scheduler Miniport
00 ff e2 d8
TAP-Win32 Adapter V8 - Packet Scheduler Miniport
7a ad
=========================================================
======
=========================================================
======
Active Routes:
Network
Netmask
Gateway
Interface
Metric
Destination
0.0.0.0
0.0.0.0
50.0.0.1
50.0.0.2
20
255.255.255.25
10.9.0.0
10.9.0.2
10.9.0.2
30
2
255.255.255.25
10.9.0.2
127.0.0.1
127.0.0.1
30
5
255.255.255.25
10.255.255.255
10.9.0.2
10.9.0.2
30
5
0x3
50.0.0.0
50.0.0.2
50.255.255.255
255.255.255.0
255.255.255.25
5
255.255.255.25
5
255.0.0.0
240.0.0.0
240.0.0.0
255.255.255.25
5
255.255.255.25
5
255.255.255.25
5
50.0.0.2
50.0.0.2
20
127.0.0.1
127.0.0.1
20
50.0.0.2
50.0.0.2
20
127.0.0.0
127.0.0.1
127.0.0.1
1
224.0.0.0
10.9.0.2
10.9.0.2
30
224.0.0.0
50.0.0.2
50.0.0.2
20
255.255.255.25
10.9.0.2
10.9.0.2
1
5
255.255.255.25
10.9.0.2
3
1
5
255.255.255.25
50.0.0.2
50.0.0.2
1
5
Default
50.0.0.1
Gateway:
=========================================================
======
Persistent Routes:
None
#route -n
OpenVPN server
Kernel Ip routing table

Destination Gateway
10.9.0.2
0.0.0.0
100.0.0.0
0.0.0.0
0.0.0.0
100.0.0.1
Genmask
255.255.255.255
255.255.255.0
0.0.0.0
Flags
UH
U
UG
Metric
0
0
0
Ref
0
0
0
Use
0
0
0
CONNECTIVITY CHECKS:
OpenVPN client
C:\>tracert 10.9.0.1
Tracing route to 10.9.0.1 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 10.9.0.1
Trace complete.
OpenVPN client
C:\>tracert 100.0.0.2
Iface
tun0
eth0
eth0

1 <1 ms <1 ms <1 ms 50.0.0.1
2 <1 ms <1 ms <1 ms 100.0.0.2
Trace complete.
Top of the page
Ethernet VPN
In this scenario, we will create an OpenVPN tunnel in Ethernet or bridged mode with the
minimum required settings.
A Microsoft Windows machine is used as the OpenVPN client, a Linux system as the OpenVPN
server.
The other OpenVPN tunnel mode is called IP or routed mode. See a case study about this mode.
1. NO SECURITY
2. PRESHARED KEYS
3. SSL
1. NO SECURITY
Read more information about OpenVPN in transparent mode.
Configuration file:
# OpenVPN server
remote 100.0.0.2
# Tunnel mode
dev tap
# IP addresses
ifconfig 10.8.0.2 255.255.255.0
# Cipher mode
cipher none
auth none
# Log verbosity
verb 2
Lauch OpenVPN
Log output:
1
OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct 1 2006

IMPORTANT: OpenVPN's default port number is now 1194, based on an official
port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the
default port.
2
will be tunnelled as cleartext
TAP-WIN32 device [Connexion au rseau local 3] opened: \\.\Global\{928ACEB1-D160420A-ADD6-A72E816FC022}.tap
5/
TAP-Win32 MTU=1500
6
7
8
lease-time:31536000]
Local Options hash (VER=V4): '2f636dfc'
Expected Remote Options hash (VER=V4): '2f636dfc'
9
10
11
12
Legend:
1.
2.
3.
4.
OpenVPN version
Security mode
Cipher algorithm
Hash algorithm
5.
6.
7.
8.
TUN/TAP drivers
Tunnel MTU
Tunnel Local IP
Tunnel Remote IP
9.
10.
11.
12
TCP or UDP port

OpenVPN server IP
Remote OpenVPN peer
OpenVPN status

# Tunnel mode
dev tap
# IP addresses
ifconfig 10.8.0.1 255.255.255.0
# Cipher mode
cipher none
auth none
# Log verbosity
verb 2
Lauch OpenVPN
Log output:
number
5 will be tunnelled as cleartext
7/ TUN/TAP device tap0 opened
8 ifconfig tap0 10.8.0.1 netmask 255.255.255.0 mtu 1500 broadcast 10.8.0.255
Local Options hash (VER=V4): '2f636dfc'
Expected Remote Options hash (VER=V4): '2f636dfc'
Top of the page
2. PRESHARED KEYS
Read explanation about OpenVPN in preshared key mode to know how to create static keys or to
get more information.
Configuration file:
# openVPN server
remote 100.0.0.2
# Tunnel mode
dev tap
# Ip addresses
ifconfig 10.8.0.2 255.255.255.0
# shared key
secret "C:\\Program Files\\OpenVPN\\config\\key.txt"
# Log verbosity
verb 2
Lauch OpenVPN
Log output:
5 TAP-WIN32 device [Local Area Connection 5] opened:
\\.\Global\{E2D87AAD-28F7-432E-8A00-5E67BE6DD464}.tap
8 interface {E2D87AAD-28F7-432E-8A00-5E67BE6DD464} [DHCP-serv: 10.8.0.1,
Successful ARP Flush on interface [4] {E2D87AAD-28F7-432E-8A00-5E67BE6DD464}
Local Options hash (VER=V4): '62f81101'
Expected Remote Options hash (VER=V4): '62f81101'
10 UDPv4 link remote: 100.0.0.2:1194

Legend:
1.
2.
3.
4.
OpenVPN version
Security mode
Cipher algorythm
Hash algorythm
5.
6.
7.
8.
TUN/TAP drivers
Tunnel MTU
Tunnel Local IP
Tunnel Remote IP
9.
10.
11.
12
TCP or UDP port

OpenVPN server IP
Remote OpenVPN peer
OpenVPN status

# Tunnel mode
dev tap
# Ip addresses
ifconfig 10.8.0.1 255.255.255.0
# shared key
secret /home/user/key.txt
# Log verbosity
verb 2
Lauch OpenVPN
Log output:
WARNING: file '/home/po/key.txt' is group or others accessible
5 TUN/TAP device tap0 opened
6/7 ifconfig tap0 10.8.0.1 netmask 255.255.255.0 mtu 1500 broadcast 10.8.0.255
Local Options hash (VER=V4): '1d6953e5'
Expected Remote Options hash (VER=V4): '1d6953e5'

Top of the page
3. SSL
Read the SSL OpenVPN mode to know how to create keys and certificates or to get more
information.
Configuration file:
# TLS mode - client
tls-client
# openVPN server
remote 100.0.0.2
# Tunnel mode
dev tap
# IP addresses
ifconfig 10.8.0.2 255.255.255.0
# CA certificate
ca "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\ca.crt"
# client certificate
cert "C:\\Program Files\\OpenVPN\\easy-rsa\\keys\\server.crt"
# client private key
key "C:\\Program Files\\OpenVPN\easy-rsa\\keys\\server.key"
# Log verbosity
verb 2
Lauch OpenVPN
Log output:
5 port.
WARNING: No server certificate verification method has been enabled. See
6 http://openvpn.net/howto.html#mitm for more info.
7 Control Channel MTU parms [ L:1541 D:138 EF:38 EB:0 ET:0 EL:0 ]
8 TAP-WIN32 device [Connexion au rseau local 3] opened: \\.\Global\{928ACEB1-D160420A-ADD6-A72E816FC022}.tap
TAP-Win32 MTU=1500
1 Local Options hash (VER=V4): '2ea34e3b'
0 Expected Remote Options hash (VER=V4): '2ea34e3b'
1 TLS Error: local/remote TLS keys are out of sync: 100.0.0.2:1194 [0]
4 CN=server/emailAddress=me@myhost.mydomain
Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
4 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
2 [server] Peer Connection Initiated with 100.0.0.2:1194
1
2
Legend:
1.
2.
3.
4.
OpenVPN version
Security mode
Cipher algorithm
Hash algorithm
5.
6.
7.
8.
TUN/TAP drivers
Tunnel MTU
Tunnel Local IP
Tunnel Remote IP
9.
10.
11.
12
TCP or UDP port

13. Client certificat
OpenVPN server IP
14. Server certificat
Remote OpenVPN peer 15. CA certificat
OpenVPN status

# TLS mode - server
tls-server
# Tunnel mode
dev tap
# IP addresses
ifconfig 10.8.0.1 255.255.255.0
# CA certificate
ca ca.crt
# server certificate
cert client.crt
# server private key
key server.key
# Diffie-Hellman Settings
dh dh1024.pem
# Log verbosity
verb 2
Lauch OpenVPN
Log output:
port.
Local Options hash (VER=V4): '2ea34e3b'
Expected Remote Options hash (VER=V4): '2ea34e3b'
CN=client/emailAddress=me@myhost.mydomain
3 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
11 [client] Peer Connection Initiated with 50.0.0.2:1194

Top of the page
NETWORK STATISTICS: (similar for the three case studies)

INTERFACES:
C:\>ipconfig
OpenVPN client
Windows IP Configuration
Ethernet adapter Local Area Connection:
Suffix .
IP Address. . . . . . . . . . . . . . .
Subnet Mask . . . . . . . . . . . . .
Default Gateway . . . . . . . . . . .
:
: 50.0.0.2
: 255.255.255.0
: 50.0.0.1
Ethernet adapter Local Area Connection 1:

Suffix .
IP Address. . . . . . . . . . . . . . . : 10.8.0.2
Subnet Mask . . . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . . . :
OpenVPN server
#ifconfig
eth0 Link encap:Ethernet HWaddr 11:22:33:44:55:66

adr inet6: fe80::212:3fff:3344:5566/64 Scope:Link

RX bytes:186894 (182.5 KiB) Octets transmis:231430 (226.0 KiB)
Interrupt:16
lo
Link encap:Local Loopback

inet adr:127.0.0.1 Mask:255.0.0.0
adr inet6: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
tun 0 Link encap:UNSPEC HWaddr 00:FF:11:22:33:44

inet6 addr: fe80::2ff:cfff:1122:3344/64 Scope:Link
ROUTING TABLE:
OpenVPN client
C:\>route print
=========================================================
=====
Interface List
0x1
MS TCP Loopback interface
00 08 02 94
0x2
Intel(R) PRO/100 VM Network Connection - Packet
c1 eb
Scheduler Miniport
00 ff e2 d8
TAP-Win32 Adapter V8 - Packet Scheduler Miniport
7a ad
=========================================================
======
=========================================================
======
Active Routes:
0x3
Network
Destination
0.0.0.0
10.8.0.0
10.8.0.2
10.255.255.255
50.0.0.0
50.0.0.2
50.255.255.255
Netmask
Gateway
Interface
Metric
0.0.0.0
255.255.255.0
255.255.255.25
5
255.255.255.25
5
255.255.255.0
255.255.255.25
5
255.255.255.25
5
255.0.0.0
240.0.0.0
240.0.0.0
255.255.255.25
5
255.255.255.25
5
255.255.255.25
5
50.0.0.1
10.8.0.2
50.0.0.2
10.8.0.2
20
30
127.0.0.1
127.0.0.1
30
10.8.0.2
10.8.0.2
30
50.0.0.2
50.0.0.2
20
127.0.0.1
127.0.0.1
20
50.0.0.2
50.0.0.2
20
127.0.0.0
127.0.0.1
127.0.0.1
1
224.0.0.0
10.8.0.2
10.8.0.2
30
224.0.0.0
50.0.0.2
50.0.0.2
20
255.255.255.25
10.8.0.2
10.8.0.2
1
5
255.255.255.25
10.8.0.2
3
1
5
255.255.255.25
50.0.0.2
50.0.0.2
1
5
Default
50.0.0.1
Gateway:
=========================================================
======
Persistent Routes:
None
#route -n
OpenVPN server
Kernel Ip routing table

Destination Gateway
10.8.0.2
0.0.0.0
100.0.0.0
0.0.0.0
0.0.0.0
100.0.0.1
Genmask
255.255.255.255
255.255.255.0
0.0.0.0
Flags
UH
U
UG
Metric
0
0
0
Ref
0
0
0
Use
0
0
0
CONNECTIVITY CHECKS:
OpenVPN client
C:\>tracert 10.8.0.1
Iface
tap0
eth0
eth0

1 <1 ms <1 ms <1 ms 10.8.0.1
Trace complete.
OpenVPN client
C:\>tracert 100.0.0.2

1 <1 ms <1 ms <1 ms 50.0.0.1
2 <1 ms <1 ms <1 ms 100.0.0.2
Trace complete.
Top of the page
1. PRESENTATION:
In this advanced case study two sites are connected together through an OpenVPN tunnel in
SSL/TLS mode with some optional and very useful OpenVPN settings.
The major goals of our case study are the following:
- Establish a full protocol connectivity between the two LANs (networks 10.0.1.0/24 and
10.0.2.0/24) through an OpenVPN tunnel on Linux boxes.
This means that the two local networks will see each other as they were in the same physical
network and just separated by a router.
- Permit the LANs users to surf on the Internet (TCP port HTTP,80 and HTTPS,443). Source
Address translation (NAT) will be needed on the Linux Boxes.
- Secure the Linux boxes with Netfilter, the Linux Firewall kernel module.
Top of the page
2. INTERFACES SETTING:
First thing to do is to configure the IP settings on the OpenVPN devices and the LAN desktops.
See the OpenManiak tutorial for more details.
OpenVPN Server
Set the interfaces' IP addresses:
#ifconfig eth0 50.0.0.1 netmask 255.255.255.0
Set the default gateway:
#route add default gateway 50.0.0.100
If you want to keep your IP settings when the system reboots, edit the /etc/network/interfaces file:
#vim /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 50.0.0.1
netmask 255.255.255.0
gateway 50.0.0.100
auto eth1
address 10.0.1.1
netmask 255.255.255.0
OpenVPN Client
Set the interfaces IP addresses:
Set the default gateway:
#route add default gateway 100.0.0.100
If you want to keep your IP settings when the system reboots, edit the /etc/network/interfaces file:
auto lo
auto eth0
address 100.0.0.1
netmask 255.255.255.0
gateway 100.0.0.100
auto eth1
address 10.0.2.1
netmask 255.255.255.0
Local Site A Desktop
IP address:
10.0.1.100
Netmask:
Gateway:
255.255.255.0
10.0.1.1
Local Site B Desktop

IP address:
Netmask:
Gateway:
10.0.2.100
255.255.255.0
10.0.2.1
Top of the page
3. CONFIGURATIONS:
The files used by OpenVPN are put in the /etc/openvpn directory
The OpenVPN machines will have the following files:
openvpn.conf - the OpenVPN configuration file.
ipp.txt (server only) - a IP reservation file used for dynamic IP assignment.
route.txt (server only)- script to add a route on the server when the tunnel is up.
Files created by the certificate authority (CA), see the SSL/PKI tutorial to know how to create
them.
ca.crt - the certificate authority certificate (CA public key).
server.crt or client.crt - the server or client certificate (server or client public key).
server.key or client.key - the server or client private key.
dh1024pem (server only) - the Diffie-Hellman (DH) settings.
openvpn.conf file:
SERVER
# Listening server IP address
local 50.0.0.1
# Local port
lport 2000
# Remote port
rport 2001
# Tunnel mode
dev tap
# CA certificate
ca ca.crt
# Server certificate
CLIENT
# Server WAN IP address
remote 50.0.0.1
# Local port
lport 2001
# Remote port
rport 2000
# Tunnel mode
dev tap
# CA certificate
ca ca.crt
# Client certificate
cert server.crt
# Server private key
key server.key
# Diffie-Hellman
dh dh1024.pem
# DHCP range, server will take
# 10.7.0.1
server 10.7.0.0 255.255.255.248
# IP reservation file
ifconfig-pool-persist ipp.txt
# Push a route to the client
push "route 10.0.1.0
255.255.255.0"
# Encryption
ciper AES-256-CBC
# Authentication
auth MD5
# Compression is activated
comp-lzo
# Allowed clients
max-clients 10
# Reduce the OpenVPN daemon's
# privileges after initialization
# (Linux only)
user nobody
# OpenVPN statistics
status openvpn-status.log
# Verbosity level
verb 2
# Script launched when the tunnel
is
# up
up "./route.txt"
# After initialization, OpenVPN
can
# only access a directory
# (Linux only)
cert client.crt
# Client private key
key client.key
# Encryption
ciper AES-256-CBC
# Authentication
auth MD5
# Compression is activated
comp-lzo
# Reduce the OpenVPN daemon's
# privileges after initialization
# (Linux only)
user nobody
# OpenVPN statistics
status openvpn-status.log
# Verbosity level
verb 2
# After initialization, OpenVPN can

only
# access a directory
# (Linux only)
# The client accepts options pushed
# by the server
pull
Here is a summary of the OpenVPN functionnalities used in our tutorial compared to their default
value.
Optional settings:
Case study
Default settings:
Tunnel mode
DHCP server
Persistant addresses
route push
cipher
auth
compression
Server source port
Server destination port
User
rights
Max-user
"up" script
IP assignment
Verbosity level
dev tap
server 10.7.0.0 255.255.255.248
push "10.0.1.0 255.255.255.0"
cipher AES
auth md5
comp-lzo
lport 2000
rport 2001
user nodody
chroot /etc/openvpn
10
up "route.txt"
ifconfig-pool-persist file_name
verb 2
dev tun
cipher BF-CBC
auth sha1
lport 1194
rport 1194
user root
- (Unlimited)
verb 0
Be sure to add the ".conf" file extension to your configuration file. This is required to use the
/etc/init.d/openvpn script to start OpenVPN automatically.
ipp.txt file:
The file /etc/openvpn/ipp.txt is used to store the IP reservations when the OpenVPN server
dynamically assigns IP addresses to clients.
The syntax is the following:
certificate_client_name,ip_address
The certificate_client_name is the name chosen when creating the client certificate, see the
OpenVPN PKI tutorial. In our case study, we chose client1 as the certificate_client_name.
client1,10.7.0.6
route.txt file:
When the server is up, it will launch the "route.txt" bash script which will add a route on it to
reach the client local network.
#!/bin/bash
route add -net 10.0.2.0/24 gw 10.7.0.6
------------------------------------Last thing to do is to set the files permissions inside the /etc/openvpn directory.
The user teddy has read/write/execute permissions. None else has any permissions at all.
The most important file inside the directory are the private keys (server.key or client.key
depending on which system you are using). If your server public key is captured, this will mean
that all your Open VPN architecture is compromised!
#chmod 700 /etc/openvpn/*
The user teddy is the owner of the files inside the /etc/openvpn directory.
#chown teddy /etc/openvpn/*
Top of the page
4. START OPENVPN
Let's start OpenVPN on the client and the server and check the logs:
#openvpn /etc/openvpn/openvpn.conf
Server log:
WARNING: No server certificate verification method has been enabled.
16 See http://openvpn.net/howto.html#mitm for more info.
LZO compression initialized
Data Channel MTU parms [ L:1586 D:1450 EF:54 EB:135 ET:32 EL:0 AF:3/1 ]
Local Options hash (VER=V4): '579db898'
Expected Remote Options hash (VER=V4): 'a0883d96'
22 chroot to '/etc/openvpn' and cd to '/' succeeded
21 UID set to nobody
8/11 UDPv4 link remote: 50.0.0.1:2000
TLS: Initial packet from 50.0.0.1:2000, sid=100aa16d 662ac586
CN=OpenManiak_CA/emailAddress=opensource@openmaniak.com
CN=server/emailAddress=opensource@openmaniak.com
3 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
4 Data Channel Encrypt: Using 128 bit message hash 'MD5' for HMAC authentication
Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Data Channel Decrypt: Using 128 bit message hash 'MD5' for HMAC authentication
[server] Peer Connection Initiated with 50.0.0.1:2000
SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
17 PUSH: Received control message: 'PUSH_REPLY,route 10.0.1.0 255.255.255.0,

18 route-gateway 10.7.0.1,ifconfig 10.7.0.6 255.255.255.248'
OPTIONS IMPORT: --ifconfig/up options modified
OPTIONS IMPORT: route options modified
6 ifconfig tap0 10.7.0.6 netmask 255.255.255.248 mtu 1500 broadcast 10.7.0.7
route add -net 10.0.1.0 netmask 255.255.255.0 gw 10.7.0.1
Legend:
1.
2.
3.
4.
13.
14.
15.
16.
OpenVPN version
Security mode
Cipher algorithm
Hash algorithm
Client certificat
Server certificat
CA certificat
compression
5. TUN/TAP drivers
6. Tunnel MTU
7. Tunnel Local IP
8. Tunnel Remote IP
17. Route pushed to client
18. IP pushed to client
19. IP reservation
9.
10.
11.
12.
21.
22.
23
OpenVPN server
Local port
Remote port
OpenVPN status
User ID
Process limitation
"up" script
Client log:
WARNING: --keepalive option is missing from server config
Diffie-Hellman initialized with 1024 bit key
TLS-Auth MTU parms [ L:1586 D:138 EF:38 EB:0 ET:0 EL:0 ]
23 ./echo.txt tap0 1500 1586 10.7.0.1 255.255.255.248 init
Data Channel MTU parms [ L:1586 D:1450 EF:54 EB:135 ET:32 EL:0 AF:3/1 ]
22 chroot to '/etc/openvpn' and cd to '/' succeeded
21 UID set to nobody
9 UDPv4 link local (bound): 50.0.0.1:2000
10 UDPv4 link remote: [undef]
MULTI: multi_init called, r=256 v=256
IFCONFIG POOL: base=10.7.0.2 size=5
19 IFCONFIG POOL LIST
client1,10.7.0.6
MULTI: multi_create_instance called
8 100.0.0.1:2001 Re-using SSL/TLS context
16 100.0.0.1:2001 LZO compression initialized
11 100.0.0.1:2001 Control Channel MTU parms [ L:1586 D:138 EF:38 EB:0 ET:0 EL:0 ]
100.0.0.1:2001 Data Channel MTU parms [ L:1586 D:1450 EF:54 EB:135 ET:32 EL:0
AF:3/1 ]
100.0.0.1:2001 Local Options hash (VER=V4): 'a0883d96'

100.0.0.1:2001 Expected Remote Options hash (VER=V4): '579db898'
100.0.0.1:2001 TLS: Initial packet from 100.0.0.1:2001, sid=85abe7b5 a5dcafc0
15 100.0.0.1:2001 VERIFY OK: depth=1, /C=US/ST=CA/L=SanFrancisco/O=OpenManiak/
CN=OpenManiak_CA/emailAddress=opensource@openmaniak.com
13 100.0.0.1:2001 VERIFY OK: depth=0, /C=US/ST=CA/L=SanFrancisco/O=OpenManiak/
CN=client1/emailAddress=opensource@openmaniak.com
3 100.0.0.1:2001 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
4 100.0.0.1:2001 Data Channel Encrypt: Using 128 bit message hash 'MD5' for
HMAC authentication
100.0.0.1:2001 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
100.0.0.1:2001 Data Channel Decrypt: Using 128 bit message hash 'MD5' for
HMAC authentication
2 100.0.0.1:2001 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA,
1024 bit RSA
100.0.0.1:2001 [client1] Peer Connection Initiated with 100.0.0.1:2001
client1/100.0.0.1:2001 PUSH: Received control message: 'PUSH_REQUEST'
17 client1/100.0.0.1:2001 SENT CONTROL [client1]: 'PUSH_REPLY,route 10.0.1.0
18 255.255.255.0,route-gateway 10.7.0.1,ifconfig 10.7.0.6 255.255.255.248' (status=1)
client1/100.0.0.1:2001 MULTI: Learn: 12:5a:a3:22:f7:11 -> client1/100.0.0.1:2001
The ping utility is very useful to test if the tunnel is up.
The server (10.7.0.1) should be able to ping the client (10.7.0.6) and vice versa.
server#ping 10.7.0.6
An init.d script is available to start or stop OpenVPN. Be sure, as indicated in the Configurations
section, that your configuration file are located in the /etc/openvpn directory and have a ".conf"
extension file.
#/etc/init.d/openvpn stop
Stopping virtual private network daemon: openvpn.
#/etc/init.d/openvpn start
Starting virtual private network daemon: openvpn.
#/etc/init.d/openvpn restart
Stopping virtual private network daemon: openvpn.
Starting virtual private network daemon: openvpn(OK).
The logs will be written by default in the /var/log/syslog file.
You can check the OpenVPN process status:
#ps -ef | grep openvpn

PPI
STIM TT
UID PID
C
TIME
D
E
Y
nobody
279
1
2
0 09:59 ?
CMD
/usr/sbin/openvpn
00:00:0
-- writepid
0
/var/run/openvpn.conf.pid
--daemon ovpn-conf
--cd /etc/openvpn
--config
/etc/openvpn/openvpn.conf
Check the routing table on the OpenVPN server:

#route -n
Kernel IP routing table
Destination Gateway
10.7.0.0
0.0.0.0
10.0.2.0
10.7.0.6
50.0.0.0
0.0.0.0
0.0.0.0
50.0.0.100
Genmask
255.255.255.248
255.255.255.0
255.255.255.0
0.0.0.0
Flags
U
UG
U
UG
Metric
0
0
0
0
Ref
0
0
0
0
Use
0
0
0
0
Iface
tap0
tap0
eth0
eth0
Top of the page
5. TCP or UDP OPENED PORTS:

Let's check which UDP or TCP ports are opened:
The goal is to close all the unnecessary opened ports to improve the security by preventing
potential attacks.
Let's identify the TCP and UDP opened ports on our test Linux which is an Ubuntu 7.10 Desktop
Edition.
UDP ports:
#netstat -uaen
-u: UDP
-t: TCP
-a: all
-e: extended
-n: numeric
Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address Foreign Address State User Inode
udp
0
0 0.0.0.0:1025
0.0.0.0:*
105 15129
udp
0
0 50.0.0.1:2000 0.0.0.0:*
0
17810
udp
0
0 0.0.0.0:5353
0.0.0.0:*
105 15128
Let's see which users own the ID "0" and "105".
#cat /etc/passwd
user: status: userid: groupid: description:
root: x:
0:
0:
root:
avahi: x:
105: 105:
Avahi mDNS daemon,,,:
home_directory:
/root:
/var/run/avahi-daemon:
shell
/bin/bash
/bin/false
Avahi is a daemon that allows programs to publish and discover services and hosts running on a
local network with no specific configuration.
This daemon is not needed in our case study so we can either deactivate or uninstall it.
Note that the two avihi ports are already closed on the Ubuntu server edition.
Stop the daemon:
#/etc/init.d/avihi-daemon stop
Deactivate the avahi at startup:
In the /etc/defaut/avahi-daemon file, set the AVAHI_DAEMON_START from "1" to "0":
AVAHI_DAEMON_START=0
Uninstall the daemon:
#apt-get remove avihi-daemon
The unnecessary Avihi daemon is no longer running, so we can now check the UDP ports status
again and see that the OpenVPN port is the only opened UDP port.
#netstat -uaen
udp
0
0 50.0.0.1:2000 0.0.0.0:*
0
17810
TCP ports:
#netstat -taen
Proto Recv-Q Send-Q Local Address Foreign Address State
User Inode
tcp
tcp
tcp
tcp6
0
0
0
0
0 127.0.0.0.1:631 0.0.0.0:*
0 127.0.0.0.1:2207 0.0.0.0:*
0 127.0.0.0.1:2208 0.0.0.0:*
0 :::22
:::*
LISTEN 0
LISTEN 108
LISTEN 0
LISTEN 0
15395
15469
15426
15688
TCP ports 631 (cupsys), 2207 and 2208 (hplip) are printer ports and not needed in our case study.
So we can uninstall the associated services and thus close the ports.
Note that the three printer ports are already closed on the Ubuntu server edition.
#apt-get remove hplip
#apt-get remove cupsys
The unneeded printer daemons are no longer running, we can now check the TCP ports status
again and see that the SSH port is the only opened TCP port.
#netstat -taen
Proto Recv-Q Send-Q Local Address Foreign Address State
User Inode
tcp6
0
0 :::22
:::*
LISTEN 0
15688
Top of the page
6. IPTABLES:
IPtables is a tool needed to configure Netfilter and must be launched as root.
NetFilter is a Linux kernel module available since the kernel version 2.4. It provides three main
functionalities:
- Packet filtering - Accepts or drops packets
- NAT - Changes the source or destination IP address of network packets
- Packet mangling - Modifies packets (as for Quality of Service, QoS)
The goal for us is to open only the needed ports and to close all the other to limit potential attacks
on our Linux systems.
Our case study security strategy is the following:
Filter rules:
- Open the ports used by OpenVPN to generate the tunnel between the two Linux systems.
- Open the 80 and 443 ports to the outside to let the LAN machines surf on the Internet.
- Accept all traffic inside the tunnel.
- Drop all the rest.

OpenVPN Server Linux configuration:
- RESET YOUR IPTABLES SETTINGS:
#iptables -F
-------------------------------------------------------- DEFAULT POLICIES:
Set the rules to deny by default all the incoming and outgoing traffics and accept the forward
traffic (inter-interface routing):
#iptables -P OUTPUT DROP
#iptables -P INPUT DROP
#iptables -P FORWARD ACCEPT
-------------------------------------------------------- OPENVPN RULES:
Authorize the OpenVPN tunnel:
#iptables -A INPUT -i eth0 -p udp -s 100.0.0.1 -d 50.0.0.1 --sport 2001 --dport 2000 -j
ACCEPT
#iptables -A OUTPUT -o eth0 -p udp -s 50.0.0.1 -d 100.0.0.1 --sport 2000 --dport 2001 -j
ACCEPT
Authorize all the traffic inside the tunnel:
#iptables -A INPUT -i tap+ -p all -j ACCEPT
#iptables -A OUTPUT -o tap+ -p all -j ACCEPT
-------------------------------------------------------- LAN INTERFACE
All the traffic to and from the LAN interface (eth1) is accepted:
#iptables -A INPUT -i eth1 -p all -s 10.0.1.0/24 -j ACCEPT
#iptables -A OUTPUT -o eth1 -p all -d 10.0.1.0/24 -j ACCEPT
-------------------------------------------------------- INTERNET ACCESS:
NAT rule:
Users from the site A network must be able to surf on the Internet, this will require NAT settings.
For example, when the Desktop located in Site A wants to access a web page on the Internet, its
source IP address is translated and takes the OpenVPN server WAN IP address. In other words,
10.0.1.100 is translated to 50.0.0.1 and vice versa when the packets come back to the Desktop.
This kind of NAT is called 'masquerade'.
#iptables -t nat -A POSTROUTING -j MASQUERADE
Internet access authorization:
LAN users are allowed to access only HTTP and HTTPS resources:
#iptables -A OUTPUT -p tcp -m multiport --dports 80,443 -o eth0 -m state --state
NEW,ESTABLISHED -j ACCEPT
#iptables -A INPUT -p tcp -m multiport --sports 80,443 -i eth0 -m state --state
ESTABLISHED -j ACCEPT
-------------------------------------------------------- FACULTATIVE RULES:
If you have SSH servers on your OpenVPN machines, you can set the rules to accept the SSH
traffic.
To install a SSH server, you just have to use the following command: "apt-get install opensshserver"
Rules to permit the local SSH client to access a remote SSH server.
#iptables -A OUTPUT -p tcp -o eth0 --dport 22 -s 50.0.0.1 -j ACCEPT
#iptables -A INPUT -p tcp --sport 22 -i eth0 -d 50.0.0.1 -m state --state ESTABLISHED -j
ACCEPT
Rules to permit remote SSH clients to access the local SSH server.
#iptables -A INPUT -p tcp --dport 22 -i eth0 -d 50.0.0.1 -j ACCEPT
#iptables -A OUTPUT -p tcp --sport 22 -o eth0 -s 50.0.0.1 -m state --state ESTABLISHED -j
ACCEPT
For connectivity checks, 50.0.0.1 and 100.0.0.1 can ping each other.
#iptables -A INPUT -p icmp -i eth0 -s 100.0.0.1 -d 50.0.0.1 -j ACCEPT
#iptables -A OUTPUT -p icmp -o eth0 -d 100.0.0.1 -s 50.0.0.1 -j ACCEPT
-------------------------------------------------------- CHECKS
Check the FireWall table:
#iptables -v -L
Chain INPUT (policy DROP 13 packets, 683 bytes)
pkt
bytes target
s
ACCEP
0 0
T
ACCEP
4 272
T
ACCEP
0 0
T
op
in
t
eth
udp -0
tap
0
-+
eth
0
-0
prot
out source
destinatio
n
100.0.0.1 50.0.0.1
0.0.0.0/0
10.0.1.0/2
0.0.0.0/0
4
ACCEP
eth
tcp -*
T
0
336
157
1088 ACCEP
eth
tcp -*
4
T
0
ACCEP icm
eth
-*
T
p
0
ACCEP
eth
tcp -*
T
0
0.0.0.0/0
udp spt:2001
dpt:2000
0.0.0.0/0
0.0.0.0/0
multiport sports
80,443 state
ESTABLISHE
D
100.0.0.1 50.0.0.1
0.0.0.0/0
50.0.0.1
0.0.0.0/0
50.0.0.1
tcp spt:22 state

ESTABLISHE
D
tcp dpt:22
Chain FORWARD (policy ACCEPT 5 packets, 217 bytes)

pkt
op
destinatio
bytes target
prot
in out source
s
t
n
Chain OUTPUT (policy DROP 339 packets, 110K bytes)
pkt
op
destinatio
bytes target
prot
in out source
s
t
n
ACCEP
eth
0 0
udp -- *
50.0.0.1 100.0.0.1
T
0
ACCEP
tap
0
-- *
0.0.0.0/0 0.0.0.0/0
T
+
ACCEP
eth
10.0.1.0/2
0 0
0
-- *
0.0.0.0/0
T
0
4
ACCEP
eth
0 0
tcp -- *
0.0.0.0/0 0.0.0.0/0
T
0
ACCEP icm
eth
4 336
-- *
50.0.0.1 100.0.0.1
T
p
0
ACCEP
eth
0 0
tcp -- *
50.0.0.1 0.0.0.0/0
T
0
2259 ACCEP
eth
173
tcp -- *
50.0.0.1 0.0.0.0/0
4
T
0
Check the NAT table:
udp spt:2000
dpt:2001
multiport dports
80,443
tcp dpt:22
tcp spt:22 state
ESTABLISHE
D
#iptables -L -t nat
Chain INPUT (policy DROP 13 packets, 683 bytes)
pkts bytes target
prot opt in out source
destination
Chain FORWARD (policy ACCEPT 5 packets, 217 bytes)

pkts bytes target
destination
108 9273 MASQUERADE 0
- - any eth0 anywhere
Chain OUTPUT (policy DROP 339 packets, 110K bytes)
pkts bytes target
destination
OpenVPN Client Linux Configuration:

- RESET YOUR IPTABLES SETTINGS:
#iptables -F
-------------------------------------------------------- DEFAULT POLICIES:
Set the rules to deny by default all the incoming and outgoing traffics and accept the forward
traffic (inter-interface routing):
#iptables -P OUTPUT DROP
#iptables -P INPUT DROP
#iptables -P FORWARD ACCEPT
-------------------------------------------------------- OPENVPN RULES:
Authorize the OpenVPN tunnel:
#iptables -A INPUT -i eth0 -p udp -s 50.0.0.1 -d 100.0.0.1 --sport 2000 --dport 2001 -j
ACCEPT
#iptables -A OUTPUT -o eth0 -p udp -s 100.0.0.1 -d 50.0.0.1 --sport 2001 --dport 2000 -j
ACCEPT
Authorize all the traffic inside the tunnel:
#iptables -A INPUT -i tap+ -p all -j ACCEPT
#iptables -A OUTPUT -o tap+ -p all -j ACCEPT
--------------------------------------------------------
- LAN INTERFACE
All the traffic to and from the LAN interface (eth1) is accepted:
#iptables -A INPUT -i eth1 -p all -s 10.0.2.0/24 -j ACCEPT
#iptables -A OUTPUT -o eth1 -p all -d 10.0.2.0/24 -j ACCEPT
-------------------------------------------------------- INTERNET ACCESS:
NAT rules:
Users from the sites B networks must be able to surf on the Internet, this will imply NAT settings.
For example, when the Desktop located in site B wants to access a web page on the Internet, its
source IP address is translated and takes the OpenVPN client WAN IP address. In other words,
10.0.2.100 is translated to 100.0.0.1 and vice versa when the packets come back to the Desktop.
This kind of NAT is called masquerade.
#iptables -t nat -A POSTROUTING -j MASQUERADE
Internet access authorization:
LAN users are allowed to access only HTTP and HTTPS resources:
#iptables -A OUTPUT -p tcp -m multiport --dports 80,443 -o eth0 -j ACCEPT
#iptables -A INPUT -p tcp -m multiport --sports 80,443 -i eth0 -m state --state
-------------------------------------------------------- FACULTATIVE RULES:
If you have SSH servers on your OpenVPN machines, you can set the rules to accept the SSH
traffic.
To install a SSH server, you just have to use the following command: "apt-get install opensshserver"
Rules to permit the local SSH client to access a remote SSH server.
#iptables -A OUTPUT -p tcp -o eth0 --dport 22 -s 100.0.0.1 -j ACCEPT
#iptables -A INPUT -p tcp --sport 22 -i eth0 -d 100.0.0.1 -m state --state ESTABLISHED -j
ACCEPT
Rules to permit remote SSH clients to access the local SSH server.
#iptables -A INPUT -p tcp --dport 22 -i eth0 -d 100.0.0.1 -j ACCEPT
#iptables -A OUTPUT -p tcp --sport 22 -o eth0 -s 100.0.0.1 -m state --state ESTABLISHED
-j ACCEPT
For connectivity checks, 50.0.0.1 and 100.0.0.1 can ping each other.
#iptables -A INPUT -p icmp -i eth0 -s 50.0.0.1 -d 100.0.0.1 -j ACCEPT
#iptables -A OUTPUT -p icmp -o eth0 -d 50.0.0.1 -s 100.0.0.1 -j ACCEPT
Top of the page
7. ROUTING
Network routes
To establish the link between machines inside the LANs of site A and site B, the following routes
need to be added on the Linux VPN devices.
On OpenVPN server: destination network 10.0.2.0 mask 255.255.255.0 gateway 10.7.0.6
On OpenVPN client: destination network 10.0.1.0 mask 255.255.255.0 gateway 10.7.0.1
The two routes are automatically added with our server configuration. The OpenVPN server route
is added through the "route.txt" script and the OpenVPN client route is pushed by the OpenVPN
server.
IP forwarding
IP forwarding is required to transfer packets between the network interfaces of a Linux system.
#echo "1" > /proc/sys/net/ipv4/ip_forward
The command above will add the "1" value inside the /proc/sys/net/ipv4/ip_forward file and thus
activate the IP forwarding.
If you want to keep the IP forwarding after a Linux reboot:
#echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
Top of the page
8. CHECKS:
The clients (10.0.1.100 and 10.0.2.100) should be able to see each other and access HTTTP or
HTTPS resources on the Internet.
LAN to LAN connectivity checks:
The clients (10.0.1.100 and 10.0.2.100) should be able to see each other. The ping and traceroute
commands can be used for this purpose.
From the 10.0.1.100 client which is a Linux machine:
#ping 10.0.2.100
#traceroute 10.0.2.100
traceroute to 10.0.2.100 (10.0.2.100), 30 hops max, 40 byte packets
1 10.0.1.1 (10.0.1.1) 0.521 ms 0.848 ms 1.011 ms
2 10.7.0.6 (10.7.0.6) 0.420 ms 0.472 ms 0505 ms
3 10.0.2.100 (10.0.2.100) 0.538 ms * *
HTTTP Internet access check:
A way to test if the IPtables firewall is set to accept HTTP (TCP port 80) and HTTPS (TCP port
443) traffic is to use a browser or simpler, the Command Line interface (CLI) is to check if the
TCP 80 and TCP 443 ports are opened with the telnet client.
#telnet 100.0.0.100 80
Trying 100.0.0.100...
Connected to 100.0.0.100.
Escape character is '^]'.
Of course, we will see only a banner (Escape character is '^]'.) but this is enough to indicate that
the port is opened.
Here is the result you would obtain when you test a closed port, for instance the FTP 21 port:
#telnet 100.0.0.100 21
Trying 100.0.0.100...
Route Tables:
Server:
Destination Gateway
10.7.0.0
0.0.0.0
10.0.1.0
0.0.0.0
10.0.2.0
10.7.0.6
50.0.0.0
0.0.0.0
0.0.0.0
50.0.0.100
Client:
Genmask
255.255.255.248
255.255.255.0
255.255.255.0
255.255.255.0
0.0.0.0
Flags
U
U
UG
U
UG
Metric
0
0
0
0
0
Ref
0
0
0
0
0
Use
0
0
0
0
0
Iface
tap0
eth1
tap0
eth0
eth0

Destination Gateway
10.7.0.0
0.0.0.0
10.0.2.0
0.0.0.0
10.0.1.0
10.7.0.1
100.0.0.0
0.0.0.0
0.0.0.0
100.0.0.100
Genmask
255.255.255.248
255.255.255.0
255.255.255.0
255.255.255.0
0.0.0.0
Flags
U
U
UG
U
UG
Metric
0
0
0
0
0
Ref
0
0
0
0
0
Use
0
0
0
0
0
Iface
tap0
eth1
tap0
eth0
eth0
TCPdump
TCPdump is used below to check the traffic inside the OpenVPN tunnel in the first example and
on the port 2000 of the Linux WAN interface in the second example. Both examples are
performed on the OpenVPN server.
#tcpdump -i tap0 -n
- n: numeric
- i: interface
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 96 bytes
IP 10.7.0.1 > 10.7.0.6: ICMP echo request, id 1824, seq 60, length 64
IP 10.7.0.6 > 10.7.0.1: ICMP echo reply, id 1824, seq 60, length 64
IP 10.7.0.1 > 10.7.0.6: ICMP echo request, id 1824, seq 61, length 64
#tcpdump -i eth0 port 2000 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
IP 50.0.0.1.2000 > 100.0.0.1.2001: UDP, length 145
IP 100.0.0.1.2001 > 50.0.0.1.2000: UDP, length 145
IP 50.0.0.1.2000 > 100.0.0.1.2001: UDP, length 145
IP 100.0.0.1.2001 > 50.0.0.1.2000: UDP, length 145
IP 50.0.0.1.2000 > 100.0.0.1.2001: UDP, length 145
IP 100.0.0.1.2001 > 50.0.0.1.2000: UDP, length 145
Top of the page
9. STARTUP SCRIPT
OpenVPN
The OpenVPN software is set to be launched automatically when the linux system boots.
To manually set OpenVPN to start automatically at bootup:

#update-rc.d openvpn defaults
To prevent OpenVPN to start automatically at bootup:
#update-rc.d -f openvpn remove
IPtables
The IPtables commands need to be added in a file called "iptables.sh" which will be executed
when the Linux system boots.
The file is stored in the /root directory.
Add a line inside the /etc/crontab file to start the IPtables commands automatically after a reboot:
#vim /etc/crontab
@reboot root /root/iptables.sh >> /dev/null
- OpenVPN server file.
/home/root/iptables.sh
# OpenVPN server IPtables settings
#
#RESET your IPtables settings
iptables -F
#
#DEFAULT POLICIES:
#
iptables -P OUTPUT DROP
iptables -P INPUT DROP
iptables -P FORWARD ACCEPT
#
#Authorize the OpenVPN tunnel:
#
iptables -A INPUT -i eth0 -p udp -s 100.0.0.1 -d 50.0.0.1 --sport 2001 --dport
2000 -j ACCEPT
iptables -A OUTPUT -o eth0 -p udp -s 50.0.0.1 -d 100.0.0.1 --sport 2000
--dport 2001 -j ACCEPT
#
#Authorize all the traffic inside the tunnel:
#
iptables -A INPUT -i tap+ -p all -j ACCEPT
iptables -A OUTPUT -o tap+ -p all -j ACCEPT
#
#All the traffic to and from the LAN interface (eth1) is accepted:
#
iptables -A INPUT -i eth1 -p all -s 10.0.1.0/24 -j ACCEPT
iptables -A OUTPUT -o eth1 -p all -d 10.0.1.0/24 -j ACCEPT
#
#NAT rules:
#
iptables -t nat -A POSTROUTING -j MASQUERADE
#
#LAN users are allowed to access only Internet HTTP and HTTPS resources:
#
iptables -A OUTPUT -p tcp -m multiport --dports 80,443 -o eth0 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --sports 80,443 -i eth0 -m state --state
#
# FACULTATIVE RULES:
#
#Rules to permit the local SSH client to access a remote SSH server
#
iptables -A OUTPUT -p tcp -o eth0 --dport 22 -s 50.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --sport 22 -i eth0 -d 50.0.0.1 -m state --state
#
# Rules to permit remote SSH clients to access the local SSH server
#
iptables -A INPUT -p tcp --dport 22 -i eth0 -d 50.0.0.1 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -o eth0 -s 50.0.0.1 -m state --state
#
#For connectivity checks, 50.0.0.1 and 100.0.0.1 can ping each other.
#
iptables -A INPUT -p icmp -i eth0 -s 100.0.0.1 -d 50.0.0.1 -j ACCEPT
iptables -A OUTPUT -p icmp -o eth0 -d 100.0.0.1 -s 50.0.0.1 -j ACCEPT
- OpenVPN client file.
/home/root/iptables.sh
# OpenVPN client IPtables settings
#
#RESET your IPtables settings
iptables -F
#
#DEFAULT POLICIES:
#
iptables -P OUTPUT DROP
iptables -P INPUT DROP

iptables -P FORWARD ACCEPT
#
#Authorize the OpenVPN tunnel:
#
iptables -A INPUT -i eth0 -p udp -s 50.0.0.1 -d 100.0.0.1 --sport 2000 --dport
2001 -j ACCEPT
iptables -A OUTPUT -o eth0 -p udp -s 100.0.0.1 -d 50.0.0.1 --sport 2001
--dport 2000 -j ACCEPT
#
#Authorize all the traffic inside the tunnel:
#
iptables -A INPUT -i tap+ -p all -j ACCEPT
iptables -A OUTPUT -o tap+ -p all -j ACCEPT
#
#All the traffic to and from the LAN interface (eth1) is accepted:
#
iptables -A INPUT -i eth1 -p all -s 10.0.2.0/24 -j ACCEPT
iptables -A OUTPUT -o eth1 -p all -d 10.0.2.0/24 -j ACCEPT
#
#NAT rules:
#
iptables -t nat -A POSTROUTING -j MASQUERADE
#
#LAN users are allowed to access only Internet HTTP and HTTPS resources:
#
iptables -A OUTPUT -p tcp -m multiport --dports 80,443 -o eth0 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --sports 80,443 -i eth0 -m state --state
#
# FACULTATIVE RULES:
#
#Rules to permit the local SSH client to access a remote SSH server
#
iptables -A OUTPUT -p tcp -o eth0 --dport 22 -s 100.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --sport 22 -i eth0 -d 100.0.0.1 -m state --state
#
# Rules to permit remote SSH clients to access the local SSH server
#
iptables -A INPUT -p tcp --dport 22 -i eth0 -d 100.0.0.1 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -o eth0 -s 100.0.0.1 -m state --state
#
#For connectivity checks, 50.0.0.1 and 100.0.0.1 can ping each other.
#
iptables -A INPUT -p icmp -i eth0 -s 50.0.0.1 -d 100.0.0.1 -j ACCEPT
iptables -A OUTPUT -p icmp -o eth0 -d 50.0.0.1 -s 100.0.0.1 -j ACCEPT
------------------------------------The very last thing to do is to set the /root/iptables.sh file permission.
The user root has read/write/execute permissions. None else has any permissions at all.
#chmod 700 /root/iptables.sh
The user root is the owner of the /root/iptables.sh file.
#chown root /root/iptables.sh
1. PRINCIPLE
The goal of this tutorial is to build a OSI layer two link between two laptops separated by two
Linux and one Windows machines.
To do it, bridges are built on these three machines because, as switches, the bridge operates at the
OSI layer two level. This is different to the routers which work at the OSI layer three and stop the
layer two broadcasts avoiding network saturation.
The bridges on the Windows B and Linux B machines are composed of a network and a virtual
OpenVPN interface made by the Operating system. The bridge on Linux A is composed of two
virtual interfaces and made by OpenVPN.
In this tutorial, OpenVPN is used in bridge and SSL mode. This is required to have multiple
tunnels on a machine and establish an OpenVPN bridge.
You will need to establish a Public key Infrastructure and create a pair of public and private keys
for Linux B (certificate common name is "server"), Windows B ("windows") and Linux B
("linux").
You can also find more information about the OpenVPN advanced options and about how to
secure a Linux OpenVPN box.
2. PICTURE
Top of the page
3. WINDOWS A
On the Windows A laptop, we just need to set an IP address and a subnet mask (10.9.0.111/24).
The default gateway is not needed as we are working in a layer 2 environment.
- Start -> Settings -> "Network Connections"
- Select the network interface -> Right click -> Properties
- Select "Internet Protocol (TCP/IP)"

- Configure the IP address and subnet mask
Top of the page
4. WINDOWS B
WAN interface configuration:
We just need to set an IP address and a subnet mask (50.0.1.2/24). The default gateway is not
needed as we are working in a layer 2 environment.
- Select the network interface -> Right click -> Properties

- Configure the IP address and subnet mask
Bridge Configuration:
- Select the network interfaces member of the bridge.

"Local Area Connection" which is one of the two physical interfaces.
"Local Area Connection 2" which is the virtual OpenVPN interface.
- Right click -> Bridge Connections.
The bridge is created with its two members.
Configure the Bridge IP address:

- Select the bridge -> Right click -> Properties
- Configure the IP address and subnet mask (10.9.0.101/24).
OpenVPN Configuration:
On Windows B, you need to have the following files in the "/etc/openvpn/" directory:
- ca.crt
- linux.crt
- linux.key
- openvpn.conf
The Certificate Authority (CA) certificate.

The "windows" certificate which contains the "windows" public key.
The "windows" private key.
The OpenVPN configuration.
The three first files are provided by the CA and stored in the "C:\Program
Files\OpenVPN\config" folder. Look at the case study introduction at the top of this page for
more information.
The Configuration file is "openvpn.conf" and also stored in the "C:\Program
Files\OpenVPN\config" folder.
# Client mode
tls-client
# Server IP address
remote 50.0.1.1
# Bridge mode
dev tap
# Port
port 2000
# Certificate authority (CA) certificate
ca ca.crt
# "windows" private key
key windows.key
# "windows" public key
cert windows.crt
# Accept data pushed by the server
pull
# verbosity level
verb 2
To start OpenVPN automatically at logon, follow the steps below:
- Start -> Run:
Open the group policy editor:

- gpedit.msc
Computer Configuration -> Administrative Templates -> System -> Logon

- Select "Run these programs at logon" -> Right Click "Properties"
- Click on "Enabled", then on the "Show..." button
- In the "Show Contents" window, Click on the "add" button:

- Enter the following command: 'openvpn "C:\Program Files\OpenVPN\config\openvpn.conf"'.
- Click on "OK".
- Click on "OK".
Windows is now configured to launch OpenVPN automatically at logon.
Top of the page
5. LINUX A
Network Interfaces Configuration:
Configure the interfaces IP address:
To keep your settings after a reboot, edit the "/etc/network/interfaces" file:
auto lo
auto eth0
address 50.0.1.1
netmask 255.255.255.0
auto eth1
address 60.0.1.1
netmask 255.255.255.0
On Linux A, you need to have the following files in the "/etc/openvpn/" directory:
- ca.crt
- server.crt
- server.key
- openvpn.conf
- ipp.txt

The "server" certificate which contains the server public key.
The "server" private key.
The clients IP address reservations.
The three first files are provided by the CA. Look at the case study introduction at the top of this
page for more information.
Let's create the OpenVPN config file.
Be careful to put the configuration file in the "/etc/openvpn" directory and with a ".conf"
extension to be able to use the OpenVPN startup script.

Note the "lport" setting is used to create several tunnels on a device with a single OpenVPN
configuration file.
# Server mode
tls-server
# Bridge mode
dev tap0
# IP settings, server takes 10.9.0.1
server 10.9.0.0 255.255.255.0
# Local port
lport 2000
ca ca.crt
# "server" private key
key server.key
# "server" public key
cert server.crt
# Diffie-Hellman settings
dh dh1024.pem
# Authorises client to client connectivity
client-to-client
# clients IP address reservations
# Verbosity level
verb 2
By default, OpenVPN is automatically launched at user logon.
Top of the page
6. LINUX B
Network Interface Configuration:
auto lo
auto eth0

address 60.0.1.2
netmask 255.255.255.0
Bridge Configuration:
- Install the tools need to build a bridge:
#apt-get install bridge-utils
- Load the bridge kernel module:
#modprobe bridge
- Check that the bridge module is loaded:
#lsmod | grep bridge
- The OpenVPN virtual interface has to be permanently up to be integrated in a bridge:
#openvpn --mktun --dev tap0
- Activate eth1 interface:
#ifconfig eth1 up
- Create the bridge:
#brctl addbr br0
- Add members to the bridge:
#brctl addif br0 eth1
#brctl addif br0 tap0
- Set the bridge IP address:
#ifconfig br0 10.9.0.201 netmask 255.255.255.0
- Check the bridge status:
#brctl show
bridge name
br0
bridge id
8000.0000ab12cd34
STP enabled
no
interfaces
tap0
eth1
The bridge ID begins with "8000" and is followed by the lowest MAC address of its members.
- Check the bridge members:
#brctl showmacs br0
port
no
mac addr
2
00:00:ab:12:cd:34
1
00:04:11:22:33:44
is local?
yes
yes
ageing timer
0.00
0.00
To keep your settings after a reboot, create the following script stored in the "/root/bridge.sh" file:
#!bin/bash
# Load the bridge kernel module
modprobe bridge
# Open permanently the tap0 virtual interface
openvpn --mktun --dev tap0
# Activate eth1 interface
ifconfig eth1 up
# Create the bridge
brctl addbr br0
# Add members to the bridge
brctl addif br0 eth1
brctl addif br0 tap0
# Set the bridge IP address:
ifconfig br0 10.9.0.201 netmask 255.255.255.0
Then you have to add the following line in the "/etc/crontab" file:
#vim /etvc/crontab
@reboot root /root/bridge.sh
On Linux B, you need to have have the following files in the "/etc/openvpn/" directory:
- ca.crt
- linux.crt
- linux.key
- openvpn.conf

The "linux" certificate which contains the "linux" public key.
The "linux" private key.
The three first files are provided by the CA.

Let's create the OpenVPN config file.
Be careful to put the configuration file in the "/etc/openvpn" directory and with a ".conf"
extension to be able to use the OpenVPN startup script.
# Client mode
tls-client
# Server IP address
remote 60.0.1.1
# Bridge mode
dev tap0
# Port
port 2000
ca ca.crt
# "linux" private key
key linux.key
# "linux" public key
cert linux.crt
# Accept data pushed by the server
pull
# verbosity level
verb 2
By default, OpenVPN is automatically launched at user logon.
Top of the page
7. LINUX C
On Linux C, we only need to configure the network interfaces IP address:
auto lo
auto eth0
address 10.9.0.222
netmask 255.255.255.0
Top of the page
8. CHECKS
We are now ready to perform checks to validate that Linux C and Windows A can see each other
(See the case study picture).
LinuxC#ping 10.9.0.111
Linux C can also ping successfully:
- The Linux B bridge
- The Linux B tap0 virtual interface
- The Linux A bridge
- The Windows B bridge
- The Windows A network interface
10.9.0.201
10.9.0.200
10.9.0.1
10.9.0.101
10.9.0.111
Let's check if we really have a layer 2 link and no routing between Linux C and Windows A.
LinuxC#ping 10.9.0.111
Before being able to send ICMP packets with the Ping command, Linux C must know the
Windows A MAC address. That's why Linux C first sends a layer two broadcast
(FF:FF:FF:FF:FF:FF) to find who has the MAC address matching the 10.9.0.222 IP address.
Windows A answers to Linux C and indicates its MAC address.
Linux C now knows Windows A MAC address and can send it icmp packets to see if the network
connectivity is established.
The capture, performed on Windows A, shows that there is an OSI layer two link between Linux
C and Windows A because Windows A receives the layer two broadcast.
It's good to remember that the default behaviour of routers which work at layer 3, are to stop the
layer two broadcasts avoiding a network saturation.
Bridges or Switches, which work at the Layer two level, will let the layer two broadcast pass
through them.
Another test to do to check whether we really have a layer two connectivity between Linux C and
Windows A is to use the Traceroute command. If there is no hop, which represents routing
device, until the destination it means we have our layer two link.
LinuxC#traceroute 10.9.0.111
traceroute to 10.9.0.111 (10.9.0.111), 30 hops max, 40 bytes packets
1 10.9.0.111 (10.9.0.111) 0.134 ms 0.110 ms 0.025 ms
If you don't have the traceroute command, you can easily install it with:
#apt-get install traceroute
Top of the page
9. ANNEX
When you have more than one tunnel on a Windows machine, you need to create new virtual
interfaces. Only one virtual address is created by default when OpenVPN is installed.
In the example below, we create a second OpenVPN virtual interface:
Start -> Programs -> OpenVPN -> "Add a new TAP32-Win32 virtual ethernet adapter".
- We have now our two virtual interfaces tagged as "TAP-Win32 Adapter".
Top of the page
1. PRINCIPLE
2. PICTURE
3. OPENVPN CONFIGURATION
4. QUAGGA CONFIGURATION
5. CHECKS
6. REDONDANCY SCENARIO
7. HUB SITE SCENARIO
1. PRINCIPLES
In this scenario we will associate OpenVPN with an open source router called Quagga to create a
redundant triangle. The Operating systems used are Ubuntu Linux. Note that, while OpenVPN
can be used on either Windows or Linux, Quagga works only on Linux.

The case study principle is that each site has two Internet links with two different providers and
each Internet link supports an OpenVPN tunnel to one of the two other sites.
If a tunnel is shut down due for example to a provider failure, all the traffic will be re-routed
through the other OpenVPN tunnel with the help of the OSPF dynamic routing protocol.
Please note that since this is an advanced scenario, you must fully understand how to use
OpenVPN with preshared keys in IP mode and Quagga.
Use the web links under OpenVPN and Quagga sections to seek help.
Top of the page
2. PICTURE
Top of the page
3. OPENVPN CONFIGURATION
Before proceeding with the OpenVPN configurations, you must understand the following
concepts:
- OpenVPN Bases.
- OpenVPN Static key creation.
- Preshared key & IP mode OpenVPN tunnel creation .
The OpenVPN advanced settings case study can also be consulted for information.
***************************
Each Linux router has two OpenVPN tunnels to the other sites. The security mode is preshared
keys, the tunnel mode is IP or tun, and a different key is used for each of the three links.
The requirements for using several OpenVPN tunnels on the same system are the following:
- The tunnel ports must be different.
- A separate configuration file must be built for each tunnel.
Here is a summary about the tunnels with the client/server designation, the UDP port and the key
file name:
- Site A - Site B Tunnel: A is the server, B the client, port 2003, keyAB.txt
- Site A - Site C Tunnel: A is the server, C the client, port 2001, keyAC.txt
- Site B - Site C Tunnel: B is the server, C the client, port 2002, keyBC.txt
Let's create the OpenVPN config files. In order to use the OpenVPN startup script, the
configuration files should have the .conf extension and they are to be placed in the
/etc/openvpn directory.
Linux Site A
# /etc/openvpn/siteAB.conf
# Site A (server) - Site B (client)
dev tun0
ifconfig 10.7.0.9 10.7.0.10
secret /etc/openvpn/keyAB.txt
verb 2
port 2003
# /etc/openvpn/siteAC.conf
# Site A (server) - Site C (client)
dev tun1
ifconfig 10.7.0.1 10.7.0.2
secret /etc/openvpn/keyAC.txt
verb 2
port 2001
Linux Site B
# /etc/openvpn/siteBA.conf
# Site B (client) - Site A (server)
dev tun0
remote 50.0.2.52
ifconfig 10.7.0.10 10.7.0.9
secret /etc/openvpn/keyAB.txt
verb 2
port 2001
# /etc/openvpn/siteBC.conf
# Site B (server) - Site C (client)
dev tun1
ifconfig 10.7.0.5 10.7.0.6
secret /etc/openvpn/keyBC.txt
verb 2
port 2002
Linux Site C
# /etc/openvpn/siteCA.conf
# Site C (client) - Site A (server)
dev tun0
remote 50.0.1.51
ifconfig 10.7.0.2 10.7.0.1
verb 2
port 2002
# /etc/openvpn/siteCB.conf
# Site C (client) - Site B (server)
dev tun1
remote 60.0.1.61
ifconfig 10.7.0.6 10.7.0.5
verb 2
port 2002
Top of the page
4. QUAGGA CONFIGURATION
Before proceeding to the Quagga configuration, make sure you know all there is to know
about the Quagga install and howto tutorials.
***************************
Three things have to be configured under Quagga:
1. The interface IP addresses.
2. The OSPF advertisements.
3. The OpenVPN gateway routing.
Be careful not to configure the interface IP addresses at the Linux level but only under Quagga.
Site A
Quagga_SiteA#vtysh
configure terminal
interface eth0
description Link to Site C
ip address 50.0.1.51/24
link-detect
interface eth1
description Link to Site B
ip address 50.0.2.52/24
link-detect
interface lo
Virtual Local Network
ip address 10.1.1.1/32
link-detect
!
router ospf
network 10.1.1.0/32 area 0.0.0.0
network 10.7.0.0/30 area 0.0.0.0
network 10.7.0.8/30 area 0.0.0.0
!
ip route 60.0.2.62/32 50.0.2.1
ip route 70.0.1.71/32 50.0.1.1
!
!
-|
|
|
|
|
1. Interfaces IP addresses
|
|
|
|
|
|
-|
|
2. OSPF advertisements
|
-|
3. OpenVPN gateways routing
|
--
Site B
Quagga_SiteB#vtysh
configure terminal
interface eth0
description Link to Site C
ip address 60.0.1.61/24
-|
|
|
link-detect
interface eth1
description Link to Site A
ip address 60.0.2.62/24
link-detect
interface lo
link-detect
!
router ospf
network 10.2.2.2/32 area 0.0.0.0
network 10.7.0.4/30 area 0.0.0.0
network 10.7.0.8/30 area 0.0.0.0
!
ip route 50.0.2.52/32 60.0.2.1
ip route 70.0.2.72/32 60.0.1.1
!
!
|
|
|
|
|
|
|
|
-|
|
|
-|
|
--
Site C
Quagga_SiteC#vtysh
configure terminal
interface eth0
description Link to Site A
ip address 70.0.1.71/24
link-detect
interface eth1
description Link to Site B
ip address 70.0.2.72/24
link-detect
interface lo
link-detect
!
router ospf
network 10.3.3.3/32 area 0.0.0.0
network 10.7.0.0/30 area 0.0.0.0
network 10.7.0.4/30 area 0.0.0.0
!
ip route 60.0.1.61/32 70.0.2.1
ip route 50.0.1.51/32 70.0.1.1
!
!
-|
|
|
|
|
|
|
|
|
|
|
-|
|
|
-|
|
--
*****************************************************************
Activate the IP forwarding on the three Linux systems:
IP forwarding is required to transfer packets between the network interfaces of a Linux system.
See a picture of the Linux kernel routing.
Note that the IP forwarding activation must be done at the Linux level since it is not possible to
do it directly from the Quagga router.
#echo "1" > /proc/sys/net/ipv4/ip_forward
The command above will add the "1" value inside the /proc/sys/net/ipv4/ip_forward file and thus
activate the IP forwarding.
If you want to keep the IP forwarding after a Linux reboot, type:
#echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
It is possible to check the ip_forwarding status at the Quagga router level:
#show ip forwarding
IP forwarding is on
In this case the IP forwarding is activated.
Top of the page
5. CHECKS
Let's check the routing status from the Linux system located in Site A.
First check the openvpn process. You should see two of them, one per tunnel.
Linux_SiteA#ps -ef | grep openvpn
PPI
STIM TT
UID PID
C
TIME CMD
D
E
Y
root 4495 1
0 08:26 ?
00:00:0 /usr/sbin/openvpn
0
--writepid /var/run/openvpn.siteAB.pid
--daemon ovpn-siteAB
--status /var/run/openvpn.siteAB.status
10
root 4502 1
0 08:26 ?
--cd /etc/openvpn
--config /etc/openvpn/siteAB.conf
00:00:0 /usr/sbin/openvpn
0
--writepid /var/run/openvpn.keyAC.pid
--daemon ovpn-keyAC
--status /var/run/openvpn.keyAC.status
10
--cd /etc/openvpn
--config /etc/openvpn/keyAC.conf
Check the routes from the Quagga platform:

Quagga_SiteA#show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route
C>*
C>*
C>*
C>*
C>*
10.1.1.1/32 is directly connected, lo

50.0.1.0/24 is directly connected, eth0
10.7.0.2/32 is directly connected, tun1
S>* 60.0.2.62/32 [1/0] via 50.0.2.1, eth1

S>* 70.0.1.71/32 [1/0] via 50.0.1.1, eth0
O
O
10.7.0.2/32 [110/10] is directly connected, tun1, 00:19:09

O>*
O>*
O>*
O>*
O>*
O>*
10.2.2.2/32 [110/20] via 10.7.0.10, tun0, 00:07:56

10.7.0.6/32 [110/20] via 10.7.0.10, tun0, 00:07:56
10.7.0.9/32 [110/20] via 10.7.0.10, tun0, 00:07:56
10.3.3.3/32 [110/20] via 10.7.0.2, tun1, 00:00:48
10.7.0.1/32 [110/20] via 10.7.0.2, tun1, 00:00:48
10.7.0.5/32 [110/20] via 10.7.0.2, tun1, 00:00:48
Check the OSPF neighbors

Quagga_SiteA#show ip ospf neighbor
Neighbo Pr
Dead
State
Address
r ID
i
Time
Full/DROthe 36.522
10.3.3.3 1
10.7.0.2
r
s
Full/DROthe 33.610 10.7.0.1
10.2.2.2 1
r
s
0
Interface
RXmt Rqst DBsm

L
L
L
tun1:10.7.0.
0
1
tun0:10.7.0.
0
9
Check the OSPF routes.

Quagga_SiteA#show ip ospf route
============ OSPF network routing table ============
N
10.2.2.2/32
[20] area: 0.0.0.0
via 10.7.0.10, tun0
N
10.3.3.3/32
[20] area: 0.0.0.0
via 10.7.0.2, tun1
N
10.7.0.1/32
[20] area: 0.0.0.0
via 10.7.0.2, tun1
N
10.7.0.2/32
[10] area: 0.0.0.0
directly attached to tun1
N
10.7.0.5/32
[20] area: 0.0.0.0
via 10.7.0.2, tun1
N
10.7.0.6/32
[20] area: 0.0.0.0
via 10.7.0.10, tun0
N
10.7.0.9/32
[20] area: 0.0.0.0
via 10.7.0.10, tun0
N
10.7.0.10/32
[10] area: 0.0.0.0
============ OSPF router routing table =============
============ OSPF external routing table ===========
Please note that Quagga shows only the best OSPF routes. For example, for Cisco or Vyatta
routers, the OSPF database contains all the routes learned for a network subnet.
Check the routes at the Linux level.
Quagga_SiteA#route -n
Destination Gateway Genmask
50.0.1.0
0.0.0.0
255.255.255.0
70.0.1.71
50.0.1.1 255.255.255.255
Flags Metric Ref Use Iface

U
0
0 0
eth0
UGH 0
0 0
eth0
50.0.2.0
60.0.2.62
0.0.0.0
50.0.2.1
255.255.255.0
255.255.255.255
U
0
UGH 0
0
0
0
0
eth1
eth1
10.2.2.2
10.7.0.6
10.7.0.9 0
10.7.0.10
10.7.0.10
10.7.0.10
10.7.0.10
0.0.0.0
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
UGH
UGH
UGH
UH
0
0
0
0
0
0
0
0
tun0
tun0
tun0
tun0
20
20
20
0
10.3.3.3
10.7.0.1
10.7.0.2
10.7.0.5
10.7.0.2
10.7.0.2
0.0.0.0
10.7.0.2
255.255.255.255
255.255.255.255
255.255.255.255
255.255.255.255
UGH
UGH
UH
UGH
20
20
0
20
0
0
0
0
0
0
0
0
tun1
tun1
tun1
tun1
Check the opened UDP ports.

Quagga_SiteA#netstat -uae
udp 0
0
*:2001
*:*
root 15387
udp 0
0
*:2003
*:*
root 15352
See detailed information about netstat.
Top of the page
6. REDUNDANCY SCENARIO
It's time to test whether or not the redundancy triangle is working.
In order to do so, we unplug the physical cable connected to the "eth0" interface of Quagga in
Site A. This will simulate an Internet provider failure.
The Site A - Site B OpenVPN tunnel will fail and Quagga in Site A will no longer learn OSPF
networks from Quagga in Site C.
Thus, Quagga A will use the route through Quagga in Site B to reach Site C.
Check the routes from the Quagga router.

Quagga_SiteA#show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route
C>*
C>*
C>*
C>*
C>*
10.1.1.1/32 is directly connected, lo

S>* 60.0.2.62/32 [1/0] via 50.0.2.1, eth1

S>* 70.0.1.71/32 [1/0] via 50.0.1.1, eth0
O
O

O>* 10.2.2.2/32 [110/20] via 10.7.0.10, tun0, 00:11:53

O>* 10.3.3.3/32 [110/30] via 10.7.0.10, tun0, 00:02:18
O>*
O>*
O>*
O>*
10.7.0.1/32 [110/30] via 10.7.0.10, tun0, 00:02:18

10.7.0.5/32 [110/30] via 10.7.0.10, tun0, 00:02:18
10.7.0.6/32 [110/20] via 10.7.0.10, tun0, 00:11:53
10.7.0.9/32 [110/20] via 10.7.0.10, tun0, 00:11:53
When the Site A - Site C tunnel is up, the route for 10.3.3.3/32 is learned as follows:
O>* 10.3.3.3/32 [110/20] via 10.7.0.2, tun1, 00:02:18
Check the OSPF neighbors.
Quagga_SiteA#show ip ospf neighbor
Neighbo Pr
Dead
RXmt Rqst DBsm
State
Address Interface
r ID
i
Time
L
L
L
Full/DROthe 33.610 10.7.0.1 tun0:10.7.0.
10.2.2.2 1
0
0
0
r
s
0
9
Traceroute Quagga in Site C to see if the packets are rerouted through site B.
The traceroute is launched at the Linux level because we need to use the "s" option to specify the
source IP address.
The Traceroute or Ping options are not available under the Quagga platform.
Linux_SiteA#traceroute -s 10.1.1.1 10.3.3.3
traceroute to 10.3.3.3
1 10.7.0.10 (10.7.0.10) 2 10.3.3.3 (10.3.3.3)
(10.3.3.3) from 10.1.1.1, 30 0.588 ms 0.471 ms
0.715 ms 1.734 ms
hops max, 40 byte packets
0.347 ms
0.512 ms
Check the OSPF database.
Quagga_SiteA#show ip ospf database
OSPF Router with ID (10.1.1.1)
Router Link States (Area 0.0.0.0)
Link ID
10.1.1.1
10.2.2.2
10.3.3.3
ADV Router Age

10.1.1.1
240
10.2.2.2
816
10.3.3.3
242
Seq#
0x8000000d
0x80000006
0x80000040
CkSum
0x91df
0xa110
0xbc81
Link count
4
5
4
Check the OSPF routes.

Quagga_SiteA#show ip ospf route
============ OSPF network routing table ============
N
10.2.2.2/32
[20] area: 0.0.0.0
via 10.7.0.10, tun0
10.3.3.3/32
10.7.0.1/32
10.7.0.2/32
10.7.0.5/32
10.7.0.6/32
10.7.0.9/32
10.7.0.10/32
[30] area: 0.0.0.0

via 10.7.0.10, tun0
[30] area: 0.0.0.0
via 10.7.0.10, tun0
[10] area: 0.0.0.0
[30] area: 0.0.0.0
via 10.7.0.10, tun0
[20] area: 0.0.0.0
via 10.7.0.10, tun0
[20] area: 0.0.0.0
via 10.7.0.10, tun0
[10] area: 0.0.0.0
============ OSPF router routing table =============

============ OSPF external routing table ===========
When the Site A - Site C tunnel is up, the route for 10.3.3.3/32 is learned as follows:
N
10.3.3.3/32
[20] area: 0.0.0.0

via 10.7.0.2, tun0
Back to the normal situation

When the internet link at Site A comes up, the OpenVPN tunnel Site A - site C is automatically
rebuilt and at the same time the OSPF advertisements are learned anew from the Quagga router in
Site C.
From Site A, 10.3.3.3 will be learned directly from Site C with a metric of 20 and indirectly
through site B with a metric of 30.
As the route with the lowest metric is elected as the best route, the path to Site C will switch back
to the Site A - Site C OpenVPN tunnel instead of the Site A - Site B - Site C tunnel used during
the provider outage.
Top of the page
7. HUB SITE SCENARIO

In this scenario, Site B is considered as a hub site. The two network links on this site are high
bandwidth. The link Site A - Site C is a low bandwidth phone link used for backup purpose.
If we keep the default OSPF settings, we will be in the same scenario as the one presented at the
top of the page where the three links are active.
If Site A wants to reach Site C via Site B, we must increase the OSPF cost on the Site A - Site C
link to a value superior than the OSPF cost via the Site B which is 30.
For the OpenVPN and Quagga configurations, we can keep the exact same settings as the
scenario presented at the top of the page. We just need to add the OSPF cost values.
Quagga_SiteA#vtysh
configure terminal
interface tun1
ip ospf cost 100
Quagga_SiteC#vtysh
configure terminal
interface tun0
ip ospf cost 100
Quagga in Site A will receive two advertisements for 10.3.3.3 which is the local Site C network.
OSPF Advertisement learned from Quagga in Site C:
10.3.3.3/32
[30] area: 0.0.0.0

via 10.7.0.10, tun0
OSPF Advertisement learned on the Quagga router in Site B:

N
10.3.3.3/32
[110] area: 0.0.0.0

via 10.7.0.2, tun1
Please note that Quagga shows only the best OSPF routes. For example, for Cisco or Vyatta
routers, the OSPF database contains all the routes learned for a network subnet.
With Quagga, we only see the best advertisement with a cost equals to 30 ("show ip ospf route"
command). If the site A - site B tunnel is down, the second OSPF advertisement will be seen on
the screen.
Top of the page

Open VPN

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Open VPN

Загружено:

Авторское право:

Доступные форматы

OPENVPN

CPU consumption: Smaller

4. IPSEC & SSL

TYPE OF SSL VPN:

Negotiate the Cipher Suite to be used during data transfer

Top of the page Key concepts Menu

Also just to remind everyone VPN is different from VPS.

Key concepts Menu

Key concepts Menu

IPSEC - SSL COMPARISON:

4346 (TLS 1.1)

Between Transport and

Let's give some more explanations about the comparison table:

Key concepts Menu

Top of the page

Because of to the simplicity of the OpenVPN configurations, problems establishing a connection

- Certificates and public keys:

- Diffie-Hellmann (DH) settings:

This DH shared secret could be compared to the OpenVPN preshared key.

HASH FUNCTION ALGORITHM

Here are some OpenVPN default values:

Src & dest port:

IP tunnel (tun mode)

Blowfish - CBC (128 bits)

HMAC - SHA1 (160 bits)

Top of the page

OpenVPN - Preshared or static keys

Let's open the key file we have just created:

To build a shared key used for the symmetric cryptography

Loading 'screen' into random state - done

Create the OpenVPN client private key and certificate.

1 out of 1 certificate requests certified, commit? [y/n]y

C:\Program Files\OpenVPN\config>openvpn client.txt

OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct 1 2006

TCP or UDP port

LINUX VPN BOX - OPENVPN SERVER:

TCP or UDP port

LINUX VPN BOX - OPENVPN SERVER:

TCP or UDP port

LINUX VPN BOX - OPENVPN SERVER:

NETWORK STATISTICS: (similar for the three case studies)

Ethernet adapter Local Area Connection 1:

eth0 Link encap:Ethernet HWaddr 11:22:33:44:55:66

Link encap:Local Loopback

RX Packets:929 errors:0 :0 overruns:0 frame:0

Kernel Ip routing table

Tracing route to 10.9.0.1 over a maximum of 30 hops

Tracing route to 100.0.0.2 over a maximum of 30 hops

OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct 1 2006

TCP or UDP port

LINUX VPN BOX - OPENVPN SERVER:

12 Initialization Sequence Completed

TCP or UDP port

LINUX VPN BOX - OPENVPN SERVER:

11 Peer Connection Initiated with 50.0.0.2:1194

TCP or UDP port

LINUX VPN BOX - OPENVPN SERVER:

12 Initialization Sequence Completed

NETWORK STATISTICS: (similar for the three case studies)

Ethernet adapter Local Area Connection 1:

eth0 Link encap:Ethernet HWaddr 11:22:33:44:55:66

TX packets:2130 errors:0 dropped:0 overruns:0 carrier:0

Link encap:Local Loopback

tun 0 Link encap:UNSPEC HWaddr 00:FF:11:22:33:44