- •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 2
Client-to-client access
With this setup, the VPN clients can connect to each other even though we did not make use of the following directive in the server-side configuration:
client-to-client
This is possible due to the route and push route statements in the server configuration file. The advantage of not using client-to-client is that it is still possible to filter out unwanted traffic using iptables or another firewalling solution.
If there is no need for the administrative clients to connect to the regular VPN clients (or vice versa), then the netmask can be adjusted to:
route 192.168.200.0 255.255.255.0
push "route 192.168.200.0 255.255.255.0"
Now, the networks are completely separated.
Using the TCP protocol
In this example, we chose the UDP protocol. The client configuration file in this recipe can easily be converted to use TCP protocol by changing the line:
proto udp
Change it to the following:
proto tcp
Save this file for future use as basic-tcp-client.ovpn.
Using the status file
OpenVPN offers several options to monitor the clients connected to a server. The most commonly used method is using a status file. This recipe will show how to use and read the OpenVPN's status file.
59
Client-server IP-only Networks
Getting ready
We use the following network layout:
This recipe uses the PKI files created in the first recipe of this chapter. In this recipe, the server computer was running CentOS 5 Linux and OpenVPN 2.1.1. The first client was running
Fedora 12 Linux and OpenVPN 2.1.1. The second client was running Windows XP SP3 and
OpenVPN 2.1.1. For the Linux server, keep the server configuration file basic-udp-server. conf from the recipe Server-side routing at hand. For the Linux client, keep the client configuration file basic-udp-client.conf from the same recipe at hand. For the Windows client, keep the corresponding client configuration file basic-udp-client.ovpn from the previous recipe at hand.
How to do it...
1.Create the server configuration file by adding a line to the basic-udp-server. conf file:
status /var/log/openvpn.status
Save it as example2-8-server.conf. 2. Start the server:
[root@server]# openvpn --config example2-8-server.conf
3. First, start the Linux client:
[root@client1]# openvpn --config basic-udp-client.conf
60
Chapter 2
4.After the VPN is established, list the contents of the openvpn.status file:
[root@server]# cat /var/log/openvpn.status
5.Transfer the ca.crt, client2.crt, client2.key files and the tls-auth secret key file, ta.key, to the Windows machine using a secure channel, such as winscp or the PuTTY's pscp command-line tool.
6.Start the Windows client on the command-line:
[WinClient2]C:> cd \program files\openvpn\config [WinClient2]C:> ..\bin\openvpn --config basic-udp-client.ovpn
Remember that this client's private key file is protected using a password or passphrase.
7.List the contents of the status file again on the server:
[root@server]# cat /var/log/openvpn.status
61
Client-server IP-only Networks
How it works...
Each time a client connects to the OpenVPN server, the status file is updated with the connection information. The OpenVPN CLIENT LIST and ROUTING TABLE are the most interesting tables, as they show:
Which clients are connected
From which IP address the clients are connecting
The number of bytes each client has received and transferred
The time at which the client connected
In addition, the routing table also shows which networks are routed to each client.
Note that the second client is connected to the server using the same Real Address as the first client. This is caused by the fact that the Windows XP client was running as a virtual machine on the Linux client. It also shows that OpenVPN can handle NAT'ted clients
quite easily.
There's more...
Status parameters
The status directive takes two parameters:
The filename of the status file.
Optionally, the refresh frequency for updating the status file. The default value of 60 seconds should suffice for most situations.
Disconnecting clients
Note that when a client disconnects the status file, it is not updated immediately. OpenVPN first tries to reconnect to the client based on the keepalive parameters in the server configuration file. The server configuration file in this recipe uses:
keepalive 10 60
This tells the server that it will ping the client every 10 seconds. If it does not get response after 60 seconds * 2, the connection is restarted. The OpenVPN server will double the value of the second argument. The server will also tell the client to ping every 10 seconds and to restart the connection after 60 seconds if it does not get any response.
62