Chapter 11
A quick and dirty method to have all clients revert back to the first server is to use the management interface on the second server and disconnect all clients.
See also
Chapter 2's recipe, Server-side routing, which explains the basic setup of OpenVPN.
Chapter 12's recipe, Using connection blocks, which shows an alternate and more flexible method for supporting multiple servers in a single client configuration file.
Details of ifconfig-pool-persist
One of the options available in OpenVPN that can lead to a lot of confusion is ifconfig- pool-persist. This directive tells the OpenVPN server to maintain a persistent list of IP addresses handed out to different clients. When a client reconnects at a later time, the previously-used address is reused. This is only one of three methods for assigning static addresses to an OpenVPN client. The other two methods are:
Using an ifconfig-push statement in a client-connect script
Using an ifconfig-push statement in a client-configuration file
both of which take precedence over the entries found in the ifconfig-pool-persist file. Experience has shown that it is often a good idea to temporarily disable this option when an OpenVPN setup is not working properly.
In this recipe, we will demonstrate how to use the ifconfig-pool-persist and what the pitfalls are.
Getting ready
We use the following network layout:
291
Advanced Configuration
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.3. The first 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, as well as the client configuration file, basic-udp-client.conf, from the same recipe. The second client was running Windows XP SP3 and OpenVPN 2.1.3. For this client, keep the client configuration file, basic-udp-client.ovpn, from the Chapter 2 recipe
Using an ifconfig-pool block at hand.
How to do it...
1.Create the server configuration file by adding the following line to the basic-udp-server.conf file:
ifconfig-pool-persist /etc/openvpn/cookbook/ipp.txt
Save it as example11-3-server.conf file.
2.Start the server:
[root@server]# openvpn --config example11-3-server.conf
An empty file /etc/openvpn/cookbok/ipp.txt will be created as the server starts up.
3.Connect the first client:
[root@client]# openvpn --config basic-udp-client.conf
Normally, this client will be assigned 192.168.200.2, which is the first available IP address in the server IP range.
4.Stop both the client and the server. List the contents of the ipp.txt file:
[root@server]# cat /etc/openvpn/cookbook/ipp.txt openvpnclient1,192.168.200.2
5.Start the server again. Now, connect the second client, which has a different certificate:
292
Chapter 11
This client will now be assigned the address 192.168.200.3. Without the ifconfig-pool-persist option, it would have been assigned the first available address, which is 192.168.200.2.
How it works...
When the OpenVPN server starts, it reads the ipp.txt file, if it exists, and it tries to re-assign the IP addresses to the client certificates found in the file. Whenever an OpenVPN client
with one of the existing client certificates connects, it is assigned the address found in the ipp.txt file, unless the server VPN IP address space is too small for the number of already-connected clients. In that case, the client receives the first available address from the server VPN IP address space.
The first client that connected received the first available address, 192.168.200.2, from the VPN IP server address range. When the OpenVPN server shuts down, this information is recorded in the ipp.txt file. The second time the OpenVPN server started, this information was reloaded and the address 192.168.200.2 was held in reserve for the client with client certificate openvpnclient1. When the second client connected with client certificate openvpnclient2, it received the next available address in the server VPN IP address range, which is 192.168.200.3. When the server shuts down again, this information is also recorded in the ipp.txt file. This means that from now on, the first client will always receive the .2 address and the second client the .3 address. However, it is not a guarantee that the listed IP addresses will be assigned to a particular client certificate. The exception occurs when many VPN clients connect to the server. If the VPN IP address range is exhausted and the first client is not connected at that time, its address is recycled for other VPN clients. If the
client with the client certificate openvpnclient1 then tries to connect to the server, it will be assigned the first available address. For a guaranteed assignment, a client-config-dir file should be used.
There's more...
When using the ifconfig-pool-persist directive, there are a few pitfalls to watch out for:
Specifying the update interval
Because we did not explicitly specify an update interval, the ipp.txt file is updated every 600 seconds (10 minutes). This can also be seen by looking at the ipp.txt file right after a new client connects: the newly-found client certificate and VPN IP are not listed in the ipp.txt file until the first update interval passes or when the OpenVPN server process shuts down.
It is also possible to specify an update interval of 0 seconds, which means that the ipp.txt file is never updated. This causes the OpenVPN server to associate IP addresses with the client certificate names found in the ipp.txt file at the startup but these associations
will never change afterwards.
293
Advanced Configuration
Caveat: the duplicate-cn option
The duplicate-cn option can be used to allow the same client certificate to connect to a number of times. If this option is used, the ifconfig-pool-persist option becomes
useless, as the same client certificate will be connected twice. This means that the OpenVPN server has to hand out two different IP addresses to each client and the entry in the ipp.txt file becomes meaningless.
When 'topology net30' is used
When the server option topology net30 is used (which is the default for OpenVPN 2.0) the format of the ipp.txt file is slightly different. In net30 topology mode, each client is assigned a /30 network address consisting of four IP addresses: the network address, the VPN server endpoint address, the actual client VPN IP address, and the broadcast address for the /30 network. In the ipp.txt file, the first of these is recorded:
openvpnclient1,192.168.200.4
openvpnclient2,192.168.200.8
Connecting using a SOCKS proxy
Under certain circumstances, it is not possible to directly connect to an OpenVPN server.
This happens most often when firewalls are restricting UDP-based traffic. In such cases,
OpenVPN can connect to an OpenVPN server via an intermediary host known as a proxy. OpenVPN supports two types of proxies: SOCKS and HTTP-based, both of which work only using TCP-based configurations. This recipe will outline how to access an OpenVPN server via a SOCKS proxy, whereas the next two recipes will show how to use an HTTP proxy, both with and without authentication.
SOCKS proxies can very easily be set up using almost any SSH client. On Linux and Mac OS X, it can be done using the ssh or slogin commands, whereas on Windows, the free SSH client PuTTY can be used.
Getting ready
We use the following network layout:
294
Chapter 11
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, example9-7-server.conf, from the Chapter 9's recipe Tuning TCP-based connections at hand. Keep the client configuration file, basic-tcp-client.conf, from the
Chapter 2's recipe Server-side routing at hand.
How to do it...
1.Start the server:
[root@server]# openvpn --config example9-7-server.conf
2.Add a line to the client configuration file basic-tcp-client.conf: socks-proxy 127.0.0.1 1080
Save this configuration file as example11-4-client.conf.
3.Set up an SOCKS proxy by setting up an SSH connection to the intermediary host:
[client]$ ssh -D 1080 proxy-host
4.In another terminal window, start the OpenVPN client:
The OpenVPN client first connects to the proxy listening on address 127.0.0.1 and port 1080 and it then sets up a connection to the OpenVPN server address.
295
Advanced Configuration
How it works...
A SOCKS proxy host acts as an intermediary between the (OpenVPN) client and the server.
SOCKS proxies can also be configured in most web browsers and are often used to gain access through a hotel or corporate firewall. The client first connects to the SOCKS proxy host and then requests a new connection to the actual endpoint, which is the OpenVPN server in this case. If the connection is allowed by the SOCKS host, the connection is established and the VPN connection can be set up.
There's more...
Before using a proxy host to set up a VPN connection, there are a few things to consider:
Performance
Proxy hosts tend to have a severe impact on the performance of a VPN setup. Both the bandwidth and the latency are usually affected when proxy hosts are used. This is mostly caused by having to connect to a separate host. There is little that can be done about this drop in performance.
Note #1 on SOCKS proxies via SSH
SSH can be a very handy tool to set up a SOCKS proxy, over which an OpenVPN connection can be set up. Apart from the drawback mentioned above, this introduces another penalty: both the SSH connection and the VPN connection will normally be encrypted. Thus, tunneling traffic over an encrypted VPN link which in itself is tunneled over an encrypted SSH link is double encrypted!
Note #2 on SOCKS proxies via SSH
A question that you should ask yourself if you are tunneling VPN traffic over an SSH tunnel is 'why?'. What type of traffic needs to be tunneled over a VPN link that cannot be tunnelled via a SOCKS-over-SSH tunnel? Most modern web browsers and e-mail clients have built-in support for SOCKS hosts, eliminating the need for a full-blown VPN. File sharing protocols such as Windows File Sharing (CIFS) can also be tunneled over an SSH connection. In those cases,
a VPN tunnel adds only extra complexity.
SOCKS proxies using plain-text authentication
In OpenVPN 2.2 and higher, support is added to connect to a SOCKS proxy that required authentication. For OpenVPN 2.2 plain-text authentication support is added. Though the name 'plain text' may suggest otherwise the authentication mechanism is secure, as the connection to the SOCKS proxy host is encrypted first.
296