This section demonstrates the process of setting up IPsec. It assumes familiarity with the concepts of building a custom kernel (see Chapter 9, Configuring the FreeBSD Kernel).
IPsec is a protocol which sits on top of the Internet Protocol (IP) layer. It allows two or more hosts to communicate in a secure manner. The FreeBSD IPsec “network stack” is based on the KAME implementation, which has support for both IPv4 and IPv6.
IPsec consists of two sub-protocols:
Encapsulated Security Payload ESP): this protocol protects the IP packet data from third party interference by encrypting the contents using symmetric cryptography algorithms such as Blowfish and 3DES.
Authentication Header (AH): this protocol protects the IP packet header from third party interference and spoofing by computing a cryptographic checksum and hashing the IP packet header fields with a secure hashing function. This is then followed by an additional header that contains the hash, to allow the information in the packet to be authenticated.
ESP and AH can either be used together or separately, depending on the environment.
IPsec can either be used to directly encrypt the traffic between two hosts using Transport Mode or to build “virtual tunnels” using Tunnel Mode. The latter mode is more commonly known as a Virtual Private Network (VPN). Consult ipsec(4) for detailed information on the IPsec subsystem in FreeBSD.
To add IPsec support to the kernel, add the following options to the custom kernel configuration file:
If IPsec debugging support is desired, the following kernel option should also be added:
There is no standard for what constitutes a VPN. VPNs can be implemented using a number of different technologies, each of which has their own strengths and weaknesses. This section presents the strategies used for implementing a VPN for the following scenario:
There are at least two sites where each site is using IP internally.
Both sites are connected to the Internet through a gateway that is running FreeBSD.
The gateway on each network has at least one public IP address.
The internal addresses of the two networks can be
either public or private IP addresses. However, the
address space must not collide. For example, both
networks cannot use
192.168.1.x.
To begin,
security/ipsec-tools
must be installed from the Ports Collection. This software
provides a number of applications which support the
configuration.
The next requirement is to create two gif(4)
pseudo-devices which will be used to tunnel packets and
allow both networks to communicate properly. As
root, run the following commands,
replacing internal and
external with the real IP
addresses of the internal and external interfaces of the two
gateways:
# ifconfig gif0 create# ifconfig gif0 internal1 internal2# ifconfig gif0 tunnel external1 external2In this example, the corporate LAN's
external IP address is
172.16.5.4 and its internal
IP address is
10.246.38.1. The home
LAN's external IP
address is 192.168.1.12 and
its internal private IP address is
10.0.0.5.
If this is confusing, review the following example output from ifconfig(8):
Once complete, both internal IP addresses should be reachable using ping(8):
As expected, both sides have the ability to send and receive ICMP packets from the privately configured addresses. Next, both gateways must be told how to route packets in order to correctly send traffic from either network. The following command will achieve this goal:
# corp-net# route add 10.0.0.0 10.0.0.5 255.255.255.0# corp-net# route add net 10.0.0.0: gateway 10.0.0.5# priv-net# route add 10.246.38.0 10.246.38.1 255.255.255.0# priv-net# route add host 10.246.38.0: gateway 10.246.38.1At this point, internal machines should be reachable from each gateway as well as from machines behind the gateways. Again, use ping(8) to confirm:
Setting up the tunnels is the easy part. Configuring a
secure link is a more in depth process. The following
configuration uses pre-shared (PSK)
RSA keys. Other than the
IP addresses, the
/usr/local/etc/racoon/racoon.conf on
both gateways will be identical and look similar to:
For descriptions of each available option, refer to the
manual page for racoon.conf.
The Security Policy Database (SPD) needs to be configured so that FreeBSD and racoon are able to encrypt and decrypt network traffic between the hosts.
This can be achieved with a shell script, similar to the
following, on the corporate gateway. This file will be used
during system initialization and should be saved as
/usr/local/etc/racoon/setkey.conf.
Once in place, racoon may be started on both gateways using the following command:
# /usr/local/sbin/racoon -F -f /usr/local/etc/racoon/racoon.conf -l /var/log/racoon.logThe output should be similar to the following:
To ensure the tunnel is working properly, switch to
another console and use tcpdump(1) to view network
traffic using the following command. Replace
em0 with the network interface card as
required:
# tcpdump -i em0 host 172.16.5.4 and dst 192.168.1.12Data similar to the following should appear on the console. If not, there is an issue and debugging the returned data will be required.
At this point, both networks should be available and seem to be part of the same network. Most likely both networks are protected by a firewall. To allow traffic to flow between them, rules need to be added to pass packets. For the ipfw(8) firewall, add the following lines to the firewall configuration file:
The rule numbers may need to be altered depending on the current host configuration.
For users of pf(4) or ipf(8), the following rules should do the trick:
Finally, to allow the machine to start support for the
VPN during system initialization, add the
following lines to /etc/rc.conf:
All FreeBSD documents are available for download at http://ftp.FreeBSD.org/pub/FreeBSD/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.