PKCS#11 is a free, cross-platform vendor independent standard. CryptoAPI is a Microsoft specific API. Most smart card vendors
provide support for both interfaces. In the Windows environment, the user should select which interface to use.
The current implementation of OpenVPN that uses the MS CryptoAPI ( cryptoapicert option) works well as long as you don't
run OpenVPN as a service. If you wish to run OpenVPN in an administrative environment using a service,
the implementation will not work with most smart cards because of the following reasons:
-
Most smart card providers do not load certificates into the local machine store, so the implementation will be unable
to access the user certificate. -
If the OpenVPN client is running as a service without direct interaction with the end-user,
the service cannot query the user to provide a password for the smart card, causing the password-verification process
on the smart card to fail. -
|
Using the PKCS#11 interface, you can use smart cards with OpenVPN in
any implementation, since PKCS#11 does not access Microsoft stores and
does not necessarily require direct interaction with the end-user.
| |
| | Routing all client traffic (including web-traffic) through the VPN
| | Overview
| By default, when an OpenVPN client is active, only network traffic
to and from the OpenVPN server site will pass over the VPN. General web browsing, for
example, will be accomplished with direct connections that bypass the VPN.
| | In certain cases this behavior might not be desirable -- you might want
a VPN client to tunnel all network traffic through the VPN, including general
internet web browsing. While this type of VPN configuration will exact a performance
penalty on the client, it gives the VPN administrator more control over security policies
when a client is simultaneously connected to both the public internet and the VPN
at the same time.
| | Implementation
| Add the following directive to the server configuration file: -
push "redirect-gateway def1"
If your VPN setup is over a wireless network, where all clients
and the server are on the same wireless subnet, add the local flag: -
push "redirect-gateway local def1"
Pushing the redirect-gateway option to clients will cause
all IP network traffic originating on client machines to pass through
the OpenVPN server. The server will need to be configured to deal with
this traffic somehow, such as by NATing
it to the internet, or routing it through the server site's HTTP proxy.
| | On Linux, you could use a command such as this to NAT the VPN client traffic
to the internet:
| iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
| This command assumes that the VPN subnet is 10.8.0.0/24 (taken from
the server directive in the OpenVPN server configuration) and that the local
ethernet interface is eth0 .
| When redirect-gateway is used, OpenVPN clients will route DNS queries through
the VPN, and the VPN server will need handle them. This can be accomplished
by pushing a DNS server address to connecting clients which will replace
their normal DNS server settings
during the time that the VPN is active. For example: -
push "dhcp-option DNS 10.8.0.1"
will configure Windows clients (or non-Windows clients with some extra server-side scripting)
to use 10.8.0.1 as their DNS server. Any address which is reachable from clients may be used
as the DNS server address.
| | Caveats
| Redirecting all network traffic through the VPN is not entirely a problem-free
proposition. Here are some typical gotchas to be aware of: -
Many OpenVPN client machines connecting to the internet will periodically
interact with a DHCP server to renew their IP address leases. The
redirect-gateway option might prevent the client from reaching
the local DHCP server (because DHCP messages would be routed over the VPN),
causing it to lose its IP address lease.
Issues exist with respect to
pushing DNS addresses to Windows clients. -
Web browsing performance on the client will be noticably slower. -
|
For more information on the mechanics of the redirect-gateway directive, see the
| | manual page .
| |
| | Running an OpenVPN server on a dynamic IP address
| While OpenVPN clients can easily access the server via a dynamic
IP address without any special configuration, things get more interesting
when the server itself is on a dynamic address. While OpenVPN has no trouble
handling the situation of a dynamic server, some extra configuration is required.
| | The first step is to get a dynamic DNS address which can be configured to "follow"
the server every time the server's IP address changes. There are several
dynamic DNS service providers available, such as
| | dyndns.org .
| | The next step is to set up a mechanism so that every time the server's IP address changes,
the dynamic DNS name will be quickly updated with the new IP address, allowing
clients to find the server at its new IP address. There are two basic
ways to accomplish this: -
Use a NAT router appliance with dynamic DNS support (such as
the Linksys BEFSR41 ). Most of the inexpensive
NAT router appliances that are widely available have the capability to update a
dynamic DNS name every time a new DHCP lease is obtained from the ISP. This
setup is ideal when the OpenVPN server box is a single-NIC machine inside the firewall. -
Use a dynamic DNS client application such as
| ddclient to update the dynamic DNS address
whenever the server IP address changes. This setup is ideal when the machine running
OpenVPN has multiple NICs and is acting as a site-wide firewall/gateway. To implement
this setup, you need to set up a script to be run by your DHCP client software every time
an IP address change occurs. This script should (a) run ddclient to notify your dynamic
DNS provider of your new IP address and (b) restart the OpenVPN server daemon. -
| |
The OpenVPN client by default will sense when the server's IP address has changed,
if the client configuration is using a remote directive which references
a dynamic DNS name. The usual chain of events is that (a) the OpenVPN client fails to
receive timely keepalive messages from the server's old IP address, triggering
a restart, and (b) the restart causes the DNS name in the remote directive
to be re-resolved, allowing the client to reconnect to the server at its new IP address.
| | More information can be found in the FAQ .
| |
| | Connecting to an OpenVPN server via an HTTP proxy.
| OpenVPN supports connections through an HTTP proxy, with the following authentication modes: -
No proxy authentication -
Basic proxy authentication -
NTLM proxy authentication -
|
First of all, HTTP proxy usage requires that you use TCP as the tunnel
carrier protocol. So add the following to both client and server configurations: -
proto tcp
Make sure that any proto udp lines in the config files are deleted.
| | Next, add the http-proxy directive to the client configuration file
(see the manual page for a full description of this directive).
| For example, suppose you have an HTTP proxy server
on the client LAN at 192.168.4.1 , which
is listening for connections on port 1080 . Add this to the client config: -
http-proxy 192.168.4.1 1080
Suppose the HTTP proxy requires Basic authentication: -
http-proxy 192.168.4.1 1080 stdin basic
Suppose the HTTP proxy requires NTLM authentication: -
http-proxy 192.168.4.1 1080 stdin ntlm
The two authentication examples above will cause OpenVPN to prompt for
a username/password from standard input. If you would instead like to
place these credentials in a file, replace stdin with a filename,
and place the username on line 1 of this file and the password on line 2.
| |
| | Connecting to a Samba share over OpenVPN
| This example is intended show how OpenVPN clients can connect
to a Samba share over a routed dev tun tunnel. If you are ethernet
bridging ( dev tap ), you probably don't need to follow these instructions, as
OpenVPN clients should see server-side machines in their network neighborhood.
| For this example, we will assume that: -
the server-side LAN uses a subnet of 10.66.0.0/24 , -
the VPN IP address pool uses 10.8.0.0/24 (as cited in the server directive
in the OpenVPN server configuration file), -
the Samba server has an IP address of 10.66.0.4 , and -
the Samba server has already been configured and is reachable
from the local LAN. -
|
If the Samba and OpenVPN servers are running on different machines,
make sure you've followed the section on
| | expanding the scope of the VPN to include additional machines .
| Next, edit your Samba configuration file ( smb.conf ). Make sure the hosts allow
directive will permit OpenVPN clients coming from the 10.8.0.0/24 subnet to connect. For example: -
hosts allow = 10.66.0.0/24 10.8.0.0/24 127.0.0.1
If you are running the Samba and OpenVPN servers on the same machine, you may want
to edit the interfaces directive in the smb.conf file to also listen
on the TUN interface subnet of 10.8.0.0/24 : -
interfaces = 10.66.0.0/24 10.8.0.0/24
If you are running the Samba and OpenVPN servers on the same machine,
connect from an OpenVPN client to a Samba share using the folder name: -
\\10.8.0.1\\sharename
If the Samba and OpenVPN servers are on different machines, use folder name: -
\\10.66.0.4\sharename
For example, from a command prompt window: -
net use z: \\10.66.0.4\sharename /USER:myusername
| |
| | Implementing a load-balancing/failover configuration
| | Client
| The OpenVPN client configuration can refer to multiple
servers for load balancing and failover. For example: -
remote server1.mydomain
remote server2.mydomain
remote server3.mydomain
will direct the OpenVPN client to attempt a connection
with server1, server2, and server3 in that order. If an existing
connection is broken, the OpenVPN client will retry the most
recently connected server, and if that fails, will move on to the next server
in the list. You can also direct the OpenVPN client
to randomize its server list on startup, so that the client load will
be probabilistically spread across the server pool. -
remote-random
If you would also like DNS resolution failures to cause the OpenVPN
client to move to the next server in the list, add the following: -
resolv-retry 60
The 60 parameter tells the OpenVPN client to try resolving each remote
DNS name for 60 seconds before moving on to the next server in the list.
| The server list can also refer to multiple OpenVPN server daemons running
on the same machine, each listening for connections on a different port,
for example: -
remote smp-server1.mydomain 8000
remote smp-server1.mydomain 8001
remote smp-server2.mydomain 8000
remote smp-server2.mydomain 8001
If your servers are multi-processor machines, running multiple OpenVPN daemons
on each server can be advantageous from a performance standpoint.
| | OpenVPN also supports the remote directive referring to a DNS name which
has multiple A records in the zone configuration for the domain. In this
case, the OpenVPN client will randomly choose one of the A records every time
the domain is resolved.
| | Server
| The simplest approach to a load-balanced/failover configuration on the server
is to use equivalent configuration files on each server in the cluster, except
use a different virtual IP address pool for each server. For example:
| server1 -
server 10.8.0.0 255.255.255.0
server2 -
server 10.8.1.0 255.255.255.0
server3 -
server 10.8.2.0 255.255.255.0
| |
| | Hardening OpenVPN Security
| One of the often-repeated maxims of network security is that
one should never place so much trust
in a single security component that its failure causes a catastrophic security breach.
OpenVPN provides several mechanisms to add additional security layers to hedge against
such an outcome.
| | tls-auth
| The tls-auth directive adds an additional HMAC signature to all SSL/TLS
handshake packets for integrity verification. Any UDP packet not bearing the correct
HMAC signature can be dropped without further processing.
The tls-auth HMAC signature provides an additional level
of security above and beyond that provided by SSL/TLS. It can protect against: -
DoS attacks or port flooding on the OpenVPN UDP port. -
Port scanning to determine which server UDP ports are in a listening state. -
Buffer overflow vulnerabilities in the SSL/TLS implementation. -
SSL/TLS handshake initiations from unauthorized machines (while such
handshakes would ultimately fail to authenticate, tls-auth can cut
them off at a much earlier point). -
|
Using tls-auth requires that you generate a shared-secret
key that is used in addition
to the standard RSA certificate/key: -
openvpn --genkey --secret ta.key
This command will generate an OpenVPN static key and write it
to the file ta.key . This key should be copied over a pre-existing
secure channel to the server and all client machines. It can be placed
in the same directory as the RSA .key and .crt files.
| In the server configuration, add: -
tls-auth ta.key 0
In the client configuration, add: -
tls-auth ta.key 1
| | proto udp
| While OpenVPN allows either the TCP or UDP protocol to be
used as the VPN carrier connection, the UDP protocol
will provide better protection against DoS attacks and
port scanning than TCP: -
proto udp
| | user/group (non-Windows only)
| OpenVPN has been very carefully designed to allow root privileges
to be dropped after initialization, and this feature should always
be used on Linux/BSD/Solaris. Without root privileges, a running
OpenVPN server daemon provides a far less enticing target to an attacker. -
user nobody
group nobody
| | chroot (non-Windows only)
| The chroot directive allows you to lock the OpenVPN daemon into
a so-called chroot jail , where the daemon would not be able to access
any part of the host system's filesystem except for the specific directory
given as a parameter to the directive. For example, -
chroot jail
would cause the OpenVPN daemon to cd into the jail subdirectory on
initialization, and would then reorient its root filesystem to this directory
so that it would be impossible thereafter for the daemon to access any files
outside of jail and its subdirectory tree. This is important
from a security perspective, because even if an attacker were able to
compromise the server with a code insertion exploit, the exploit would
be locked out of most of the server's filesystem.
| Caveats: because chroot reorients the filesystem (from the perspective of
the daemon only), it is necessary to place any files which OpenVPN might
need after initialization in the jail directory, such as: -
the crl-verify file, or -
the client-config-dir directory. -
| Larger RSA keys
| The RSA key size is controlled by the KEY_SIZE variable in the
easy-rsa/vars file, which must be set before any keys are generated.
Currently set to 1024 by default, this value
can reasonably be increased to 2048 with no negative impact on VPN
tunnel performance, except for a slightly slower SSL/TLS renegotiation
handshake which occurs once per client per hour, and a much slower one-time
Diffie Hellman parameters generation process using the
easy-rsa/build-dh script.
| | Larger symmetric keys
| By default OpenVPN uses Blowfish , a 128 bit symmetrical cipher.
| OpenVPN automatically supports any cipher which is supported by the
OpenSSL library, and as such can support ciphers which use large key
sizes. For example, the 256-bit version of AES (Advanced Encryption Standard)
can be used by adding the following to both server and client configuration files: -
cipher AES-256-CBC
| | Keep the root key ( ca.key ) on a standalone
machine without a network connection
| One of the security benefits of using an X509 PKI (as OpenVPN does) is that
the root CA key ( ca.key ) need not be present on the OpenVPN server
machine. In a high security environment, you might want to specially designate
a machine for key signing purposes, keep the machine well-protected physically,
and disconnect it from all networks. Floppy disks can be used to move key
files back and forth, as necessary. Such measures make it extremely difficult
for an attacker to steal the root key, short of physical theft of the key
signing machine.
| |
| | Revoking Certificates
| Revoking a certificate means to invalidate a previously
signed certificate so
that it can no longer be used for authentication purposes.
| Typical reasons for wanting to revoke a certificate include: -
The private key associated with the certificate is compromised or stolen. -
The user of an encrypted private key forgets the password on the key. -
You want to terminate a VPN user's access. -
| Example
| As an example, we will revoke the client2 certificate, which we
generated above in the "key generation" section of the HOWTO.
| First open up a shell or command prompt window and cd to the easy-rsa
directory as you did in the "key generation" section above. On Linux/BSD/Unix: -
. ./vars
./revoke-full client2
On Windows: -
vars
revoke-full client2
You should see output similar to this:
| Using configuration from /root/openvpn/20/openvpn/tmp/easy-rsa/openssl.cnf
DEBUG[load_index]: unique_subject = "yes"
Revoking Certificate 04.
Data Base Updated
Using configuration from /root/openvpn/20/openvpn/tmp/easy-rsa/openssl.cnf
DEBUG[load_index]: unique_subject = "yes"
client2.crt: /C=KG/ST=NA/O=OpenVPN-TEST/CN=client2/emailAddress=me@myhost.mydomain
error 23 at 0 depth lookup:certificate revoked
| Note the "error 23" in the last line. That is what you want to see, as it
indicates that a certificate verification of the revoked certificate failed.
| The revoke-full script will generate a CRL (certificate revocation list) file
called crl.pem in the keys subdirectory. The file should be copied to
a directory where the OpenVPN server can access it, then CRL verification
should be enabled in the server configuration: -
crl-verify crl.pem
Now all connecting clients will have their client
certificates verified against
the CRL, and any positive match will result in the connection
being dropped.
| | CRL Notes
When the crl-verify option is used in OpenVPN, the CRL file will be re-read
any time a new client connects or an existing client renegotiates the SSL/TLS connection
(by default once per hour). This means that you can update the CRL file while the
OpenVPN server daemon is running, and have the new CRL take effect immediately
for newly connecting clients. If the client whose certificate
you are revoking is already connected,
you can restart the server via a signal (SIGUSR1 or SIGHUP) and flush all clients,
or you can telnet to the
| management interface and explicitly
kill the specific client instance object on the server without disturbing
other clients. -
While the crl-verify directive can be used on both the OpenVPN server and clients,
it is generally unnecessary to distribute a CRL file to clients unless a server certificate
has been revoked. Clients don't need to know about other client certificates which have
been revoked because
| clients shouldn't be accepting direct connections from other clients
in the first place. -
The CRL file is not secret, and should be made world-readable so that the OpenVPN
daemon can read it after root privileges have been dropped. -
If you are using the chroot directive, make sure to put a copy of
the CRL file in the chroot directory, since unlike most other files which
OpenVPN reads, the CRL file will be read after the chroot
call is executed, not before. -
A common reason why certificates need to be revoked is that the user
encrypts their private key with a password, then forgets the password. By revoking
the original certificate, it is possible to generate a new certificate/key pair with
the user's original common name. -
|
| |
| | Important Note on possible "Man-in-the-Middle" attack if clients do
not verify the certificate of the server they are connecting to.
| To avoid a possible Man-in-the-Middle attack where an authorized
client tries to connect to another client by impersonating the
server, make sure to enforce some kind of server certificate
verification by clients. There are currently five different ways
of accomplishing this, listed in the order of preference: -
[OpenVPN 2.1 and above]
Build your server certificates with specific key usage and
extended key usage. The RFC3280 determine that the following
attributes should be provided for TLS connections:
-
| Mode | Key usage | Extended key usage |
| Client = digitalSignature - | TLS Web Client Authentication
| | keyAgreement
| | digitalSignature, keyAgreement
| | Server = digitalSignature, keyEncipherment - | TLS Web Server Authentication
| | digitalSignature, keyAgreement
You can build your server certificates with the build-key-server
script (see the easy-rsa documentation for more
info). This will designate the certificate as a
server-only certificate by setting the right attributes.
Now add the following line to your client configuration: -
remote-cert-tls server
-
[OpenVPN 2.0 and below]
Build your server certificates with the build-key-server
script (see the easy-rsa documentation for more
info). This will designate the certificate as a
server-only certificate by setting nsCertType =server.
Now add the following line to your client configuration: -
ns-cert-type server
This will block clients from connecting to any
server which lacks the nsCertType =server designation
in its certificate, even if the certificate has been
signed by the ca file in the OpenVPN configuration
file. -
Use the tls-remote directive on the client to
accept/reject the server connection based on the common
name of the server certificate. -
Use a tls-verify script or plugin to accept/reject the
server connection based on a custom test of the server
certificate's embedded X509 subject details. -
Sign server certificates with one CA and client certificates
with a different CA. The client configuration ca directive should
reference the server-signing CA file, while the server configuration ca
directive should reference the client-signing CA file. -
|
| | Sample OpenVPN 2.0 configuration files
| |
| | sample-config-files/server.conf
| #################################################
# Sample OpenVPN 2.0 config file for #
# multi-client server. #
# #
# This file is for the server side #
# of a many-clients <-> one-server #
# OpenVPN configuration. #
# #
# OpenVPN also supports #
# single-machine <-> single-machine #
# configurations (See the Examples page #
# on the web site for more info). #
# #
# This config should work on Windows #
# or Linux/BSD systems. Remember on #
# Windows to quote pathnames and use #
# double backslashes, e.g.: #
# "C:\\Program Files\\OpenVPN\\config\\foo.key" #
# #
# Comments are preceded with '#' or ';' #
#################################################
# Which local IP address should OpenVPN
# listen on? (optional)
;local a.b.c.d
# Which TCP/UDP port should OpenVPN listen on?
# If you want to run multiple OpenVPN instances
# on the same machine, use a different port
# number for each one. You will need to
# open up this port on your firewall.
port 1194
# TCP or UDP server?
;proto tcp
proto udp
# "dev tun" will create a routed IP tunnel,
# "dev tap" will create an ethernet tunnel.
# Use "dev tap0" if you are ethernet bridging
# and have precreated a tap0 virtual interface
# and bridged it with your ethernet interface.
# If you want to control access policies
# over the VPN, you must create firewall
# rules for the the TUN/TAP interface.
# On non-Windows systems, you can give
# an explicit unit number, such as tun0.
# On Windows, use "dev-node" for this.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev tun
# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel if you
# have more than one. On XP SP2 or higher,
# you may need to selectively disable the
# Windows firewall for the TAP adapter.
# Non-Windows systems usually don't need this.
;dev-node MyTap
# SSL/TLS root certificate (ca), certificate
# (cert), and private key (key). Each client
# and the server must have their own cert and
# key file. The server and all clients will
# use the same ca file.
#
# See the "easy-rsa" directory for a series
# of scripts for generating RSA certificates
# and private keys. Remember to use
# a unique Common Name for the server
# and each of the client certificates.
#
# Any X509 key management system can be used.
# OpenVPN can also use a PKCS #12 formatted key file
# (see "pkcs12" directive in man page).
ca ca.crt
cert server.crt
key server.key # This file should be kept secret
# Diffie hellman parameters.
# Generate your own with:
# openssl dhparam -out dh1024.pem 1024
# Substitute 2048 for 1024 if you are using
# 2048 bit keys.
dh dh1024.pem
# Configure server mode and supply a VPN subnet
# for OpenVPN to draw client addresses from.
# The server will take 10.8.0.1 for itself,
# the rest will be made available to clients.
# Each client will be able to reach the server
# on 10.8.0.1. Comment this line out if you are
# ethernet bridging. See the man page for more info.
server 10.8.0.0 255.255.255.0
# Maintain a record of client <-> virtual IP address
# associations in this file. If OpenVPN goes down or
# is restarted, reconnecting clients can be assigned
# the same virtual IP address from the pool that was
# previously assigned.
ifconfig-pool-persist ipp.txt
# Configure server mode for ethernet bridging.
# You must first use your OS's bridging capability
# to bridge the TAP interface with the ethernet
# NIC interface. Then you must manually set the
# IP/netmask on the bridge interface, here we
# assume 10.8.0.4/255.255.255.0. Finally we
# must set aside an IP range in this subnet
# (start=10.8.0.50 end=10.8.0.100) to allocate
# to connecting clients. Leave this line commented
# out unless you are ethernet bridging.
;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100
# Push routes to the client to allow it
# to reach other private subnets behind
# the server. Remember that these
# private subnets will also need
# to know to route the OpenVPN client
# address pool (10.8.0.0/255.255.255.0)
# back to the OpenVPN server.
;push "route 192.168.10.0 255.255.255.0"
;push "route 192.168.20.0 255.255.255.0"
# To assign specific IP addresses to specific
# clients or if a connecting client has a private
# subnet behind it that should also have VPN access,
# use the subdirectory "ccd" for client-specific
# configuration files (see man page for more info).
# EXAMPLE: Suppose the client
# having the certificate common name "Thelonious"
# also has a small subnet behind his connecting
# machine, such as 192.168.40.128/255.255.255.248.
# First, uncomment out these lines:
;client-config-dir ccd
;route 192.168.40.128 255.255.255.248
# Then create a file ccd/Thelonious with this line:
# iroute 192.168.40.128 255.255.255.248
# This will allow Thelonious' private subnet to
# access the VPN. This example will only work
# if you are routing, not bridging, i.e. you are
# using "dev tun" and "server" directives.
# EXAMPLE: Suppose you want to give
# Thelonious a fixed VPN IP address of 10.9.0.1.
# First uncomment out these lines:
;client-config-dir ccd
;route 10.9.0.0 255.255.255.252
# Then add this line to ccd/Thelonious:
# ifconfig-push 10.9.0.1 10.9.0.2
# Suppose that you want to enable different
# firewall access policies for different groups
# of clients. There are two methods:
# (1) Run multiple OpenVPN daemons, one for each
# group, and firewall the TUN/TAP interface
# for each group/daemon appropriately.
# (2) (Advanced) Create a script to dynamically
# modify the firewall in response to access
# from different clients. See man
# page for more info on learn-address script.
;learn-address ./script
# If enabled, this directive will configure
# all clients to redirect their default
# network gateway through the VPN, causing
# all IP traffic such as web browsing and
# and DNS lookups to go through the VPN
# (The OpenVPN server machine may need to NAT
# the TUN/TAP interface to the internet in
# order for this to work properly).
# CAVEAT: May break client's network config if
# client's local DHCP server packets get routed
# through the tunnel. Solution: make sure
# client's local DHCP server is reachable via
# a more specific route than the default route
# of 0.0.0.0/0.0.0.0.
;push "redirect-gateway"
# Certain Windows-specific network settings
# can be pushed to clients, such as DNS
# or WINS server addresses. CAVEAT:
# http://openvpn.net/#dhcpcaveats
;push "dhcp-option DNS 10.8.0.1"
;push "dhcp-option WINS 10.8.0.1"
# Uncomment this directive to allow different
# clients to be able to "see" each other.
# By default, clients will only see the server.
# To force clients to only see the server, you
# will also need to appropriately firewall the
# server's TUN/TAP interface.
;client-to-client
# Uncomment this directive if multiple clients
# might connect with the same certificate/key
# files or common names. This is recommended
# only for testing purposes. For production use,
# each client should have its own certificate/key
# pair.
#
# IF YOU HAVE NOT GENERATED INDIVIDUAL
# CERTIFICATE/KEY PAIRS FOR EACH CLIENT,
# EACH HAVING ITS OWN UNIQUE "COMMON NAME",
# UNCOMMENT THIS LINE OUT.
;duplicate-cn
# The keepalive directive causes ping-like
# messages to be sent back and forth over
# the link so that each side knows when
# the other side has gone down.
# Ping every 10 seconds, assume that remote
# peer is down if no ping received during
# a 120 second time period.
keepalive 10 120
# For extra security beyond that provided
# by SSL/TLS, create an "HMAC firewall"
# to help block DoS attacks and UDP port flooding.
#
# Generate with:
# openvpn --genkey --secret ta.key
#
# The server and each client must have
# a copy of this key.
# The second parameter should be '0'
# on the server and '1' on the clients.
;tls-auth ta.key 0 # This file is secret
# Select a cryptographic cipher.
# This config item must be copied to
# the client config file as well.
;cipher BF-CBC # Blowfish (default)
;cipher AES-128-CBC # AES
;cipher DES-EDE3-CBC # Triple-DES
# Enable compression on the VPN link.
# If you enable it here, you must also
# enable it in the client config file.
comp-lzo
# The maximum number of concurrently connected
# clients we want to allow.
;max-clients 100
# It's a good idea to reduce the OpenVPN
# daemon's privileges after initialization.
#
# You can uncomment this out on
# non-Windows systems.
;user nobody
;group nobody
# The persist options will try to avoid
# accessing certain resources on restart
# that may no longer be accessible because
# of the privilege downgrade.
persist-key
persist-tun
# Output a short status file showing
# current connections, truncated
# and rewritten every minute.
status openvpn-status.log
# By default, log messages will go to the syslog (or
# on Windows, if running as a service, they will go to
# the "\Program Files\OpenVPN\log" directory).
# Use log or log-append to override this default.
# "log" will truncate the log file on OpenVPN startup,
# while "log-append" will append to it. Use one
# or the other (but not both).
;log openvpn.log
;log-append openvpn.log
# Set the appropriate level of log
# file verbosity.
#
# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 3
# Silence repeating messages. At most 20
# sequential messages of the same message
# category will be output to the log.
;mute 20
| |
| | sample-config-files/client.conf
| ##############################################
# Sample client-side OpenVPN 2.0 config file #
# for connecting to multi-client server. #
# #
# This configuration can be used by multiple #
# clients, however each client should have #
# its own cert and key files. #
# #
# On Windows, you might want to rename this #
# file so it has a .ovpn extension #
##############################################
# Specify that we are a client and that we
# will be pulling certain config file directives
# from the server.
client
# Use the same setting as you are using on
# the server.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev tun
# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel
# if you have more than one. On XP SP2,
# you may need to disable the firewall
# for the TAP adapter.
;dev-node MyTap
# Are we connecting to a TCP or
# UDP server? Use the same setting as
# on the server.
;proto tcp
proto udp
# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote my-server-1 1194
;remote my-server-2 1194
# Choose a random host from the remote
# list for load-balancing. Otherwise
# try hosts in the order specified.
;remote-random
# Keep trying indefinitely to resolve the
# host name of the OpenVPN server. Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite
# Most clients don't need to bind to
# a specific local port number.
nobind
# Downgrade privileges after initialization (non-Windows only)
;user nobody
;group nobody
# Try to preserve some state across restarts.
persist-key
persist-tun
# If you are connecting through an
# HTTP proxy to reach the actual OpenVPN
# server, put the proxy server/IP and
# port number here. See the man page
# if your proxy server requires
# authentication.
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]
# Wireless networks often produce a lot
# of duplicate packets. Set this flag
# to silence duplicate packet warnings.
;mute-replay-warnings
# SSL/TLS parms.
# See the server config file for more
# description. It's best to use
# a separate .crt/.key file pair
# for each client. A single ca
# file can be used for all clients.
ca ca.crt
cert client.crt
key client.key
# Verify server certificate by checking
# that the certicate has the nsCertType
# field set to "server". This is an
# important precaution to protect against
# a potential attack discussed here:
#
# To use this feature, you will need to generate
# your server certificates with the nsCertType
# field set to "server". The build-key-server
# script in the easy-rsa folder will do this.
;ns-cert-type server
# If a tls-auth key is used on the server
# then every client must also have the key.
;tls-auth ta.key 1
# Select a cryptographic cipher.
# If the cipher option is used on the server
# then you must also specify it here.
;cipher x
# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
comp-lzo
# Set log file verbosity.
verb 3
# Silence repeating messages
;mute 20
| | Open VPN
- |
| | | | | | | | | | | | | |
Español
Facebook 
Google 
Yahoo! 
MSN Hotmail 
Twitter 
Del.icio.us 
Digg 
StumbleUpon 
Technorati 
Blinklist 
Furl 
Reddit