Enterprise Implementation

Similar commands can be used to view and set DMA hard disk transfers, but with the options -d and -d 1. RAID or LVM can also influence the speed with which log files can be written to disk, though this is often not in use on VPN servers, since in general people build entire fail-over servers for VPNs rather than a simple disk fail-over scheme, since the disks in the VPN servers normally contain no user data apart from log files.

Disable Dead Peer Detection

You might want to consider whether or not DPD is a feature that you want to run on a busy VPN server. We have heard reports that DPD can cause a big slowdown in certain deployment scenarios. On the other hand, DPD is a nice feature for kicking out roadwarriors that have left without nicely closing down, something that might also impact on a large VPN server negatively. Play with these settings if you are encountering performance issues to see what works best in your scenario.

Reducing the Number of Tunnels

As each network combination requires a tunnel be established, in large networks with noncontiguous network blocks this can quickly add up to hundreds of tunnels between only a few IPsec peers. This is not ideal, and fortunately there are ways to reduce the number of tunnels, provided both ends are running Openswan.

Depending on your network topology, you may be able to reduce the number of tunnels down to one—a single host-to-host tunnel. You must set up a GRE (Generic Routing Encapsulation) tunnel between the two IPsec peers, and then either use static routes, or run a dynamic routing daemon, such as Quagga, Zebra, or GateD, to manage the network routing.

Packets are then encapsulated into GRE packets, which are in turn placed into the ESP packets exchanged between peers. The resulting packet as it goes over the wire looks like this:

Once you bring up your IPsec tunnel, you will need to add a GRE tunnel on top of it. This is best done by hooking into the _updown scripts.

The following sample script will bring up a GRE tunnel:

#!/bin/sh

#$remote_ip = External IP of remote Gateway

#$local_ip = External IP of local Gateway

#$local_tun_ip = Local IP for the GRE tunnel (Usually RFC 1918 based)

#$remote_tun_ip = IP address on the other side of the GRE tunnel (usually

#RFC1918 based)

ip tunnel add myGREtunnel mode gre remote $remote_ip local \ $local_ip ttl 255 ip link set myGRELtunnel up

ip addr add $local_tun_ip dev myGREtunnel ip route add $remote_tun_ip dev myGREtunnel

260

Chapter 11

Once your GRE tunnel is established, you can route as many networks as you want over your GRE tunnel. Here we will route some 192.168.x.x networks and the 172.16.0.0/18 address space over the tunnel.

ip route add 192.168.0.0/24 $remote_tun_ip ip route add 192.168.5.0/24 $remote_tun_ip ip route add 192.168.6.0/24 $remote_tun_ip ip route add 172.16.0.0/16 $remote_tun_ip

Taking this a step further, you can use dynamic routing protocols such as OSPF or BGPv4 to automatically set up the routing for you. Three options currently exist for doing this—Zebra, Quagga, and OpenBGP. Quagga is actually a fork of the GNU Zebra project, so both share the same configuration syntax. OpenBGP has just been released at the time of writing and the authors have no operational experience with it as yet.

OSPF Setup

The following configuration uses OSPF to propagate all local routes (including directly connected networks, as well as static routes) to the remote peer.

interface	myGREtunnel
ip ospf	network point-to-point

router ospf

ospf router-id 192.168.0.1 redistribute kernel redistribute connected redistribute static

network 10.1.20.1/32 area 0

BGPv4 Setup

The following sample Zebra/Quagga config stanza shows a configuration for BGPv4 between two peers, who are willing to send any RFC 1918 traffic between them.

!Use private AS numbers for this router bgp 65432

!Our local GRE tunnel IP address bgp router-id 192.168.0.1

!Networks we are willing to share network 10.0.0.0/8

network 172.16.0.0/18 network 192.168.0.0/16

!Same AS as us

neighbor 192.168.0.2 remote-as 65432

!Important - sets our GRE address as the next-hop neighbor 192.158.0.2 next-hop-self

neighbor 192.168.0.2 distribute-list 101 out neighbor 192.168.0.2 distribute-list 101 in

!Permit RFC1918 networks to be shared.

access-list 101 permit 10.0.0.0/8 access-list 101 permit 172.16.0.0/18 access-list 101 permit 192.168.0.0/16

261