Racoon Likes to Keep Secrets

Instead of manually changing the shared secrets in your
/etc/ipsec.conf file, you can keep one shared secret and use the
IKE protocol to negotiate a key. Racoon speaks IKE
(ISAKMP/Oakley), which is a key management protocol.

I installed Racoon from the ports tree. Here are the configuration files
from both my laptop and
the gateway.
The only difference between the two files is that I instruct the gateway to
listen on only one address (it has two NICs). Here is the diff, if you are
interested:

Pre-shared key File
Pre-shared key file defines a pair of the identifier and the shared
secret key which are used at Pre-shared key authentication method in
phase 1. The pair in each lines are separated by some number of blanks
and/or tab characters like hosts(5). Key can be included any blanks
because all of the words after 2nd column are interpreted as a secret
key. Lines start with #' are ignored. Keys which start with ' are
hexa-decimal strings. Note that the file must be owned by the user ID
running racoon(8) (usually the privileged user), and must not be accessi-
ble by others.

Here is the /usr/local/etc/racoon/psk.txt file on my
laptop:

10.0.0.1 MySecretValue

Here is the file from the wireless gateway:

10.0.0.10 MySecretValue

With these values, Racoon on my laptop knows that when it talks to 10.0.0.1
(the gateway) it should use the shared key MySecretValue.
Similarly, the Racoon running on the gateway knows to use the same shared key
when speaking to 10.0.0.10 (my laptop).

To start Racoon, issue this command:

/usr/local/etc/rc.d/racoon.sh start

If you're running a recent version of FreeBSD (for example, 4.10-RELEASE),
add this entry in /etc/rc.conf:

racoon_enable="YES"

Ensure that Racoon is running on both the laptop and the gateway. Then
remove the SAD entries from both machines, and Racoon should negotiate a new set
of keys.

# setkey -c
flush;
^D

If that doesn't work, try running Racoon in the foreground
(after first stopping the one running in the background):

/usr/local/sbin/racoon -F

It should just work.

Fun with Keys: Understanding What Happens

I thought it might be interesting to clear out the SAD entries and see what
happens when it comes time to negotiate new keys. I started a ping running and
ran tcpdump while I issued this command:

The lines that contain isakmp represent the two
Racoon daemons negotiating a new key.

As an experiment, I turned off IPsec on my laptop by commenting out the
ipsec_enable line in /etc/rc.conf. Then I rebooted.
Interestingly, I still received an IP address from my DHCP server on the other
side of the wireless gateway. However, I could not get through the gateway.
Even simple pings to the gateway went unanswered. At this time, the firewall on
the wireless gateway allowed all traffic to pass. Therefore, the gateway
rejected the traffic because it did not use IPsec.

To make IPsec work again, I did this while the ping was still running:

The first line populates the SPD1 database, based upon the data
within the file /etc/ipsec.conf. From there, Racoon
must negotiate a new key. It took some time (about 26 seconds), but
Racoon eventually succeeded. Immediately thereafter, the pings
resumed.

1Actually, the command populates only the SAD because the
file in question contains only add commands. I commented out
the spdadd commands.

DHCP Server

I mentioned above that I could still receive an IP address from my DHCP
server that was running on my gateway. I had not previously mentioned it, but
I think it might be useful to you. Here are the basics; the rest you should be
able to piece together yourself.

Installing dhcpd

Starting at boot time

This will install /usr/local/etc/rc.d/isc-dhcpd.sh. Remember to add
dhcpd_enable="YES" to /etc/rc.conf, or the script will not
start the server. I also added dhcpd_ifaces="dc0" so that
dhcpd would listen only on the one NIC--the one attached to the
same hub as the WAP.

The configuration file

The port installs /usr/local/etc/dhcpd.conf. It is full of
examples, but here is what I'm using, slightly altered to protect the
obvious:

That fixed-address relates to the following entry in
/etc/dhclient.conf:

send dhcp-client-identifier "laptop.example.org";

This allows the laptop to tell the DHCP server who it is, which I use to assign a specific IP address. Note: this method is convenient, but it is not
necessarily secure. If you're like me, sometimes using wireless with your
laptop and sometimes connecting via wire, then you might want to give it a
different IP address depending on where it is. I do that by having two DHCP
servers. I'm sure someone will suggest another method.

Is That Enough?

Now you have your wireless laptop connected to your LAN, with encrypted and
secured traffic. Nobody else can use your gateway unless they guess the
secret key. That's not easy. The key will change from time to time, so even
if someone guesses a key, there's a new one coming along soon. The only thing
you have to secure is the preshared secret. Don't use what I've supplied.
Come up with something odd, even some random values. Pick some text from IRC.
That should work.

Are you being paranoid enough? I think for one of my next tasks I will look
for any unusual traffic coming on the gateway, from any IP other than my
laptop. There are whole books written on intrusion detection, and that topic
is well beyond what I can cover here.

Enjoy.

Dan Langille
runs a consulting group in Ottawa, Canada, and lives in a house ruled by felines.