Determine the correct object - Each PKCS#11 token can contain several objects. Each object has two distinctive attributes id and label . In order to view the token contents you can use the following command:
$ openvpn --show-pkcs11-objects /usr/lib/pkcs11/<provider> <slot-id> PIN: Token Information: label: Token1 manufacturerID: model: serialNumber: 0104524263233729 flags: 0000040d You can access this token using pkcs11-slot-type "label" --pkcs11-slot "Token1" options. The following objects are available for use with this token. Each object shown below may be used as a parameter to --pkcs11-id-type and --pkcs11-id options. Object Label: AUTH000-20050705B436961C5E5F6D2B Id: 41 54 5f 4b 45 59 45 58 43 48 41 4e 47 45 1b ed 81 a2 96 62 24 c4 a8 0a f1 42 48 10 e6 5d 00 Type: Certificate subject: /CN=User1 serialNumber: 2A5F4854000000000032 notBefore: 050705164745Z Object Label: AUTH000-20050705B436961C5E5F6D2B Id: 41 54 5f 4b 45 59 45 58 43 48 41 4e 47 45 1b ed 81 a2 96 62 24 c4 a8 0a f1 42 48 10 e6 5d 00 Type: Private Key Sign: TRUE Sign Recover: TRUE
Reference to this object can be made by: Label (Recommended): - pkcs11-id-type label pkcs11-id "AUTH000-20050705B436961C5E5F6D2B"
Id: - pkcs11-id-type id
pkcs11-id "41 54 5f 4b 45 59 45 58 43 48 41 4e 47 45 1b ed 81 a2 96 62 24 c4 a8 0a f1 42 48 10 e6 5d 00" < X.509 certificate subject: - pkcs11-id-type subject pkcs11-id "/CN=User1"
Using OpenVPN with PKCS#11 - A typical set of OpenVPN options for PKCS#11 pkcs11-providers /usr/lib/pkcs11/<provider> pkcs11-slot-type label pkcs11-slot "Token1" pkcs11-id-type label pkcs11-id "AUTH000-20050705B436961C5E5F6D2B"
This will select the slot where "Token1" is located, select a certificate and private key based on the label "AUTH000-20050705B436961C5E5F6D2B". - Advanced OpenVPN options for PKCS#11 pkcs11-providers /usr/lib/pkcs11/provider1.so /usr/lib/pkcs11/provider2.so pkcs11-slot-type label pkcs11-slot "Token1" pkcs11-id-type label pkcs11-id "AUTH000-20050705B436961C5E5F6D2B" pkcs11-pin-cache 300 daemon management 127,0.0.1 8888 management-hold management-query-passwords
This will load two providers into OpenVPN, search for the slot where "Token1" is located, select a certificate and private key based on the label "AUTH000-20050705B436961C5E5F6D2B", and use the management interface in order to query passwords. The token will be used for 300 seconds after which the password will be re-queried. -
| | PKCS#11 implementation considerations - Many PKCS#11 providers make use of threads, in order to avoid problems caused by implementation of LinuxThreads (setuid, chroot), it is highly recommend to upgrade to Native POSIX Thread Library (NPTL) enabled glibc if you intend to use PKCS#11. -
| | OpenSC PKCS#11 provider - OpenSC PKCS#11 provider is located at /usr/lib/pkcs11/opensc-pkcs11.so on Unix or at opensc-pkcs11.dll on Windows.
| | OpenSC PKCS#11 provider does not report private key attributes correctly. In order to workaround this issue you should specify the pkcs11-sign-mode sign option. -
| | Difference between PKCS#11 and Microsoft Cryptographic API (CryptoAPI)
| | 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 -
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
| |
Technology VPN 2023
Concerned About Online Privacy? You Need a VPN Router Innovation & Tech Today
What Are VPN audits, and Why Are They So Important? CyberGhost VPN
Choosing HIPAA compliant VPN solutions for your businessTitle CyberNews.com
Stream 'Yellowjackets' worldwide with this VPN Global Village space
| | | | | | | | | | |