FreeBSD vs WIN2K IPSEC road warrior HOWTO

Anton. R. Ivanov, IP Access LTD,
© 22.02.2002 ai1@ipaccess.com

$Id: FreeBSD-WIN2K-IPSEC-HOWTO.html,v 1.9 2002/02/25 10:08:06 ai1 Exp ai1 $

1. Introduction and Disclaimers

After some experimenting with cross-compatibility between OpenBSD, FreeBSD, NetBSD, Windows2000 and Linux FreeSwan I have found out Windows IPSEC+PPTP RAS to be most easily implemented on FreeBSD. NetBSD should be similar.

Despite the common hype about OpenBSDs IPSec stack I could not get the most recent RELEASE (3.0) to work correctly vs recent Cisco IOSes. Also, the machine performance on the same hardware was much lower than with FreeBSD. The configuration proved to be quite cumbersome as well.
Linux which I love and use for general purposes is just not there yet. FreeSWAN has numerous issues with routing, lack of support for some encryption algorithms, ad naseum.
So this leaves only FreeBSD, NetBSD, Windows RAS itself and specialized hardware vendors in the picture. Note that very few specialized hardware vendors support real Windows RAS. Many of them require specific client software which uses IPSEC tunnel mode.

Summary: I have found FreeBSD on a common desktop class machine to be sufficient for the needs of a small enterprise. It can support up to 256 clients, more than 4 MBit 3des and more than 10MB des throughput on a 700MHz PIII. If you need more than this you most likely will have to go for a specialized access point from Cisco, Nortel or other vendors and/or specialized client software that supports algorithms more efficient than 3des.

Please keep in mind that all usual disclaimers apply:

This worked for me, your mileage may vary.

My employer denies any responsibility for any damages or losses caused by the use or misuse of this information. I deny any reponsibility as well.

All trademarks are property of their respective owners.

This material is based on the excellent OpenSSL cookbook, OpenSSL documentation and various documents from Microsoft , Verisign, the KAME project and others. All information used in this HOWTO is either freely available on the Internet or can be derived from elementary interoperability testing.

I will be glad to accept any corrections and amendments to this document and maintain it.

You are allowed to redistribute this document free of charge, modify it as you see fit and include in other documents and products as long as the original copyright notice is retained and/or due credit is given.

2. Certificate Authority.

If you already have one - go to the next section. Otherwise you need to create a certificate root.

2.1. Create the necessary directory structure

Choose your own directory location. Depending on the number of certificates to deal with and local policy - either /usr/local/etc/openssl or /var/openssl. Create the necessary subdirectories and files:

 mkdir /var/openssl/certs

 mkdir /var/openssl/crl

 mkdir /var/openssl/newcerts

 mkdir /var/openssl/private

 echo "01" > /var/openssl/serial

 touch /var/openssl/index.txt

2.2. Prepare an openssl.conf file

The only reason for doing this is to avoid having to enter your company name, location, etc every time you run openssl. Here is a sample config based on the SSL Cookbook.

 RANDFILE                = /var/openssl/.rand

 

 ####################################################################

 [ ca ]

 default_ca      = CA_default            # The default ca section

 

 ####################################################################

 [ CA_default ]

 

 dir             = /var/openssl        # Where everything is kept

 certs           = $dir/certs            # Where the issued certs are kept

 crl_dir         = $dir/crl                      # Where the issued crl are
kept

 database        = $dir/index.txt                # database index file.

 new_certs_dir   = $dir/newcerts         # default place for new certs.

 

 certificate     = $dir/private/CAcert.pem       # The CA certificate

 serial          = $dir/serial           # The current serial number

 crl             = $dir/clr/crl.pem              # The current CRL

 private_key     = $dir/private/CAkey.pem        # The private key

 RANDFILE                = $dir/private/.rand    # private random number
file

 

 #x509_extensions                = x509v3_extensions     # The extentions
to add  to the cert

 default_days            = 365           # how long to certify for

 default_crl_days= 30                    # how long before next CRL

 default_md      = md5                   # which md to use.

 preserve        = no                    # keep passed DN ordering

 

 # A few difference way of specifying how similar the request should look

 # For type CA, the listed attributes must be the same, and the optional

 # and supplied fields are just that :-)

 policy          = policy_match

 

 # For the CA policy

 [ policy_match ]

 countryName             = match

 stateOrProvinceName     = optional

 localityName            = match

 organizationName        = match

 organizationalUnitName  = optional

 commonName              = supplied

 emailAddress            = optional

 

 [ req ] default_bits            = 1024

 default_keyfile         = privkey.pem

 distinguished_name      = req_distinguished_name

 attributes              = req_attributes

 

 [ req_distinguished_name ]

 countryName                     = Country Name (2 letter code)

 countryName_default             = UK

 countryName_min                 = 2

 countryName_max                 = 2

 

 stateOrProvinceName             = State or Province Name (full name)

 stateOrProvinceName_default     = 

 

 localityName                    = Locality Name (eg, city)

 localityName_default            = Cambridge

 

 organizationName                = Organization Name (eg, company)

 organizationName_default        = IP Access

 

 organizationalUnitName          = Organizational Unit Name (eg, section)

 organizationalUnitName_default  = 

 

 commonName                      = Common Name (eg, YOUR name)

 commonName_default              = ipaccess.com

 commonName_max                  = 64

 

 emailAddress                    = Email Address

 emailAddress_max                = 40

 emailAddress_default            = root-ca@ipaccess.com

 

 [ req_attributes ]

 challengePassword               = A challenge password

 challengePassword_min           = 4

 challengePassword_max           = 20

Note that the v3 x509 extensions have been commented out. I have had some trouble with them and they are not used by any of the parties concerned anyway.

2.3. Create the CA certificate and make a copy of it in PKCS#12 format so Windows can read it.

 openssl req -new -x509 -keyout /var/openssl/private/CAkey.pem  \

-out /var/openssl/private/CAcert.pem  -config openssl.conf

 openssl pkcs12 -export -in private/CAcert.pem \

-inkey private/CAcert.pem -nokeys -out CA.p12

As a result you will have two PEM format files for your Certificate Root and a PKCS#12 file which you can import into a windows system. Keep in mind that if you do not use the -nokeys switch, the resulting PKCS#12 file will contain your CA private key as well. At least with OpenSSL 0.9.6c under debian-woody this option does not work correctly and the keys are present in the PKCS#12 file (according to windows). If your private key has been kept for any reason it can be easily stripped by exporting it under windows and reimporting it back in.

2.4. Create a cert request for the server, sign it and make a non-encrypted copy of it.

 openssl req  -new -keyout server-key-encrypted.pem \

-out server.pem  -days 360 -config openssl.conf

 cat server.pem server-key.pem > server-req.pem

 openssl ca  -policy policy_match -out server-signed.pem \

-config openssl.conf -infiles server-req.pem

 openssl rsa -in server-key-encrypted.pem -out server-key.pem

Note that the openssl certificate request creates an encrypted private key. It has to be decrypted in order for racoon to be able to use it. That is the reason for the last openssl rsa line.

2.5. Create a cert request for each windows machine, sign it and make windows readable PKCS#12 copy of it.

Similar to the above:

 openssl req  -new -keyout user-key.pem -out user.pem  \

-days 360 -config openssl.conf

 cat user.pem user-key.pem > user-req.pem

 openssl ca  -policy policy_match -out user-signed.pem \

-config openssl.conf -infiles user-req.pem

 openssl pkcs12 -export -in user-signed.pem -inkey user-key.pem \

-name "User Name Goes Here" -certfile private/CA.pem -out user.p12

You need to repeat step 3.5 for every user and import the certificate into the windows system as described in 4.1.

You will also need to copy the certificates to the FreeBSD VPN system and symlink them to their checksums (see section 3.2).

3. Setting up a FreeBSD box.

3.1. Rebuild your kernel with IPSec.

You will need to enable the following in the config file:

 options         IPSEC                   #IP security

 options         IPSEC_ESP

Also enable the firewall of your choice IPFIREWALL or IPFILTER. Keep in mind that some options like NAT may not be compatible with using IPSEC.

3.2. Build and install KAME racoon from the ports collection.

It is under /usr/ports/security/racoon. In most cases a simple make install should be enough. Best of all put the config under its own directory like /usr/local/etc/racoon/. The config is quite simple:

 path pre_shared_key "/usr/local/etc/racoon/racoon.keys" ;

 path certificate "/usr/local/etc/racoon/cert" ;

 log debug;

 

 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 main, aggressive, base;

         my_identifier address 192.168.3.5;

         passive off;

         certificate_type x509 "server-signed.pem" "server-key.pem";

         my_identifier asn1dn;

         verify_cert off;

         proposal {

                 encryption_algorithm des;

                 hash_algorithm md5;

                 authentication_method rsasig ;

                 dh_group 1 ;

         }

 }

 

 sainfo anonymous

 {

         encryption_algorithm des, 3des ;

         authentication_algorithm non_auth, hmac_sha1;

         compression_algorithm deflate;

 }

Racoon searches for certificates based on their checksum. So, Client certificate under the cert directory will need to be symlinked to its magic hash name.

ln -s demon.pem `openssl x509 -noout -hash -in demon.pem`.0

3.3. Build and install the PoPToP PPTP server.

It is under /usr/ports/net/poptop. FreeBSD by default builds it with userland ppp which does not support RC4 encryption. Considering that encryption is delegated to IPSec this is not a problem. Alternatively there is another VPN daemon and kernel ppp both of which support RC4 but I have not tested them. At least the kernel ppp with the RC4 patches is reported to be unstable. It may also be illegal to use it in some countties.

After building it you need to add the following section to the bsd ppp options file.

 loop:

  set timeout 0

  set log phase chat connect lcp ipcp command

  set device localhost:pptp

  set dial

  set login

  # Server (local) IP address, Range for Clients, and Netmask

  set ifaddr 192.168.20.1 192.168.20.130-192.168.20.254 255.255.255.255

  set server /tmp/loop "" 0177

 

 loop-in:

  set timeout 0

  set log phase lcp ipcp command

  allow mode direct

 

 pptp:

  load loop

  enable chap

  disable pap

  # Authenticate against /etc/passwd

  #enable passwdauth

  # The next depends on your routing. Proxy arp is an easy way out 

  # enable proxy

  accept dns

  # DNS Servers to assign client

  # set dns 192.168.0.1 192.168.0.2

  # NetBIOS/WINS Servers to assign client

  # set nbns 192.168.0.15 192.168.0.16

  set device !/etc/ppp/secure

Update the IPs in the pptpd.conf file as well. I have not had the time to try what happens if they differ. If they are the same it works.

3.4. Create a traffic policy

Traffic policy on the BSD side is fairly simple. All GRE packets and PPTP control channel traffic is set to require IPSEC.


 setkey -c

 spdadd 172.28.1.2 0.0.0.0/0 gre -P  out ipsec

         esp/transport//require;

 spdadd 0.0.0.0/0 172.28.1.2 gre -P in ipsec

         esp/transport//require;

 spdadd 172.28.1.2[1723] 0.0.0.0/0 tcp -P  out ipsec

         esp/transport//require;

 spdadd 0.0.0.0/0 172.28.1.2[1723] tcp -P in ipsec

         esp/transport//require;

4. Windows 2000 Setup

You will need admin privileges for every client. There are also some prerequisites. Windows must be patched to SP2 and have the high encryption pack installed. The high encryption pack is available from

http://www.microsoft.com/windows2000/downloads/recommended/encryption/default.asp

. You will also need working network browsing. The easiest way to achieve this is to enable WINS on the PDC (or its samba equivalent) and ask PPP to supply the clients with the WINS server address.

4.1. Certificate Setup

Note, that this is the part where it is easiest of all to make a mistake. From the start menu run "mmc". From the console menu chose add-remove snap-in. Add the certificate and the IPSEC snap-ins. When asked which certificates do you want to manage chose local computer. Note that windows has per-user certificates as well as per-computer ones, but the per-user ones are not useable for IPSEC.

Under the Certificates, right button click on Trusted Root Certification authorities. From all actions choose import . Import your certificate authority PKCS#12 certificate here. Check if it is displayed.

Under the Certificates, right button click on Personal. From all actions choose import. Import the user PKCS#12 certificate here. Check if it is correctly displayed and the root authority is known.

Under IP Security policies choose a policy which you are not using. Modify it as follows:

One access list for all traffic going to the IP address of the BSD VPN Gateway.
All traffic requires IPSec and is authenticated using a certificate.
From the list of authorities choose yours. Disable or remove all other rules and enable the policy.

If your personal certificate is correctly signed it will than be used for isakmp key negotiation. If you are having trouble, run racoon in debug mode on the BSD box. It will display the whole certificate in the debug output.

4.2. PPTP setup.

Create a new VPN connection. Make sure that under properties, in the security section the require data encryption field is left blank. You do not need it. This is the RC4 encryption for the PPTP which will be unnecessary overhead if IPSEC is protecting the connection.

DEBUGGING and CAVEATS

If you run into trouble your best chance is to use racoon in non-daemon mode with debugging enabled. I found most errors to be self-explanatory except one:

Racoon fails when trying to read its own private key with no additional error message. This happens when the certificate used for the BSD server has an encrypted private key. You will need to run openssl rsa in order to decrypt it.