- •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 1
Here is the set of configuration options:
user nobody group nobody persist-tun persist-key keepalive 10 60 ping-timer-rem
They are used to make the connection more robust and secure, as follows:
The OpenVPN process runs as user nobody, group nobody, after the initial connection is established. Even if somebody is able to take control of the OpenVPN process itself he would still only be user nobody and not root. Note that on some Linux distributions the group nogroup is used instead.
The persist-tun and persist-key options are used to ensure that the connection comes back up automatically if the underlying network is disrupted. These options are necessary when using user nobody and group nobody
(or group nogroup).
The keepalive and ping-timer-rem options cause OpenVPN to send a periodic 'ping' message over the tunnel to ensure that both ends of the tunnel remain up and running.
There's more...
This point-to-point setup can also be used to evade restrictive firewalls. The data stream between the two endpoints is not recognizable and very hard to decipher. When OpenVPN is run in client/server (see Chapter 2, Multi-client TUN-style Networks), the traffic is recognizable as OpenVPN traffic due to the initial TLS handshake.
See also
Chapter 8, Troubleshooting OpenVPN: Routing Issues, in which the most common routing issues are explained.
3-way routing
For a small number (less than four) of fixed endpoints, a point-to-point setup is very flexible. In this recipe, we set up three OpenVPN tunnels between three sites, including routing between the endpoints. By setting up three tunnels, we create a redundant routing so that all sites are connected even if one of the tunnels is disrupted.
25
Point-to-Point Networks
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. In this recipe, the tunnel endpoints were running CentOS 5 Linux or Fedora
13 Linux and OpenVPN 2.1.1. Make sure that the routing (IP forwarding) is configured on all the OpenVPN endpoints.
How to do it...
1. We generate three static keys:
[root@siteA]# openvpn –-genkey –-secret AtoB.key [root@siteA]# openvpn –-genkey –-secret AtoC.key [root@siteA]# openvpn –-genkey –-secret BtoC.key
Transfer these keys to all endpoints over a secure channel (for example, using scp).
2.Create the server (listener) configuration file named example1-8-serverBtoA. conf:
dev tun proto udp port 1194
secret AtoB.key 0
ifconfig 10.200.0.1 10.200.0.2
26
Chapter 1
route 192.168.4.0 255.255.255.0 vpn_gateway 5 route 192.168.6.0 255.255.255.0 vpn_gateway 10 route-delay
keepalive 10 60 verb 3
Next, create example1-8-serverCtoA.conf: dev tun
proto udp port 1195
secret AtoC.key 0
ifconfig 10.200.0.5 10.200.0.6
route 192.168.4.0 255.255.255.0 vpn_gateway 5 route 192.168.5.0 255.255.255.0 vpn_gateway 10 route-delay
keepalive 10 60 verb 3
and example1-8-serverBtoC.conf: dev tun
proto udp port 1196
secret BtoC.key 0
ifconfig 10.200.0.9 10.200.0.10
route 192.168.4.0 255.255.255.0 vpn_gateway 10 route 192.168.6.0 255.255.255.0 vpn_gateway 5 route-delay
keepalive 10 60 verb 3
Now, create the client (connector) configuration files example1-8- clientAtoB.conf:
dev tun proto udp remote siteB port 1194
secret AtoB.key 1
ifconfig 10.200.0.2 10.200.0.1
27
Point-to-Point Networks
route 192.168.5.0 255.255.255.0 vpn_gateway 5 route 192.168.6.0 255.255.255.0 vpn_gateway 10 route-delay
keepalive 10 60 verb 3
Also, create example1-8-clientAtoC.conf file: dev tun
proto udp remote siteC port 1195
secret AtoC.key 1
ifconfig 10.200.0.6 10.200.0.5
route 192.168.5.0 255.255.255.0 vpn_gateway 10 route 192.168.6.0 255.255.255.0 vpn_gateway 5 route-delay
verb 3
and finally the example1-8-clientCtoB.conf: dev tun
proto udp remote siteB port 1196
secret BtoC.key 1
ifconfig 10.200.0.10 10.200.0.9
route 192.168.4.0 255.255.255.0 vpn_gateway 10 route 192.168.5.0 255.255.255.0 vpn_gateway 5 route-delay
keepalive 10 60 verb 3
First, we start all the listener tunnels:
[root@siteB]# openvpn --config example1-8-serverBtoA.conf [root@siteB]# openvpn --config example1-8-serverBtoC.conf [root@siteC]# openvpn --config example1-8-serverCtoA.conf
28
Chapter 1
These are followed by the connector tunnels:
[root@siteA]# openvpn --config example1-8-clientAtoB.conf [root@siteA]# openvpn --config example1-8-clientAtoC.conf [root@siteC]# openvpn --config example1-8-clientCtoB.conf
And with that, our three-way site-to-site network is established.
How it works...
It can clearly be seen that the number of configuration files gets out of hand too quickly. In principle, two tunnels would have been sufficient to connect three remote sites, but then there would have been no redundancy.
With the third tunnel and with the configuration options:
route 192.168.5.0 255.255.255.0 vpn_gateway 5 route 192.168.6.0 255.255.255.0 vpn_gateway 10 route-delay
keepalive 10 60
There are always 2 routes to each remote network.
For example, site A has two routes to site B (LAN 192.168.5.0/24), as seen from the following routing table:
[siteA]$ ip route show […]
192.168.5.0/24 via 10.200.0.1 dev tun0 metric 5 192.168.5.0/24 via 10.200.0.5 dev tun1 metric 10 […]
Aroute:
Via the "direct" tunnel to site B; this route has the lowest metric
Via an indirect tunnel: first to site C and then onward to site B; this route has a higher metric and is not chosen until the first route is down
This setup has the advantage that if one tunnel fails, then after 60 seconds, the connection and its corresponding routes are dropped and are restarted. The backup route to the other network then automatically takes over and all three sites can reach each other again.
When the "direct" tunnel is restored the direct routes are also restored and the network traffic will automatically choose the best path to the remote site.
29
Point-to-Point Networks
There's more...
Scalability
In this recipe, we connect three remote sites. This results in six different configuration files that provide the limitations of the point-to-point setup. In general, to connect N possible sites with full redundancy, you will have N * ( N – 1 ) configuration files. This is manageable for up to four sites, but after that, a server/multiple-client setup as described in the next chapters is much easier.
Routing protocols
To increase the availability of the networks, it is better to run a Routing Protocol such as RIPv2 or OSPF. Using a routing protocol, the failing routes are discovered much faster, resulting in less network downtime.
See also
Chapter 8, Troubleshooting OpenVPN: Routing Issues, in which the most common routing issues are explained.
30