Configuring IPsec

20:20:50.372185 193.110.157.131 > 205.150.200.209: ESP(spi=0xe5f72aaa,seq=0x1a)

20:20:50.402157 205.150.200.209 > 193.110.157.131: ESP(spi=0xc51033f4,seq=0x1a)

20:20:50.402623 193.110.157.131 > 205.150.200.209: ESP(spi=0xe5f72aaa,seq=0x1b)

20:20:50.413297 205.150.200.209 > 193.110.157.131: ESP(spi=0xc51033f4,seq=0x1b)

The packets are no longer visible as traceroute packets. All we see are IPsec packets using the ESP protocol. We can still see the plaintext packets, if we run tcpdump on the virtual interface:

# tcpdump -n -i ipsec0

18:00:44.130014 IP 193.110.157.17 > 205.150.200.209: icmp 64: echo request seq 0 20:20:44.144720 IP 205.150.200.209 > 193.110.157.17: icmp 64: echo reply seq 0 20:20:45.131177 IP 193.110.157.17 > 205.150.200.209: icmp 64: echo request seq 1 20:20:45.146790 IP 205.150.200.209 > 193.110.157.17: icmp 64: echo reply seq 1 20:20:46.132104 IP 193.110.157.17 > 205.150.200.209: icmp 64: echo request seq 2 20:20:46.147400 IP 205.150.200.209 > 193.110.157.17: icmp 64: echo reply seq 2

With NETKEY, things look a bit different:

# tcpdump -n -i eth0

00:08:15.311865 IP 193.110.157.131 > 205.150.200.209: ESP(spi=0xc7fb9fab,seq=0xb) 00:08:16.227426 IP 205.150.200.209 > 193.110.157.131: ESP(spi=0x55b8f8aa,seq=0x6) 00:08:16.227426 IP 205.150.200.209 > 193.110.157.131: icmp 64: echo reply seq 6 00:08:16.311724 IP 193.110.157.131 > 205.150.200.209: ESP(spi=0xc7fb9fab,seq=0xc) 00:08:17.275456 IP 205.150.200.209 > 193.110.157.131: ESP(spi=0x55b8f8aa,seq=0x7) 00:08:17.275456 IP 205.150.200.209 > 193.110.157.131: icmp 64: echo reply seq 7 00:08:17.311578 IP 193.110.157.131 > 205.150.200.209: ESP(spi=0xc7fb9fab,seq=0xd)

The unencrypted packet is caught and encrypted before it hits the Ethernet, so tcpdump only sees the encrypted packet going out. For the incoming packet, tcpdump first sees the encrypted packet coming in, and then it sees the same packet again, but in unencrypted form. This is because the NETKEY stack grabs the packet after it has been received (and seen by tcpdump), decrypts it, and then puts it back in the incoming packet stream, so tcpdump sees this packet too. If you used tcpdump on a machine further down the line, you would only see encrypted packets.

When using NETKEY, running tcpdump on the endpoint will give confusing results. To resolve this, run tcpdump on a router between the two IPsec endpoints, or hook up the endpoint to a hub, and attach another machine to the same hub and run tcpdump on that second machine.

Connecting Subnets Through an IPsec Connection

Now that we have our first host-to-host tunnel running, we can attempt to set up a subnet-to-subnet tunnel, which you'll find to be just as easy. The following example connection, when installed and activated on both West and East, will create a VPN tunnel between the networks Sunrise and Sunset:

conn sunset-sunrise left=193.110.157.131 leftsubnet=193.111.228.0/24 right=205.150.200.209

86

Chapter 4

rightsubnet=192.0.2.0/24

leftrsasigkey=0sAQ43A1....

rightrsasigkey=0sAQfP63....

auto=start

Remember that we are now abbreviating the key entries; in your file they will be the same as before, covering four lines. Also remember that to set up this new connection, you can edit the config file while Openswan is still running, and run the following command to activate it:

# ipsec auto --add sunset-sunrise

The eroute command will now show two tunnels:

# ipsec eroute
5	193.110.157.131/32	-> 205.150.200.209/32 => tun0x109a@205.150.200.209
0	193.111.228.0/24 ->	192.0.2.0/24	=> tun0x109b@205.150.200.209

One is our host-to-host tunnel from West to East, and the other is our new subnet-to-subnet tunnel from Sunrise to Sunset.

Testing Subnet Connections

Testing a subnet-to-subnet connection is a little bit trickier than testing a host-to-host connection. West has two IP addresses. On its external network interface it has the IP address 193.110.157.131, which is part of our host-to-host tunnel. On its internal network interface it has the IP address 193.111.228.1.

The question you have to ask is, "If I try to ping 192.0.2.13 from West, which IP address is it going to use?" Because if it is going to come from 193.110.157.131, the ping will fail, as there is no IPsec tunnel from 193.110.157.131 to 192.0.2.0/24. If it picked our internal address of 193.111.228.1, it would work, since that is covered by the policies of our subnet-to-subnet tunnel.

Unfortunately for us in this case, the ping will fail. The Linux kernel will automatically pick the closest IP address and use that as its source for the outgoing packet. On NETKEY, such packets will be dropped by the SPD's firewall in the IPsec stack. KLIPS, on the other hand, does not play firewall. It will allow this packet through, since it doesn't match any of its IPsec policies. The unencrypted packet would be sent onwards, and would likely be dropped by the next machine, which does not have a route for 192.0.2.0/24.

Testing Properly

If you can, the easiest method to test the subnet-to-subnet tunnel is to just walk over to a host in the Sunset LAN, for example 193.111.228.13, and ping a machine in the Sunrise LAN, for example 192.0.2.13. But in practice, a lot of this work is done remotely, and one cannot easily walk over to a machine in the other LAN.

The alternative is to specify which source address to use on our outgoing test packets. After all, the internal IP address of our gateway is part of the subnet range we just connected through an IPsec connection. Whether you can do this depends on the application, but ping, mtr, and traceroute all allow this. For example, on West we can ping a host in the Sunrise LAN, using West's own IP address from the Sunset LAN:

87