Cryptosystems: Configuring IPSec
Pages: 1, 2, 3

Next I'll create the file that contains the pre-shared secret:

$ vi /usr/local/etc/racoon/psk.txt

#peer's external ip	pre-shared secret
B.B.B.B			dontguessme

That file needs to exist on both peers. The file on Gateway A uses B's external IP; the file on Gateway B uses A's external IP. Doublecheck for typos in the password itself, especially if you use a hard to guess password, which you should.

It's important to remember to change the default permissions of this file on both gateways or else Phase One will fail:

$ chmod 600 /usr/local/etc/racoon/psk.txt

At this point, racoon is configured and ready to go. I just need a few more configurations to tell FreeBSD about the VPN. The installation of racoon creates a startup script:

$ more /usr/local/etc/rc.d/racoon.sh

#!/bin/sh

case "$1" in
   start)
      if [ -x /usr/local/sbin/racoon ]; then
         /usr/local/sbin/racoon -f /usr/local/etc/racoon/racoon.conf \
            && echo -n ' racoon'
      fi
   ;;

   stop)
      /usr/bin/killall racoon && echo -n ' racoon'
   ;;
	
   *)
      echo "Usage: `basename $0` { start | stop }"
      exit 64
   ;;
esac

That line between if and fi starts racoon at bootup using the configuration file specified by the f switch. However, I like to modify that line so it also includes the l or logging switch which tells racoon to log to the specified file. My modified line looks like this:

/usr/local/sbin/racoon -f /usr/local/etc/racoon/racoon.conf -l 
/var/log/racoon.log && echo -n ' racoon'

Note that the output was wrapped so you could see it; when you modify that line, just do one long line without pressing enter until you are finished.

You don't have to go in and create that log file using the touch command as racoon will create the file for you.

One last thing I add to the end of that file is a command that tells the system which packets need to be sent over the tunnel. For example, on Gateway A, any packets being sent to 192.168.1.x (the encryption domain of Gateway B) need to go through the VPN tunnel. So on Gateway A, I include this line:

/sbin/route add -net 192.168.1.0/24 10.0.0.1

That line basically says, if you need to go to network 192.168.1.0, go to 10.0.0.1 so you can be routed correctly into the VPN tunnel. If you're new to CIDR prefixes, you might not recognize the /24 part. That is the other way of writing the subnet mask of 255.255.255.0 as it is really 8 bits (255) + 8 bits + 8 bits + 0 bits = 24.

On Gateway B, I do the opposite as I want to go to Gateway A's encryption domain:

/sbin/route add -net 10.0.0.0/8 192.168.1.1

The /8 is the same as the subnet mask of 255.0.0.0. Technically, that line can be added to any script that is read at bootup, so you may see it in different files as you read various tutorials. I prefer to place it in racoon.sh as it reminds me that the route is used for the VPN tunnel.

We're almost finished with the configurations. A few lines need to be added to /etc/rc.conf. I'll add these lines to Gateway A:

ipsec_enable="YES"
ipsec_file="/etc/ipsec.conf"
gif_interfaces="gif0"
ifconfig_gif0="10.0.0.1 netmask 255.0.0.0 192.168.1.1 netmask 255.255.255.0"
gifconfig_gif0="A.A.A.A netmask 255.255.240.0 B.B.B.B netmask 255.255.240.0"

The first two lines ensure IPSec support is loaded at bootup. We'll be creating that IPSec file in just a moment.

The gif_interfaces command creates a pseudo device that represents the tunnel. Technically, this isn't required in order for the tunnel to work, but it does make it a bit easier to troubleshoot the tunnel and you'll notice that most tutorials mention it. If you'd like a further explanation on this, there was a very interesting discussion in the mailing lists this past summer.

The last two lines tell your FreeBSD system which addresses to use in the headers. Remember that in tunnel mode the original IP packet contains the IP addresses of the real source and destination, which are usually private range addresses withing the two encryption domains. The new IP header created by ESP contains the external IP addresses of the two VPN gateways.

The ifconfig_gif0 command contains the internal IP addresses of the two gateways and the gifconfig_gif0 command contains the external IP addresses of the two gateways. On Gateway A, you should place Gateway A's IP addresses first, followed by Gateway B's. On Gateway B, switch the order so Gateway B's addresses are first.

The last file we need to create is ipsec.conf. At first, this file seems redundant as it creates the policy stored in the SPD. You may be thinking, "I've already configured that policy in racoon.conf". Actually, you only told racoon (or the IKE protocol) what policy parameters it should use when negotiating the SAs which will be placed in the SAD. However, racoon can't place the policy in the SPD for you; that is the job of setkey. Creating /etc/ipsec.conf means you won't have to run setkey manually every time you reboot.

My file on Gateway A looks like this:

$ more /etc/ipsec.conf

#delete all existing entries from the SAD and SPD databases
flush;
spdflush;

#add the policy to the SPD database
spdadd 10.0.0.0/8 192.168.1.0/24 any -P out ipsec
esp/tunnel/A.A.A.A-B.B.B.B/require;

spdadd 192.168.1.0/24 10.0.0.0/8 any -P in ipsec
esp/tunnel/B.B.B.B-A.A.A.A/require;

The policy lines (the two lines that start with spdadd) aren't one long wrapped line, meaning you can press enter after the word ipsec. The first policy line says whenever packets from network 10.0.0.0 need to go "out" to network 192.168.1.0, they are "required" to be encrypted by esp and to go through the tunnel that goes from Gateway A to Gateway B.

The second policy line says that whenever packets from network 192.168.1.0 need to come "in" to network 10.0.0.0, they are "required" to be encrypted by esp and to go through the tunnel that goes from Gateway B to Gateway A.

The file on Gateway B will be similar, but the addresses will be reversed so "in" and "out" match up. See why it is handy to have a sketch of your network so you can remember which address belongs where?

We've covered a lot this article. Next week, I'll show you what to watch out for when you reboot your computer after the configurations are complete. We'll then test the tunnel and work through some troubleshooting scenarios. In the meantime, you may found the following URLs useful:

• The FreeBSD Handbook's IPSec section
• http://www.kame.net/
• http://asherah.dyndys.org/~josh/ipsec-howto.txt
• Setting up a FreeBSD IPSec Tunnel

Dru Lavigne is a network and systems administrator, IT instructor, author and international speaker. She has over a decade of experience administering and teaching Netware, Microsoft, Cisco, Checkpoint, SCO, Solaris, Linux, and BSD systems. A prolific author, she pens the popular FreeBSD Basics column for O'Reilly and is author of BSD Hacks and The Best of FreeBSD Basics.

---

Read more FreeBSD Basics columns.

Return to the BSD DevCenter.