Set Up IPsec Under FreeBSD






Set Up IPsec Under FreeBSD

Use FreeBSD's built-in IPsec support to secure your traffic.

Using IPsec with IKE under FreeBSD requires enabling IPsec in the kernel and installing a user-land program, racoon , to handle the IKE negotiations.

Make sure that your kernel has been compiled with the following options:

options         IPSEC               #IP security
options         IPSEC_ESP           #IP security (crypto; define w/IPSEC)
options         IPSEC_DEBUG         #debug for IP security

If it hasn't, you'll need to define them and then rebuild and install the kernel. After you've done that, reboot to verify that it works.

You can install racoon by using the network section of the ports tree or by downloading it from ftp://ftp.kame.net/pub/kame/misc/. Install raccoon per the instructions provided with the distribution.

On the client, you should first configure racoon by modifying this example racoon.conf file to suit your needs:

path include "/usr/local/etc/racoon" ;
path pre_shared_key "/usr/local/etc/racoon/psk.txt" ;
remote anonymous
{
        exchange_mode aggressive,main;
        my_identifier user_fqdn "[email protected]";
        lifetime time 1 hour;
        initial_contact on;

        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key ;
                dh_group 2 ;
        }
}
sainfo anonymous
{
        pfs_group 1;
        lifetime time 30 min;
        encryption_algorithm 3des ;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate ;
}

In your firewall configuration, be sure you allow IKE connections to your machine (UDP port 500). You must configure racoon to start at boot time.

Client Configuration

The /usr/local/etc/racoon/psk.txt file contains your credentials. This file must be readable by root only. If the permissions are not set correctly, racoon will not function. For a shared-secret IPsec connection, the file contains your identification (in this case, your email address) and the secret, in this format:

               [email protected]     supersecret
            

Now, set up the security policy, using the setkey utility to add entries to the kernel Security Policy Database (SPD). Create a client.spd file for setkey to load, with entries like the following:

spdadd 192.168.0.104/32 0.0.0.0/0 any -P out ipsec \ 
  esp/tunnel/192.168.0.104-192.168.0.1/require ; 
spdadd 0.0.0.0/0 192.168.0.104/32 any -P in ipsec \ 
  esp/tunnel/192.168.0.1-192.168.0.104/require ;

For this setup, the station IP is 192.168.0.104 and the gateway is 192.168.0.1. The first entry creates a security policy that sends all traffic to the VPN endpoint. The second entry creates a security policy that allows all traffic back from the VPN endpoint.

In this configuration, the client is unable to talk to any hosts on the local subnet, except for the VPN gateway. In a wireless network where the client is a prime target for attack, this is probably a good thing for your workstation.


Load the SPD by running the following command:

# setkey -f client.spd
            

The gateway racoon.conf is the same as the file for the client side. This allows any client to connect. The psk.txt file must contain the identifications and shared secrets of all clients who can connect:

[email protected]      supersecret
[email protected]      evenmoresecret
[email protected]      notsosecret

Gateway Configuration

Again, make sure psk.txt is readable by root only. Start racoon and make sure there are no errors. Finally, set up a gateway.spd file that creates an SPD for each client. The following example assumes your clients are at 192.168.0.10[4-6]:

spdadd 0.0.0.0/0 192.168.0.104/32 any -P out ipsec \
  esp/tunnel/192.168.0.1-192.168.0.104/require ; 
spdadd 192.168.0.104/32 0.0.0.0/0 any -P in ipsec \
  esp/tunnel/192.168.0.104-192.168.0.1/require ; 
spdadd 0.0.0.0/0 192.168.0.105/32 any -P in ipsec \
  esp/tunnel/192.168.0.1-192.168.0.105/require ; 
spdadd 192.168.0.105/32 0.0.0.0/0 any -P out \
  ipsec esp/tunnel/192.168.0.105-192.168.0.1/require ; 
spdadd 0.0.0.0/0 192.168.0.106/32 any -P in ipsec \
  esp/tunnel/192.168.0.1-192.168.0.106/require ; 
spdadd 192.168.0.106/32 0.0.0.0/0 any -P out ipsec \
  esp/tunnel/192.168.0.106-192.168.0.1/require ; 

Load the SPD by issuing setkey -f gateway.spd. Verify the SPD entries using the spddump command in setkey. At this point, you should be able to ping a client from the gateway. It might take a packet or two for the VPN negotiation to complete, but the connection should be solid after that. If you are unable to ping, examine your syslog output for errors and warnings.

Using x.509 Certificates

You can use x.509 certificates to perform authentication instead of a preshared key, but if you're going to do this, you'll first need to set up a Certificate Authority (CA) [Hack #69]. After you've done that, modify your racoon.conf file to look like this:

path certificate "/etc/ssl";
remote anonymous
{
        exchange_mode main;
        lifetime time 1 hour;
        certificate_type x509 "cletus.crt" "cletus.key";
        verify_cert on;
        my_identifier asn1dn;
        peers_identifier asn1dn;

        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method rsasig;
                dh_group 2;
        }
}
sainfo anonymous
{
        pfs_group 1;
        lifetime time 30 min;
        encryption_algorithm 3des ;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate ;
}

With this configuration, racoon expects to find the x.509 certificates in /etc/ssl, so copy your certificate/key pair (cletus.crt and cletus.key) to the location you decide to use. On your other systems, modify the configuration file accordingly, replacing the certificate and key filenames with the proper ones for each system.

Copy your CA's certificate to your certificate directory. This will be used to verify that your CA has signed the certificates on each system. If it has, they'll be allowed to connect.

You'll notice that the CA certificate isn't specified anywhere in the configuration file. This is because racoon looks for it in a filename named after a hash of it. To enable racoon to find the CA cert, run a command similar to this:

# ln -s CA.crt \Qopenssl x509 -noout -hash < CA.crt\Q.0
            

The previous command assumes that you've copied your CA certificate to /etc/ssl and named it CA.crt.


Restart racoon by running /usr/local/etc/rc.d/racoon restart. Now, you can test it by having the hosts ping each other. Then, run tcpdump on one of your systems. You should begin to see ESP packets:

# tcpdump -n 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lnc0, link-type EN10MB (Ethernet), capture size 96 bytes
03:35:57.481254 IP 192.168.0.40 > 192.168.0.41: ESP(spi=0x05d628a3,seq=0xd)
03:35:57.483451 IP 192.168.0.41 > 192.168.0.40: ESP(spi=0x0c53fadb,seq=0xd)
03:35:58.490287 IP 192.168.0.40 > 192.168.0.41: ESP(spi=0x05d628a3,seq=0xe)
03:35:58.491160 IP 192.168.0.41 > 192.168.0.40: ESP(spi=0x0c53fadb,seq=0xe)
03:35:59.500509 IP 192.168.0.40 > 192.168.0.41: ESP(spi=0x05d628a3,seq=0xf)
03:35:59.501289 IP 192.168.0.41 > 192.168.0.40: ESP(spi=0x0c53fadb,seq=0xf)

These are the ping packets in encrypted form.



 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows