- •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 8
Without this, the OpenVPN server does not "know" which VPN client the remote network is connected to. If a packet comes in from a client that the OpenVPN server does not know about, then the packet is dropped and, with 'verb 5' or higher, the warning MULTI: bad source is printed.
There's more...
Apart from the warnings explained above, there is one other major reason for the MULTI: bad source messages to occur.
Other occurrences of the 'MULTI: bad source' message
Sometimes the MULTI: bad source message is printed in the OpenVPN server log file even when no client-side LAN is connected to the VPN client . This happens most often with VPN clients running Windows. When a file share is accessed over the VPN connection, Windows sometimes sends packets with a different source IP address than that of the VPN interface. These packets are not recognized by the OpenVPN server and the warning is printed. The solution to this issue is not known.
See also
Chapter 2's recipe, Routing: subnets on both sides, which explains the basics of setting up a client-config-dir setup.
Chapter 7's recipe, Troubleshooting 'client-config-dir' issues, which goes deeper into some of the frequently made mistakes when using the client-config-dir directive.
Failure when redirecting the default gateway
In this recipe, we will troubleshoot an infrequent yet very persistent issue that can occur when setting up a VPN connection. When the redirect-gateway directive is used to redirect the default gateway on an OpenVPN client, it sometimes causes the client to lose all the Internet connections. This particularly occurs when the client machine on which OpenVPN is running is connected to the rest of the network or with the Internet using a PPP-based connection, such as PPPoE or PPPoA, especially, when using a GPRS/UMTS connections via a mobile phone.
When this occurs, OpenVPN sometimes is not capable of determining the default gateway before it is redirected. After the default gateway is redirected to the OpenVPN tunnel, the whole tunnel collapses on itself, as all the traffic, including the encrypted tunnel traffic itself, is redirected into the tunnel, causing the VPN to lock up.
227
Troubleshooting OpenVPN: Routing
This recipe will show how to detect this situation and what can be done about it. In this recipe, we will not use a GPRS/UMTS connection but we will use a PPP-over-SSH connection, which behaves in a similar fashion and is more readily available.
Getting ready
We use the following network layout:
Install OpenVPN 2.0 or higher on two computers. Make sure the computers are connected over a network. Make sure the client is connected to the network using a PPP connection, as otherwise, the issue described in the title of this recipe will not occur. For this recipe, a PPP-over-SSH connection and the default route was altered to point to the ppp0 device.
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 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 the server and add an extra parameter to direct the default gateway:
[root@server]# openvpn --config basic-udp-server.conf \ -–push "redirect-gateway"
2.Create the client configuration file:
client proto udp
#next is the IP address of the VPN server via the
#PPP-over-SSH link
remote 192.168.222.1 port 1194
dev tun nobind
228
Chapter 8
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
user nobody verb 5
Save it as example8-8-client.conf.
3.Check the system routes before starting the client:
[root@client]# netstat -rn
172.30.0.10172.30.0.1 255.255.255.255 UGH 0 0 0 eth0
192.168.222.1 |
0.0.0.0 |
255.255.255.255 UH |
0 0 0 |
ppp0 |
|
0.0.0.0 |
192.168.222.1 |
0.0.0.0 |
UG |
0 0 0 |
ppp0 |
4.Now, start the client:
[root@client]# openvpn --config example8-8-client.conf
The connection will start but after a few seconds will stop and the log file will contain a warning message:
… OpenVPN ROUTE: omitted no-op route: 192.168.222.1/255.255.255.25 5 -> 192.168.222.1
5.Check the system routes again:
[client]$ netstat –rn
172.30.0.19172.30.0.1 255.255.255.255 UGH 0 0 0 eth0
192.168.222.1 |
0.0.0.0 |
255.255.255.255 |
UH |
0 0 0 |
ppp0 |
192.16.186.192 |
0.0.0.0 |
255.255.255.192 |
U |
0 0 0 |
eth0 |
192.168.200.0 |
0.0.0.0 |
255.255.248.0 |
U |
0 0 0 |
tun0 |
10.198.0.0 |
192.168.200.1 |
255.255.0.0 |
UG |
0 0 0 |
tun0 |
0.0.0.0 |
192.168.200.1 |
0.0.0.0 |
UG |
0 0 0 |
tun0 |
The default gateway is now the VPN tunnel but the original route to the gateway is now gone.
All the connections on the client have stopped. What's worse, when the OpenVPN client is aborted (by pressing Ctrl-C in the terminal window) the default route is not restored, as the OpenVPN process does not have the proper rights to do so:
TCP/UDP: Closing socket /sbin/ip route del 10.198.0.0/16
RTNETLINK answers: Operation not permitted
ERROR: Linux route delete command failed: external program exited with error status: 2
/sbin/ip route del 192.168.222.1/32
229
Troubleshooting OpenVPN: Routing
RTNETLINK answers: |
Operation not permitted |
ERROR: Linux route |
delete command failed: external program exited with |
error status: 2 |
|
/sbin/ip route del |
0.0.0.0/0 |
RTNETLINK answers: |
Operation not permitted |
ERROR: Linux route |
delete command failed: external program exited with |
error status: 2 |
|
/sbin/ip route add |
0.0.0.0/0 via 192.168.222.1 |
RTNETLINK answers: |
Operation not permitted |
ERROR: Linux route |
add command failed: external program exited with |
error status: 2 |
|
Closing TUN/TAP interface
The result is that the default gateway on the client machine is gone. The only solution is to reload the network adapter so that all the system defaults are restored.
The solution to the above problem is to use the following as is done in the Chapter 2 recipe
Redirecting the default gateway:
push "redirect-gateway def1"
How it works...
When the OpenVPN client initializes, it always tries to create a direct route to the OpenVPN server via the existing system gateway. Under certain circumstances this fails, mostly due to an odd network configuration. It is seen most often when the default gateway is a dial-up or
PPPoE connection, which is used in certain ADSL/VDSL setups and especially when using GPRS/UMTS connections.
When the OpenVPN client is instructed to redirect all the traffic over the VPN tunnel, it normally sends the encrypted VPN traffic itself over a direct link to the OpenVPN server. You can think of the encrypted VPN traffic as "outside" of the tunnel. However, when this direct route is missing, then this "outside" traffic is also sent into the tunnel, creating a tunneling loop from which the VPN can never recover.
In the example used in this recipe, the situation is made worse by using the client configuration directive:
user nobody
This tells the OpenVPN process to drop all the privileges after starting. When the client is aborted because the tunnel is not functioning properly, the client is not capable of restoring the original gateway and the system is left in a non-functioning state:
[client]$ netstat –rn |
|
|
|
|
194.171.96.27 |
192.16.186.254 255.255.255.255 UGH 0 0 0 |
eth0 |
||
192.168.222.1 |
0.0.0.0 |
255.255.255.255 UH |
0 0 0 |
ppp0 |
192.16.186.192 |
0.0.0.0 |
255.255.255.192 U |
0 0 0 |
eth0 |
230
Chapter 8
Only by adding a new default gateway can the network be restored.
The proper fix is to use:
push "redirect-gateway def1"
This will not overwrite the existing default gateway but which will add two extra routes:
0.0.0.0 192.168.200.1 128.0.0.0 UGH 0 0 0 tun0 128.0.0.0 192.168.200.1 128.0.0.0 UGH 0 0 0 tun0
both of which cover half the available network space. These two routes effectively replace the existing default route whilst not overwriting it.
There's more...
This "biting your own tail" problem was much more common when OpenVPN 2.0 was used. In OpenVPN 2.1 and higher, the detection of the default gateway was much improved and this problem now rarely occurs anymore. This is another good reason to upgrade all the clients (and preferably the server as well, of course) to OpenVPN 2.1 or higher.
See also
Chapter 2's recipe, Redirecting the default gateway, which explains how to properly redirect all traffic via the VPN tunnel.
231