Chapter 11

There's more...

OpenVPN supports multiple authentication mechanisms when connecting to an HTTP proxy:

NTLM proxy authorization

OpenVPN also supports HTTP proxies that use NTLM proxy authorization, where NTLM stands for NT Lan Manager. Typically, this type of proxy is used in a Microsoft Windows environment. Unfortunately, OpenVPN's implementation of NTLM authorization is rather limited. It does not send out proper NTLMSSP messages and it works only with a very limited set of proxies.

To enable support for this type of proxy add:

http-proxy proxyhost proxyport stdin ntlm

or:

http-proxy proxyhost proxyport stdin ntlm2

where stdin instructs OpenVPN to query the username and password on the command prompt. This type of proxy authorization does not work well with the OpenVPN GUI

on Windows.

New features in OpenVPN 2.2

OpenVPN 2.2 adds support for HTTP digest authentication, which is more secure than the plain-text authentication outlined in this recipe.

It also adds the option auto-nct to the http-proxy authentication option to reject weak proxy authentication methods.

See also

The previous recipe in this chapter, where a connection is established using an HTTP proxy without extra authentication.

Using dyndns

Sometimes an OpenVPN server needs to be set up using a dynamic IP address. This means that OpenVPN clients need to connect to a different IP address every time the server's

IP address changes. This can happen often when the OpenVPN server is hooked up to the

Internet via an ADSL or cable modem connection. In this recipe, we will see how to configure a dynamic DNS name for the OpenVPN server and how the client can be configured to make use of the dynamic DNS name. As a dynamic DNS provider, the free dyndns.org service is used.

303

Advanced Configuration

Getting ready

For this recipe, the server computer was running CentOS 5 Linux and OpenVPN 2.1.3. The client computer was running Windows XP SP3 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.ovpn, from the Chapter 2 recipe Using an

'ifconfig-pool' block.

How to do it...

1.Register an account with a dynamic DNS service provider, such as dyndns.org.

2.Register a hostname and assign the current server's IP address to it. For this recipe, the hostname vpncookbook.dyndns.org was registered.

3.Check that the DNS name vpncookbook.dyndns.org resolves to the right IP address:

[server1]$ host vpncookbook.dyndns.org vpncookbook.dyndns.org has address 172.30.0.1

(the output was modified to hide the actual IP address used).

4.Set up the ddclient tool to easily update the dyndns.org's IP address. For this recipe, the following ddclient.conf file was used:

daemon=0

syslog=yes mail-failure=root

pid=/var/run/ddclient/ddclient.pid

ssl=yes

use=web, web=checkip.dyndns.org/, web-skip='IP Address' login=dyndns-username

password=dyndns-password server=members.dyndns.org, \ protocol=dyndns2 \ vpncookbook.dyndns.org

5.Start the server:

[root@server1]# openvpn --config basic-udp-server.conf

Change the client configuration file basic-udp-client.ovpn by changing the line: remote openvpnserver.example.com

to:

remote vpncookbook.dyndns.org resolv-retry 300

Save the configuration file as example11-7.ovpn.

304

Chapter 11

6. Start the OpenVPN connection:

The OpenVPN client will resolve the hostname vpncookbook.dyndns.org to the current IP address of the OpenVPN server.

7.Force a new IP address for vpncookbook.dyndns.org using either the web interface or the ddclient tool.

[root@server2]$ ddclient --verbose # output in /var/log/messages

8.Verify that the hostname vpncookbook.dyndns.org now resolves to the new IP address.

9.Start OpenVPN with the exact same configuration on the host with the new

IP address:

[root@server2]# openvpn --config basic-udp-server.conf

10.Now, shut down the original OpenVPN server. After a while, the OpenVPN client will reset and it will re-resolve the hostname vpncookbook.dyndns.org. This will lead it to connect to the new OpenVPN server.

How it works...

The dyndns service allows a user to freely register a hostname. This hostname is resolved to an IP address of choice, but the Time-To-Live flag of the DNS name is very short. This means that DNS servers around the world will cache the resolved IP address for only a very short period of time. The benefit is that if the IP address changes then the DNS resolution is rapidly updated.

By using the ddclient tool, we update the DNS-to-IP resolution as soon as a new IP address is assigned to a particular host. Use the --verbose flag and check the /var/log/messages log to troubleshoot the interaction of the ddclient tool and the dyndns web service.

On the OpenVPN client side, we use an extra directive:

resolv-retry 300

305

Advanced Configuration

to make sure the OpenVPN client tries to resolve the hostname found in the remote directive for 300 seconds (= 5 minutes) before giving up. If this directive is not added, then no retries are attempted. This means that there is a chance that the dyndns hostname will not resolve, causing the OpenVPN client to abort.

There's more...

Using dyndns can be a very powerful and flexible method for setting up a VPN server on a dynamic IP address. However, it does not provide fully automatic failover. On Linux servers, it does integrate quite nicely into the NetworkManager tool.

Failover

Note that even with the dyndns service, the OpenVPN client still needs to restart in order to reconnect to the server. OpenVPN currently does not support transparent failover, where all existing connections are kept intact during the restart. This was also stated in the recipe

Multiple remotes & remote-random earlier in this chapter.

NetworkManager and 'ddclient'

Newer versions of the Linux NetworkManager tool have a dispatcher plugin for ddclient. This plugin is launched whenever an interface receives a new IP address. The plugin can be configured to update the dyndns registration when this happens. This causes the hostname-to-IP address resolution to follow the assigned addresses automatically.

Note that this plugin will only be truly effective if the new IP address that the NetworkManager receives is the actual public IP address.

See also

The recipe Multiple remotes & remote-random earlier in this chapter.

IP-less setups (ifconfig-noexec)

The goal of this recipe is to create an OpenVPN tunnel without assigning IP addresses to the endpoints of the tunnel. In a routed network setup, this ensures that the tunnel endpoints can never be reached through themselves, which adds some security and can also make the routing tables a bit shorter. In the OpenVPN configuration files, an IP address needs to be specified, but it is never assigned to the tunnel interface.

This recipe has only been tested on Linux systems, as it requires some network-interface configuration that is not available on other platforms.

306

Chapter 11

Getting ready

We use the following network layout:

Set up the client and server certificates using the first recipe from Chapter 2, Client-server IP-only Networks. In this recipe, the server computer was running CentOS 5 Linux and OpenVPN 2.1.1. The client was running Fedora 12 Linux and OpenVPN 2.1.1. Keep the server config file, example3-1-server.conf, from the Chapter 3 recipe Simple configuration - non-bridged at hand.

How to do it...

1.Create the server configuration file by adding a line to the example3-1-server. conf file:

route 192.168.4.0 255.255.255.0 192.168.99.1 and save it as example11-8-server.conf.

2.Start the server:

[root@server]# openvpn --config example11-8-server.conf

3.Create the client configuration file:

client proto udp

remote openvpnserver.example.com port 1194

dev tap nobind

tls-auth /etc/openvpn/cookbook/ta.key 1 ns-cert-type server

307

Advanced Configuration

script-security 2 ifconfig-noexec

up /etc/openvpn/cookbook/example11-8-up.sh

route-noexec

route-up /etc/openvpn/cookbook/example11-8-route-up.sh

Save it as example-11-8-client.conf.

4.Next, create the example11-8-up.sh script:

#!/bin/bash

/sbin/ifconfig $1 0.0.0.0 up

# needed for TAP interfaces !!!

echo 1 > /proc/sys/net/ipv4/conf/$1/proxy_arp

and save it as /etc/openvpn/cookbook/example11-8-up.sh.

5.Similarly, for the example11-8-route-up.sh script:

#!/bin/bash

# add an explicit route back to the VPN endpoint /sbin/ip route add $route_vpn_gateway/32 dev $dev

n=1;

while [ $n -le 100 ] do

network=`env | sed -n \ "/^route_network_${n}=/s/^route_network_ ${n}=//p"`

netmask=`env | sed -n \ "/^route_netmask_${n}=/s/^route_netmask_${n}=//p"`

if [ -z "$network" -o -z "$netmask" ] then

break

fi

/sbin/ip route add $network/$netmask dev $dev let n=n+1

done

Save it as /etc/openvpn/cookbook/example11-8-route-up.sh.

6.Make sure both scripts are executable and both of them start the client:

[[root@client]# chmod 755 /etc/openvpn/cookbook/example11-8*.sh [root@client]# openvpn --config example11-8-client.conf

308

Chapter 11

7.After the client successfully connects to the OpenVPN server, check the tap0 interface and the routing tables, and verify that you can ping the server:

[root@client]# ifconfig tap0

[[root@client]# ping -c 2 192.168.99.1

PING 192.168.99.1 (192.168.99.1) 56(84) bytes of data.

64 bytes from 192.168.99.1: icmp_seq=1 ttl=64 time=25.7 ms 64 bytes from 192.168.99.1: icmp_seq=2 ttl=64 time=26.2 ms

How it works...

The OpenVPN server allocates an IP address for the client, but that does not mean that the client interface actually needs to assign these addresses. The example11-8-up.sh script does exactly this.

Some older Linux kernels refuse to add a route without an address being assigned to an interface. Hence, we assign the address 0.0.0.0 to the tun0 interface. To add the routes that are pushed by the server, a special route-up script is used, example11-8-route-up.sh, which brings up all the routes.

There's more...

Please note the following when considering an IP-less setup:

Point-to-point and TUN-style networks

This recipe can also be used in a point-to-point style environment, where static keys are used to connect two networks. Similarly, it can also be used in a TUN-style setup.

309

Advanced Configuration

Routing and firewalling

At first, this recipe might seem odd. The advantage of this setup is that the OpenVPN client itself is not reachable by other machines on the VPN. This is handy when connecting many clients to an OpenVPN server, but some clients are used as gateways to the networks behind them (for example, to connect a remote office to the OpenVPN server). By not assigning the remote office gateway an IP address, there is no risk of the gateway itself being attacked from the remote VPN side. Also, server-side firewalling and iptables rules can be slightly shorter in this scenario, as there will be no traffic coming from the OpenVPN client with the VPN source address. This is also the reason why the server configuration has an explicit route

to the client-side network:

route 192.168.4.0 255.255.255.0 192.168.99.1

310