- •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
Chapter 9
See also
The next recipe in this chapter, which explains how to tune TCP-based connections in a very similar manner.
Tuning TCP-based connections
In this recipe, we focus on some of the basic techniques for optimizing TCP-based VPN tunnels. In a TCP-based VPN setup, the connection between the VPN endpoints is a regular TCP connection. This has advantages and drawbacks. The main advantage is that it is often easier to set up a TCP connection than a UDP connection, mostly due to firewall restrictions. The main drawback of tunneling TCP traffic over a TCP-based tunnel is that there is chance of severe performance penalties, especially, when the network connection is poor. This performance penalty is caused by the tcp-over-tcp syndrome. The TCP protocol guarantees the ordered delivery of packets, thus if a packet is dropped along the way, the packet will be resent. Once the new packet is received, the packet order is restored. Until that time, all
packets after the lost packet are on hold. The problem with tunnelling TCP traffic over a TCP connection is that both layers want to guarantee ordered packet delivery. This can lead to a large amount of retransmits and hence to a large performance penalty.
When tuned correctly, however, an OpenVPN tunnel over a TCP connection can achieve the same performance as an OpenVPN tunnel over a UDP connection. In this recipe, we will show some techniques for tuning such a TCP-based OpenVPN connection.
Getting ready
We use the following network layout:
249
Performance Tuning
Install OpenVPN 2.0 or higher on two computers. Make sure the computers are connected over a network. 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.1. The client was running Windows XP SP3 and OpenVPN 2.1.1.
How to do it...
1.Create the server configuration file:
proto tcp port 1194 dev tun
server 192.168.200.0 255.255.255.0
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
topology subnet
user nobody group nobody
daemon
log-append /var/log/openvpn.log
tcp-nodelay
Save it as example9-7-server.conf.
2.Start the server:
[root@server]# openvpn --config example9-7-server.conf
3.Next , create the client configuration file:
client proto tcp
remote openvpnserver.example.com port 1194
250
Chapter 9
dev tun nobind
ca |
"c:/program files/openvpn/config/ca.crt" |
cert |
"c:/program files/openvpn/config/client2.crt" |
key |
"c:/program files/openvpn/config/client2.key" |
tls-auth "c:/program files/openvpn/config/ta.key" 1
ns-cert-type server
Save it as example9-7.ovpn. 4. Start the client:
5.Next, start iperf on the server:
[server]$ iperf –s
6.Then, measure the performance of the tunnel:
[client]$ iperf –c 192.168.200.1
On this particular network, the following settings were tested:
Protocol |
Result |
UDP |
40 Mbits/se |
TCP |
32 Mbits/sec |
TCP with tcp-nodelay |
38 Mbits/sec |
As can be seen, the performance of running OpenVPN over TCP is almost identical to the performance of OpenVPN over UDP, when the --tcp-nodelay directive is used.
251
Performance Tuning
How it works...
When OpenVPN uses TCP as its underlying protocol, all packets are transferred over a regular TCP connection. By default, TCP connections make use of the Nagle algorithm, where smaller packets are held back and collected before they are sent. For an OpenVPN tunnel, this has an adverse effect on performance in most cases, hence it makes sense to disable the Nagle algorithm. By adding the --tcp-nodelay directive, we disable the Nagle algorithm and we see an immediate increase in performance.
There's more...
The two important parameters that can be tweaked for TCP-based connections are:
The --tcp-nodelay directive
The MTU size of the TUN/TAP-Win32 adapter via either the --tun-mtu or
--link-mtu directives
On Linux, the MTU size of the TUN (or TAP) adapter can be adjusted on-the-fly, but on Windows XP, this is not the case. OpenVPN must be configured to match the MTU size as specified on the server. Before the new MTU size is used, however, a registry change must be made and Windows must be rebooted for the new MTU size to take effect. This makes it much harder
to find the right MTU size for Window clients.
Starting with Windows Vista, it is now also possible to change the MTU setting on-the-fly, using the netsh command:
First, find the right sub-interface number:
[winclient]C:> netsh interface ipv4 show subinterfaces
Next, in order to change the MTU size of a sub-interface, use:
[winclient]C:> netsh interface ipv4 set subinterface "1" mtu=1400
Note that these commands must be run with elevated privileges.
If the MTU setting of the Windows TAP-Win32 adapter is larger than the MTU size configured by OpenVPN, the following message can appear in the OpenVPN 2.1 log file:
… read from TUN/TAP [State=AT?c Err=[c:\src\21\tap-win32\tapdrvr. c/2447] #O=4 Tx=[29510,0] Rx=[15309,0] IrpQ=[0,1,16] PktQ=[0,22,64] InjQ=[0,1,16]]: More data is available. (code=234)
For this particular network, all changes made to the MTU size (with the appropriate Windows reboot) did not have a positive effect on performance.
252