- •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
12
New Features of OpenVPN 2.1 and 2.2
In this chapter, we will cover:
Inline certificates
Connection blocks
Port sharing with an HTTPS server
Routing features: redirect-private, allow-pull-fqdn
Handing out public IPs
OCSP support
New for 2.2: the x509_user_name parameter
Introduction
In this chapter, we will focus on some of the new features found in OpenVPN 2.1 and the upcoming 2.2 release. Many recipes from the previous chapters already made use of
OpenVPN 2.1-specific features (such as topology subnet), but a few other features introduced in OpenVPN 2.1 are less well known. The recipes in this chapter will cover some of these, such as the use of inline certificates, connection blocks, and port-sharing.
The upcoming 2.2 release of OpenVPN is mainly a bug-fix release, though a few new directives were introduced. In the last recipe of this chapter, we will focus on one of them.
New Features of OpenVPN 2.1 and 2.2
Inline certificates
To ease the deployment of OpenVPN configuration, public and private key files, a new feature is available to include all of them in a single file. This is done by integrating the contents of the ca, cert, key, and optionally the tls-auth file into the client configuration file itself. So, in this recipe, we will set up such a configuration file and use it to connect to our standard
OpenVPN server.
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.First, start the server:
[root@server]# openvpn --config basic-udp-server.conf
2.Create the client configuration file:
client proto udp
remote openvpnserver.example.com port 1194
dev tun nobind
ca [inline] cert [inline]
312
Chapter 12
key [inline] tls-auth [inline] 1
<ca>
-----BEGIN CERTIFICATE-----
# insert base64 blob from ca.crt
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
# insert base64 blob from client1.crt
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
# insert base64 blob from client1.key
-----END PRIVATE KEY-----
</key>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
# insert ta.key
-----END OpenVPN Static key V1-----
</tls-auth>
Insert the contents of the ca.crt, client1.crt, client1.key and ta.key files in the configuration. Save it as example12-1-client.conf.
3.Then, connect the client:
[root@client]# openvpn --config example12-1-client.conf
How it works...
When OpenVPN parses the configuration directives, ca, cert, key, and tls-auth (and dh for server configuration files), and it finds the value [inline], then an XML-like block must be present later in the configuration file. The contents of this XML-like block are then read and treated in the same manner as when a file is specified. When all the required configuration files or blocks are present, the connection is established.
Note that it is not required to treat all of the above configuration directives in the same manner. It is also possible to only specify an [inline] block for the CA certificate file, as this file tends to be static for all the clients.
313
New Features of OpenVPN 2.1 and 2.2
Connection blocks
Similar to the inline certificates used in the previous recipe, it is also possible to specify connection blocks. These connection blocks are treated as multiple definitions for remote servers and they are tried in order until a VPN connection is established. The advantage of using a connection block is that for each remote server, server-specific parameters can be specified, such as the protocol (UDP or TCP), the remote port, whether a proxy server should be used , and so on.
In this recipe, we will set up two servers, one listening on a UDP port and the other on a TCP port. We will then configure the OpenVPN client to try the first server using a UDP connection.
If the connection cannot be established, the client will attempt to connect to the second server using a TCP connection.
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 server configuration file basic-udp-server.conf from the Chapter 2 recipe Server-side routing at hand, as well as the server configuration file, example9-7-server.conf, from the
Chapter 9 recipe Tuning TCP-based connections.
How to do it...
1.Start both the servers:
[root@server1]# openvpn --config basic-udp-server.conf
[root@server2]# openvpn --config example9-7-server.conf
314
Chapter 12
2.Check the log files to check that both the servers have successfully started.
3.Create the client configuration file:
client dev tun
<connection>
remote openvpnserver1.example.com proto udp
port 1194 </connection>
<connection>
remote openvpnserver2.example.com proto tcp
port 1194 </connection>
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 example12-2-client.conf.
4.Start the client:
[root@client]# openvpn --config example12-2-client.conf
5.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 the alternate server using the TCP protocol.
How it works...
When the OpenVPN client starts up, it attempts to connect to the server specified in the first
<connection> block. If that connection fails, it will try the next <connection> block entry and so forth. When an OpenVPN server becomes unavailable or is stopped, the client will automatically restart and try to connect to the first available OpenVPN server again.
315
New Features of OpenVPN 2.1 and 2.2
The OpenVPN client first parses the global directives, which are specified outside the
<connection> blocks. For each block, the global directives are then overruled using block-specific directives. This makes it easier to specify in the <connection> blocks only those parameters that are different for each connection.
There's more...
Connection blocks, as well as inline certificates, are very handy new features introduced in OpenVPN 2.1. A consequence of these features is that the use of the command line to overrule the directives specified in the configuration file becomes harder, if not impossible. There are a few other things to keep in mind when using connection blocks.
Allowed directives inside connection blocks
There are only a few directives allowed inside a connection block:
bind
connect-retry, connect-retry-max, connect-timeout
float
http-proxy, http-proxy-option, http-proxy-retry, http-proxy- timeout
local lport
nobind
port
proto
remote, rport
socks-proxy, socks-proxy-retry
All other directives are considered global and can only be specified once.
Pitfalls when mixing TCP and UDP-based setups
Connection blocks make it very easy to mix TCP and UDP-based setups. The downside is that the global parameters specified in the configuration file must be valid for both the TCP and
UDP-based setups. This rules out the use of the commonly-used fragment directive, as well as a few other tuning parameters. It is expected that this shortcoming of <connection> blocks will be addressed in a future version of OpenVPN.
See also
Chapter 11's recipe, Multiple remotes & remote-random, which explains how to achieve the same setup without using connection blocks.
316