- •Credits
- •About the Author
- •About the Reviewers
- •www.PacktPub.com
- •Table of Contents
- •Preface
- •Introduction
- •Shortest setup possible
- •OpenVPN secret keys
- •Multiple secret keys
- •Plaintext tunnel
- •Routing
- •Configuration files versus the command-line
- •Complete site-to-site setup
- •3-way routing
- •Introduction
- •Setting up the public and private keys
- •Simple configuration
- •Server-side routing
- •Routing: subnets on both sides
- •Redirecting the default gateway
- •Using an 'ifconfig-pool' block
- •Using the status file
- •Management interface
- •Proxy-arp
- •Introduction
- •Simple configuration—non-bridged
- •Enabling client-to-client traffic
- •Bridging—Linux
- •Bridging—Windows
- •Checking broadcast and non-IP traffic
- •External DHCP server
- •Using the status file
- •Management interface
- •Introduction
- •Certificate generation
- •xCA: a GUI for managing a PKI (Part 1)
- •xCA: a GUI for managing a PKI (Part 2)
- •OpenSSL tricks: x509, pkcs12, verify output
- •Revoking certificates
- •The use of CRLs
- •Checking expired/revoked certificates
- •Intermediary CAs
- •Multiple CAs: stacking, using --capath
- •Introduction
- •Initializing a hardware token
- •Getting a hardware token ID
- •Using a hardware token
- •Selecting a PKCS#11 certificate using the management interface
- •Generating a key on the hardware token
- •Private method for getting a PKCS#11 certificate
- •Pin caching example
- •Introduction
- •Using a client-side up/down script
- •Windows login greeter
- •Using client-connect/client-disconnect scripts
- •Using a 'learn-address' script
- •Using a 'tls-verify' script
- •Using an 'auth-user-pass-verify' script
- •Script order
- •Script security and logging
- •Using the 'down-root' plugin
- •Using the PAM authentication plugin
- •Introduction
- •Cipher mismatches
- •TUN versus TAP mismatches
- •Compression mismatches
- •Key mismatches
- •Troubleshooting MTU and tun-mtu issues
- •Troubleshooting network connectivity
- •How to read the OpenVPN log files
- •Introduction
- •The missing return route
- •Missing return routes when 'iroute' is used
- •Source routing
- •Routing and permissions on Windows
- •Troubleshooting client-to-client traffic routing
- •Understanding the 'MULTI: bad source' warnings
- •Failure when redirecting the default gateway
- •Introduction
- •Optimizing performance using 'ping'
- •OpenSSL cipher speed
- •Compression tests
- •Traffic shaping
- •Tuning UDP-based connections
- •Tuning TCP-based connections
- •Analyzing performance using tcpdump
- •Introduction
- •Linux: using NetworkManager
- •MacOS: using Tunnelblick
- •Windows Vista/7: elevated privileges
- •Windows: using the CryptoAPI store
- •Windows: updating the DNS cache
- •Windows: running OpenVPN as a service
- •Windows: public versus private network adapters
- •Windows: routing methods
- •Introduction
- •Including configuration files in config files
- •Details of ifconfig-pool-persist
- •Connecting using a SOCKS proxy
- •Connecting via an HTTP proxy
- •Connecting via an HTTP proxy with authentication
- •Using dyndns
- •IP-less setups (ifconfig-noexec)
- •Introduction
- •Inline certificates
- •Connection blocks
- •Port sharing with an HTTPS server
- •Routing features: redirect-private, allow-pull-fqdn
- •OCSP support
- •New for 2.2: the 'x509_user_name' parameter
- •Index
11
Advanced
Configuration
In this chapter, we will cover:
Including configuration files in config files
Multiple remotes & remote-random
Details of ifconfig-pool-persist
Connecting using a SOCKS proxy
Connecting via an HTTP proxy
Connecting via an HTTP proxy with authentication
Using dyndns
IP-less setups (ifconfig-noexec)
Introduction
The recipes in this chapter and the next will cover the advanced configuration of OpenVPN. This chapter will focus on some of the less well-known configuration options that OpenVPN offers, whereas the next chapter will deal mostly with configuration options that are specific to OpenVPN 2.1 and higher. The recipes will cover both advanced server configuration, such as the use of a dynamic DNS provider such as dyndns, as well as advanced client configuration, such as using a proxy server to connect to an OpenVPN server.
Advanced Configuration
Including configuration files in config files
One of the lesser-known possibilities when using configuration files is the ability to include other configuration files. This can be especially handy when setting up a complex OpenVPN server, where multiple OpenVPN instances are offered simultaneously. The common configuration directives can be stored in a single file, whereas the connection-specific parts can be stored in a file for each instance. In this recipe, we will set up two OpenVPN instances, one using UDP and the other using TCP as the transport protocol.
Note that this option does not allow for the sharing of VPN IP address ranges between instances.
Getting ready
Set up the client and server certificates using the first recipe from Chapter 2, Client-server IP-only Networks. For this recipe, the server computer was running CentOS 5 Linux and OpenVPN 2.1.3.
How to do it...
1.First, create the common configuration file: dev tun
ca |
/etc/openvpn/cookbook/ca.crt |
cert |
/etc/openvpn/cookbook/server.crt |
key |
/etc/openvpn/cookbook/server.key |
dh |
/etc/openvpn/cookbook/dh1024.pem |
tls-auth /etc/openvpn/cookbook/ta.key 0
persist-key persist-tun keepalive 10 60
push "route 10.198.0.0 255.255.0.0" topology subnet
user nobody group nobody
daemon
Save it as example11-1-common.conf. Note that this configuration file does not include a protocol specification or server line. Also, note that we will be using the same server certificate for both OpenVPN instances.
286
Chapter 11
2.Next, create two server configuration files, one for UDP-based connections: config example11-1-common.conf
proto udp port 1194
server 192.168.100.0 255.255.255.0
log-append /var/log/openvpn-udp.log
Save it as example11-1-server1.conf.
3.And one for TCP-based connections: config example11-1-common.conf
proto tcp port 443
server 192.168.200.0 255.255.255.0
log-append /var/log/openvpn-tcp.log
Save it as example11-1-server2.conf. The second instance is listening on the
HTTPS port 443, which is an often-used trick to circumvent very strict firewalls, or to work around a badly configured firewall.
4.Start both servers:
[root@server]# openvpn --config example11-1-server1.conf [root@server]# openvpn --config example11-1-server2.conf
Check the log files to see if both the servers have successfully started.
How it works...
OpenVPN configuration files are treated very similarly to command-line options. As the
--config command-line option is used almost always, it is also possible to use it inside a configuration file again. This allows for a split in the configuration options, where
directives that are common to all OpenVPN instances can be stored in a single file for easy maintenance. The instance-specific directives (such as the server directive) can then be stored in much smaller configuration files, which are also less likely to change over time.
This again eases maintenance of a large-scale OpenVPN server setup.
OpenVPN has a built-in protection mechanism to avoid including the same configuration file recursively.
287
Advanced Configuration
Multiple remotes and remote-random
OpenVPN has built-in support for automatic failover and load-balancing: if the connection to one OpenVPN server cannot be established, then the next configured server is chosen.
The remote-random directive can be used to load-balance many OpenVPN clients across multiple OpenVPN servers. In this recipe, we will set up two OpenVPN servers and then use the remote-random directive to have a client choose either one of the two servers.
Note that OpenVPN does not offer transparent failover, in which case the existing connections are transparently migrated to another server. Transparent failover is much harder to achieve with a VPN setup (not just OpenVPN), as the secure session keys need to be migrated from one server to the other as well. This is currently not possible with OpenVPN.
Getting ready
We use the following network layout:
Set up the client and server certificates using the first recipe from Chapter 2, Client-server IP-only Networks. For this recipe, the server computers were running CentOS 5 Linux and OpenVPN 2.1.3. The client was running Fedora 13 Linux and OpenVPN 2.1.1. Keep the configuration file basic-udp-server.conf from the Chapter 2 recipe Server-side routing at hand.
How to do it...
1.Start both servers:
[root@server1]# openvpn --config basic-udp-server.conf
[root@server2]# openvpn --config basic-udp-server.conf
Check the log files to see that both the servers have successfully started.
288
Chapter 11
Note that we can use the exact same configuration file on both servers. By using masquerading, the VPN clients will appear to come from either server1
or server2.
2.Set up masquerading on both servers:
[root@server1]# iptables -t nat -I POSTROUTING -o eth0 \ -j MASQUERADE
[root@server2]# iptables -t nat -I POSTROUTING -o eth0 \ -j MASQUERADE
3.Create the client configuration file:
client proto udp
remote openvpnserver1.example.com 1194 remote openvpnserver2.example.com 1194 remote-random
dev tun nobind
ca |
/etc/openvpn/cookbook/ca.crt |
cert |
/etc/openvpn/cookbook/client1.crt |
key |
/etc/openvpn/cookbook/client1.key |
tls-auth /etc/openvpn/cookbook/ta.key 1
ns-cert-type server
Save it as example11-2-client.conf.
4.Start the client:
[root@client]# openvpn --config example11-2-client.conf
The OpenVPN client will randomly choose which server to connect to.
After the connection has been established, stop the first OpenVPN process on the server that the client connected to:
[root@server1]# killall openvpn
And wait for the client to reconnect. After the default timeout period, the client will reconnect to an alternate server.
289
Advanced Configuration
How it works...
When the OpenVPN client starts up and remote-random is specified, it randomly picks a server from the list of available remote servers. If the VPN connection to this server cannot be established, it will pick the next server from the list, and so on. When the VPN connection is dropped, for example, due to a failing server, the OpenVPN client will try to reconnect after a default timeout period. In the server configuration file used in the Chapter 2 recipe Server-side routing, the timeout period is configured using the keepalive option.
There's more...
When setting up a failover OpenVPN solution there are many things to consider, some of which are outlined here.
Mixing TCP and UDP-based setups
It is also possible to mix TCP and UDP-based setups by specifying the protocol type with the remote directive:
remote openvpnserver1.example.com 1194 udp remote openvpnserver2.example.com 1194 tcp
An OpenVPN 2.1-specific feature known as connection blocks is much handier to use in this case. The use of connection blocks is explained in the next chapter.
Advantage of using TCP-based connections
There is one major advantage when using a TCP-based setup in combination with a failover solution. If the OpenVPN server to which a client is connected is unavailable, the TCP connection will fail almost immediately. This leads to a very short timeout period after which the OpenVPN client will try to reconnect. With a UDP-based setup, the client cannot so easily detect whether the server is unavailable and must first wait for the keepalive timeout to pass.
Automatically reverting to the first OpenVPN server
A question that is asked from time to time is whether it is possible to configure OpenVPN to also support automatic revert: a second OpenVPN instance is set up to provide a failover solution. When the main OpenVPN server is unavailable, the backup instance takes over. However, when the main OpenVPN server comes back online, the clients are not automatically reconnected to the main server. For this, a client reset (or server reset of the second OpenVPN instance) is required. It is possible to achieve this using scripting but it depends largely on what type of connectivity is considered acceptable: it takes some time for an OpenVPN client to detect when the remote server is not responding and to reconnect. The VPN connectivity will be intermittent in such a setup. Especially when the network connection to the main OpenVPN server is not stable, this can lead to very low availability.
290