10

Encrypting the Local Network

We have now covered various methods for setting up a VPN connection between two hosts or two subnets over the Internet. However, in recent years a new problem has surfaced in the form of wireless internet connections such as 802.11 (WiFi) and Bluetooth. The need for encryption, even when two machines are next to each other in the same room, is stronger than ever. This chapter explains how to encrypt internal LAN connections using IPsec.

As with most emerging technologies, various vendors are implementing methods to protect the link layer against rogue intrusions, or methods for removing compromised hosts from the network. The IETF Dynamic Host Configuration working group (the same group that wrote the DHCP standard) is working on protecting the DHCP protocol with encryption, based on DNSSEC. Meanwhile, Microsoft has been adding a feature called Network Access Protection (NAP) into its latest beta releases of Windows, Longhorn, and Vista. These technologies are still being developed and tested, while IPsec technology has been around for a while and is supported on most platforms. Why not use IPsec to secure and encrypt LAN traffic?

Methods of Encryption

There are a few different ways to accomplish the task of securing the local network with IPsec encryption.

Host-to-Host Mesh

If you only have a handful of machines, you could set up a full mesh of IP connections. This solution is the easiest to set up, very ugly, and a nightmare to maintain. For three servers (A, B, and C), you need to configure three IPsec tunnels (AB, AC, and BC). For four servers you need six IPsec connections, for five servers ten connections. In general, you would need (n-1) * n/2 connections for n servers. These are straightforward host-to-host IPsec connections, containing:

conn ab left=a.b.c.d right=a.b.c.e

Sometimes host-to-host connections seem to fail in the LAN. If this happens to you, try

adding type=%direct to the conn

Encrypting the Local Network

Host-to-Gateway Setup

A slightly more advanced setup is where all machines have an IPsec connection to the default gateway, and they tunnel all traffic through this connection. However, this is not as simple as it may appear. Image you have:

conn ab left=a.b.c.d right=a.b.c.1

rightsubnet=0.0.0.0/0

Packets for a.b.c.e would still not be guaranteed to go through this tunnel. First of all, we have found inconsistent behavior on Windows in such a setup. Secondly, when using KLIPS, the problem is that it depends on the additional kernel routes into the ipsecX device, and since we are trying to connect to a machine in the same LAN, the routing is not used at all. The machine will simply send an ARP request to obtain the MAC address of the ethernet card of the other machine and then send the packet directly over the Ethernet (or over the real ether if this is a wireless connection). As a result, KLIPS never gets to see this packet and will not be able to send it over an IPsec connection. With NETKEY, however, this should not be a problem.

Single IP Extrusiautomation or L2TP

The next solution is to extrude an IP address onto machines in the LAN from the gateway using IPsec, and then use this IP address for all communication. The outer IP would be firewalled to only allow IPsec (or L2TP). Although such a setup would probably work, it has not been extensively tested. It requires two IP addresses per machine—each belonging to a different subnet. The first DHCP IP address can be anything from a large pool of IP addresses, such as 10.0.0.0/16. The second IP address is then taken from a pool that only hands out /32 addresses. That is, it does not come from a pool of /24 or /16. Since each address is a /32, it turns the link into the equivalent of a point-to-point link. All traffic from that IP is sent over the IPsec (or L2TP) tunnel.

However, administration of this type of setup is difficult. L2TP makes it easier, but requires Transport mode IPsec, and a RADIUS server to scale. It requires IP packets to be sent within IPsec packets, which means that packet sizes are decreased for the inner IP to prevent IP fragmentation. And it requires twice as many IP addresses. It is far from ideal.

Opportunistic Encryption in the LAN

If the LAN consists purely of Linux machines, our task would be easier. After all, Opportunistic Encryption, as explained in Chapter 5, allows each machine to find the key of any other machine and set up an IPsec tunnel based on the IPsec key information in the reverse zone of the local IP range used. Unfortunately, this still presents various problems.

The biggest problem at this point is that NETKEY currently does a very poor job when deployed as part of an Opportunistic Encryption setup because it lacks the packet-caching features needed for dynamically setting up tunnels. KLIPS, on the other hand, needs the routing hack that fails in the LAN, unless we copy the split default route trick as a split the local LAN route trick. We covered this route hack in Chapter 6.

236