Integration of Checkpoint VPN-1/FW-1 with FreeBSD's IPSEC

By Jon Orbeton and Matt Hite

May 25, 2001 - This document explains how to configure a VPN tunnel between FreeBSD and Check Point's VPN-1/Firewall-1. Other documents provide similar information, but do not contain instructions specific to VPN-1/Firewall-1 and their integration with FreeBSD. These documents are listed at the conclusion of this paper for further reference.

Although it was not tested, with some modification this procedure should work with NetBSD and other platforms that include KAME integration.

The following is a diagram of the machines and networks referenced in this document.

     External Interface                    External Interface
          208.229.100.6                    216.218.197.2
                      |                    |
        +--> Firewall-1 <--> Internet <--> FreeBSD GW <--+
        |                                                |
 FW-1 Protected Nets                              Internal Nets
    199.208.192.0/24                                  192.168.10.0/24

The FreeBSD GW serves as a firewall and NAT device for "internal nets."


Prerequisites

The FreeBSD kernel must be compiled to support IPSEC. Use the following kernel options:

	options		IPSEC
	options		IPSEC_ESP
	options		IPSEC_DEBUG

For instructions on building a custom kernel, refer to the FreeBSD handbook.

Please note that IP protocol 50 (ESP) must be allowed through the FreeBSD GW firewall.

Also, racoon must be installed to support key exchange. It's included in the FreeBSD ports collection in /usr/ports/security/racoon. (The racoon configuration file will be covered later in this document.)


Firewall-1 Network Object Configuration

Begin by configuring the Firewall-1 Policy. Open the Policy Editor on the Firewall-1 Management server and create a new "Workstation" Network Object representing FreeBSD GW.

General Tab:
Set name and IP address

VPN Tab:
Encryption Schemes Defined:             IKE               ---> Edit

IKE Properties:
Key Negotiation Encryption Methods:     3DES
Authentication Method:                   Pre-Shared Secret ---> Edit

Select the Firewall Object and set a pre-shared secret. (Don't use our example one.)

Support Aggressive Mode:                 Checked
Supports Subnets:                       Checked

After setting the pre-shared secret in the Firewall-1 Network Object definition, place this secret in /usr/local/etc/racoon/psk.txt on FreeBSD GW. The format for psk.txt is:

208.229.100.6		rUac0wtoo?


Firewall-1 VPN Rule Configuration

Next, create a Firewall-1 rule enabling encryption between the FreeBSD GW and the Firewall-1 protected network. In this rule, the network services permitted through the VPN must be defined.

Source            | Destination        | Service      | Action  | Track
------------------------------------------------------------------------
FreeBSD GW        | FW-1 Protected Net | VPN services | Encrypt | Long
FW-1 Protected Net| FreeBSD GW         |              |         |

"VPN services" are any services (i.e. telnet, ssh, ntp, etc.) remote hosts are permitted to access through the VPN. Use caution when permitting services; hosts connecting through a VPN still represent a potential security risk. Encrypting the traffic between the two networks offers little protection if a host on either side of the tunnel has been compromised.

Once the rule specifying data encryption between the FreeBSD GW and the Firewall-1 protected network has been configured, review the "Action Encrypt" settings.

Encryption Schemes Defined:     IKE ---> Edit
Transform:                      Encryption + Data Integrity (ESP)
Encryption Algorithm:           3DES
Data Integrity:                 MD5
Allowed Peer Gateway:           Any or Firewall Object
Use Perfect Forward Secrecy:    Checked

The use of Perfect Forward Secrecy (PFS) is optional. Enabling PFS will add another layer of encryption security, but does come at the cost of increased CPU overhead. If PFS is not used, uncheck the box above and comment out the "pfs_group 1" line from racoon.conf on FreeBSD GW. (An example racoon.conf is provided later in this document.)


BSD VPN Policy Configuration

Next, the VPN policy on FreeBSD GW must be defined. The setkey tool performs this function. The following is a shell script used to automate this process.

kame-bsd.sh

#!/bin/sh
#
# IP addresses
#
#     External Interface                    External Interface
#          208.229.100.6                    216.218.197.2
#                      |                    |
#        +--> Firewall-1 <--> Internet <--> FreeBSD GW <--+
#        |                                                |
# FW-1 Protected Nets                              Internal Nets
#    199.208.192.0/24                                  192.168.10.0/24
#
setkey -FP
setkey -F
# Configure the Policy
setkey -c << END
spdadd 216.218.197.2/32 199.208.192.0/24 any -P out ipsec
esp/tunnel/216.218.197.2-208.229.100.6/require;
spdadd 199.208.192.0/24 216.218.197.2/32 any -P in ipsec
ESP/tunnel/208.229.100.6-216.218.197.2/require;
END

Execute the script to issue the setkey commands:

sh ./kame-bsd.sh


BSD Racoon Configuration

To facilitate the negotiation of IPSec keys on FreeBSD GW, racoon must be installed and configured. Racoon is included in the FreeBSD ports collection.

The following is a racoon configuration file suitable for use with the examples outlined in this document.

/usr/local/etc/racoon/racoon.conf

# racoon.conf for use with Check Point VPN-1/Firewall-1
#
#
# Pre-shared key set on the VPN-1 server.
#
# WARNING: psk.txt must have mode 600 permission.

path pre_shared_key "/usr/local/etc/racoon/psk.txt" ;

#
log debug;

# "padding" defines some parameter of padding.  You should not touch these.
padding
{
        maximum_length 20;      # maximum padding length.
        randomize off;          # enable randomize length.
        strict_check off;       # enable strict check.
        exclusive_tail off;     # extract last one octet.
}

# Specification of default various timer.
timer
{
        # These value can be changed per remote node.
        counter 5;              # maximum trying count to send.
        interval 20 sec;        # maximum interval to resend.
        persend 1;              # the number of packets per a send.

        # Timer for waiting to complete each phase.
        phase1 30 sec;
        phase2 15 sec;
}

remote anonymous
{
        exchange_mode aggressive,main; # For Firewall-1 Aggressive mode

        #my_identifier address;
        #my_identifier user_fqdn "";
        #my_identifier address "";
        #peers_identifier address "";
        #certificate_type x509 "" "";

        nonce_size 16;
        lifetime time 10 min;    # sec,min,hour
        lifetime byte 5 MB;     # B,KB,GB
        initial_contact on;
	support_mip6 on;
        proposal_check obey;    # obey, strict or claim

        proposal {
                encryption_algorithm 3des;
                hash_algorithm md5;
                authentication_method pre_shared_key;
                dh_group 2 ;
        }
}

sainfo anonymous
{
        pfs_group 1;
        lifetime time 10 min;
        lifetime byte 50000 KB;
        encryption_algorithm 3des;
        authentication_algorithm hmac_md5;
        compression_algorithm deflate ;
}

Ensure that /usr/local/etc/racoon/psk.txt contains the shared secret configured in the "Firewall-1 Network Object Configuration" section of this document and has mode 600 permissions.


Starting the VPN

You are now ready to launch racoon and test the VPN tunnel. For debugging purposes, open the Firewall-1 Log Viewer and define a log filter to isolate entries pertaining to FreeBSD GW. You may also find it helpful to tail the racoon log:

tail -f /var/log/racoon.log

Start racoon using the following command:

/usr/local/sbin/racoon -f /usr/local/etc/racoon/racoon.conf

Once racoon has been launched, telnet to a host on the Firewall-1 protected network.

telnet -s 192.168.10.3 199.208.192.66 22

This command attempts to connect to the SSH port on 199.208.192.66, a machine in the Firewall-1 protected network. The -s switch indicates the source interface of the outbound connection. This is particularly important when running NAT and IPFW on FreeBSD GW. Using -s and specifying an explicit source address prevents NAT from mangling the packet prior to tunneling.

A successful racoon key exchange will output the following to racoon.log:

pfkey UPDATE succeeded: ESP/Tunnel 216.218.197.2->208.229.100.6
pk_recvupdate(): IPsec-SA established: ESP/Tunnel 216.218.197.2->208.229.100.6
get pfkey ADD message
IPsec-SA established: ESP/Tunnel 208.229.100.6->216.218.197.2

Once key exchange completes (which takes a few seconds), an SSH banner will appear. If all went well, two "Key Install" messages will be logged in the Firewall-1 Log Viewer.

Action      |  Source        |  Dest.  [snip]     | Info.
Key Install |  216.218.197.2 |  208.229.100.6     | IKE Log: Phase 1 (aggressive) completion.
Key Install |  216.218.197.2 |  208.229.100.6     | scheme: IKE methods

Under the information column, the full log detail will read:

IKE Log: Phase 1 (aggressive) completion. 3DES/MD5/Pre shared secrets Negotiation Id:

scheme: IKE methods: Combined ESP: 3DES + MD5 + PFS (phase 2 completion) for host:


Footnotes

1. Depending on configuration you may need to set the Firewall Object in Check Point as a Gateway in the properties tab. This will allow you to specify an internal network as an encryption domain behind the FreeBSD GW.



References

FreeBSD Handbook: IPSEC
http://www.freebsd.org/handbook/ipsec.html

FreeBSD IPSEC mini-HOWTO
http://www.x-itec.de/projects/tuts/ipsec-howto.txt

KAME Project
http://www.kame.net

Please support these people and projects.

 


About the Authors

Jon Orbeton is a Network Security Engineer in the Bay Area. He remembers a kinder, gentler Internet with quality newsgroups and Bulletin Board Systems (BBS's). Today, he provides professional security consulting for larger tier-2 ISP's and small, highly secure companies. With seven years network and security experience, Jon has plenty of hands on experience in the trenches.

Matt Hite is a Systems Administrator and Network Security Specialist based in San Francisco, CA. Eighteen years have passed since he first used a modem to call a bulletin board system (BBS) and he's been in love with computers, networks, and all things digital since.



About Security Reports

Matt Hite and Jon Orbeton are available for consulting engagements at reasonable rates.

For more information, send email to info@securityreports.com.


 
SecurityPortal.com
© Copyright 1999-2001 AtomicTangerine, Inc. All rights reserved.