Setting up a Linux FreeS/WAN VPN (Virtual Private Network) for Remote Users

Note: This page is superceded by linuxsetup71.html.

1. What is a VPN

Although there are many software options for establishing secure connections between computers, such as SSH or various forms of encryption, most of them suffer from the disadvantage of needing special software: only traffic that can be sent through the tunnel is secure. In order to encrypt every packet between two points, something like IPSec that works at the level of the network protocol is needed. With an IPSec tunnel, remote users can access and browse your network as if they were directly connected to it.

IPSec is not a regular user-mode program, but installs itself as part of the kernel. If your kernel doesn't support IPSec, you have to recompile the kernel. In Windows, special client software that interacts with the Registry is needed.

Getting IPSec to work with Windows clients is complex. In our tests, we had to reinstall Windows twice because the software trashed the Registry when it was removed. Before starting, ask yourself whether it might be easier to purchase a preconfigured hardware device instead.

On the FreeS/WAN side, the documentation is quite obscure, and the error messages produced by the server often have little to do with the actual problem. Configuring it can be a nightmare.

Even so, after a fair amount of work we were able to set up a functioning VPN on a local network between a Windows computer with a static IP number running SSH Sentinel and a Linux machine running FreeS/WAN. With somewhat more work, we were able to set up an encrypted VPN over a commercial 56k dialup line between a Windows client ("Road Warrior") and the Linux server. Eventually, after discovering a number of apparently undocumented facts about this software, we finally got the client to connect using a virtual IP. The Windows computer had no problem browsing the network and accessing the network's private resources. However, when we switched to DHCP, we encountered strange problems.

2. Authentication

Users can be authenticated either by giving them a pre-shared key, or by using X.509 certificates. Some types of pre-shared keys, including password authentication, Radius, or SecureID can not work with Freeswan, because of a fundamental flaw in the design of the IPSec protocol: IPSec has no concept of user IDs. Thus, it has no way of verifying a password for any particular user. With pre-shared keys, every remote user would have to use the same password -- an obviously insecure solution. To get around this limitation, it's necessary to generate and distribute a Diffie-Hellman style public key known as an X.509 certificate for each remote computer. This can usually be automated so that creating a certificate is not too much harder than setting a user's password. (Oh, who am I kidding?)

3. Linux Kernel Configuration and Installation of FreeS/WAN

Before trying to connect Windows clients, get it working on a Linux box first.

1. Before starting, get Samba working first and make sure Windows computers can browse the server over the local network.
2. Find out if ipsec is compiled into your kernel

   ls /proc/net/ipsec*

   If it doesn't print anything, it is necessary to build and install a new kernel.

3. Download FreeS/WAN and X.509 patches from
                   http://www.strongsec.com/freeswan
                   http://www.freeswan.org/download.html
                   http://www.freeswan.ca/patches
   If www.strongsec.com is not available, try www.strongsec.net.

   The following files are needed to work with SSH Sentinel

   freeswan-1.99.tar.gz x509patch-0.9.15-freeswan-1.99.tar.gz freeswan-alg-0.8.0-BASE-common.diff freeswan-alg-0.8.0-BASE-klips.diff freeswan-alg-0.8.0-BASE-pluto_with_x509.diff freeswan-alg-0.8.0-enc-aes.diff notify_delete-freeswan-1.98b-020724.diff

4. Remove all the unterminated <NOBR>s from the HTML files in the freeswan documentation so they are readable.
5. Extract freeswan and the patches:

   tar -xzvf freeswan-1.99.tar.gz tar -xzvf x509patch-0.9.15-freeswan-1.99.tar.gz

6. Patch freeswan to handle X.509, AES (Rijndael encryption), and SA notification:

   cd freeswan-1.99 patch -p1 < ../x509patch-0.9.15-freeswan-1.99/freeswan.diff patch -p1 < ../freeswan-alg-0.8.0-BASE-common.diff patch -p1 < ../freeswan-alg-0.8.0-BASE-klips.diff patch -p1 < ../freeswan-alg-0.8.0-BASE-pluto_with_x509.diff patch -p1 < ../freeswan-alg-0.8.0-enc-aes.diff

7. Build a 2.4 kernel (2.5 kernels do not work). Freeswan cannot be installed unless you have previously compiled a kernel, so you may have to do this step twice.

   su cd /usr/src ln -s linux-2.4.18 linux cd linux make xconfig make dep make make modules (if using modules) make bzImage make modules_install (if using modules)

   Return to freeswan directory and recompile kernel with ipsec

   exit xhost +localhost su make xgo

   Be sure not to put a '&' after the 'make xgo' command.
   Use "make ogo" instead if you don't want to use the X11 menu configuration tool.
   Check under "Networking options" to make sure the correct options for ipsec are set (i.e., all of them).
   Make sure "advanced router" and "WAN router" are off.
   Make sure "IP forwarding" is on.
   Save the new configuration.
   The script will start building your kernel automatically.
   Install the new kernel:

   ls -l ./arch/i386/boot/bzImage cp /boot/bzImage /boot/bzImage.old cd /usr/src/linux/arch/i386/boot cp bzImage /boot/ vi /etc/lilo.conf /sbin/lilo

   If you made ipsec as modules, add the following to rc.local:

   echo "modprobe ipsec_aes" >> /etc/rc.d/rc.local

   If a booting problem occurs, disable freeswan in /etc/rc.d.

   WARNING: If you delete or move the freeswan directory, you will be unable to recompile the kernel because FreeS/WAN creates links out of /usr/src/linux pointing to files in the freeswan directory.

8. The installation should copy a binary called 'ipsec' in /usr/local/sbin and should place a number of new files in /usr/local/lib/ipsec. If not, add the following line to /etc/init.d/ipsec before the line that starts "# Pick up ipsec"

   echo ipsec is at $dir

   and run /etc/init.d/ipsec to find it.

   If an old version of ipsec is present (e.g., in /usr/sbin), remove it and remove the directory /usr/lib/ipsec to prevent the old, unpatched version from being run by mistake.

9. Install OpenSSL. OpenSSL is available from www.openssl.org. Do not use any version earlier than 0.9.6g because these early versions had serious security problems.

   OpenSSL may install itself in /usr/local/ssl or in /usr/share/ssl. Make sure only a single version is present. A complete Perl installation is necessary to install OpenSSL.
   

10. Check /usr/local/ssl/openssl.cnf for any site-specific changes. In particular, increase the expiration times so you don't have to go back and reissue new certificates all the time. (Setting them to expire exactly one week after your employment contract expires may not be a great idea, though). Make sure the expiration date is earlier than year 2038.
    

4. Set up an OpenSSL-based certificate authority (CA) on the Linux server running FreeS/WAN.

1. Add openssl to root's path

   export PATH=$PATH:/usr/local/ssl/bin/:/usr/local/sbin/

2. As root, create a new root CA certificate:

   cd /usr/local/ssl/misc rm -rf demoCA ./CA.pl -newca

   This should ask a bunch of questions.

   ./CA.pl -newca CA certificate filename (or enter to create) Making CA certificate ... Using configuration from /usr/local/ssl/openssl.cnf Generating a 1024 bit RSA private key ...++++++ ..................................++++++ writing new private key to './demoCA/private/cakey.pem' Enter PEM pass phrase: Verifying password - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:Disrepair Locality Name (eg, city) []:Crapville Organization Name (eg, company) [Internet Widgits Pty Ltd]: Crapco Institute of Verminology Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []:Napoleon Bonaparte Email Address []:

   Note that if this command is run a second time, it does nothing.
   To wipe out the old CA and create a new one, delete the directory demoCA.
   It can be a major ordeal to repeat this process if your CRL expires.
   If you want to change the duration of the root certificate to 10 years instead of 3650 days (recommended), type the following.

   cd demoCA /usr/local/ssl/bin/openssl req -new -x509 -keyout private/cakey.pem \ -out cacert.pem -days 3650

   Check the certificate to make sure the software used reasonable starting and ending dates. If you make the expiration too long, the software will "wrap around" the value, and silently create an invalid certificate. The only clue is a cryptic message later on, when ipsec starts up:

   carbon pluto[13966]: loaded host cert file '/etc/ipsec.d/certs/myCert.pem' (3282 bytes) carbon pluto[13966]: host certificate is invalid

   Unfortunately, you can't just edit the expiration date. It's necessary to create an entire new set of certificates. Certificates apparently cannot be set to expire beyond the year 2038.

   The software sets the starting and expiration dates in GMT.

   Copy the new CA certificate to the /etc/ipsec.d/cacerts/ directory.

   cp -p cacert.pem /etc/ipsec.d/cacerts/myCAcert.pem

3. Create a Certificate Revocation List (CRL) valid for 3650 days, using the same password as used in creating the CA.

   cd /usr/local/ssl/misc /usr/local/ssl/bin/openssl ca -gencrl -crldays 3650 -out crl.pem

   It gives a terse message, without confirming whether it did anything:

   Using configuration from /usr/local/ssl/openssl.cnf Enter PEM pass phrase:

   Copy it to its correct location

   cp -p crl.pem /etc/ipsec.d/crls/myCrl.pem

4. Create a FresS/Wan Host Certificate Request for the FreeS/Wan gateway.
   

   cd /usr/local/ssl/misc ./CA.pl -newcert

   It should ask a series of questions as before:

   Using configuration from /usr/local/ssl/openssl.cnf Generating a 1024 bit RSA private key .................................................................++++++ ..........++++++ writing new private key to 'newreq.pem' Enter PEM pass phrase: Verifying password - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:Disrepair Locality Name (eg, city) []:Crapville Organization Name (eg, company) [Internet Widgits Pty Ltd]: Crapco Institute of Verminology Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []:Napoleon Bonaparte Email Address []:nb@sh-hole.org Certificate (and private key) is in newreq.pem

   Make sure it actually created a Host Certificate

   /usr/local/ssl/misc > ls -lrt n* -rw-r--r-- 1 root root 2187 Dec 15 09:44 newreq.pem

   If it only says

   Certificate (and private key) is in newreq.pem

   this means the script did not find the openssl binary, did not create anything, and the certificate and private key are NOT in newreq.pem.

5. Sign the certificate request with the OpenSSL root CA certificate.

   ./CA.pl -signcert Getting request Private Key Enter PEM pass phrase: Generating certificate request Using configuration from /usr/local/ssl/openssl.cnf Enter PEM pass phrase: Check that the request matches the signature Signature ok The Subjects Distinguished Name is as follows countryName :PRINTABLE:'US' stateOrProvinceName :PRINTABLE:'Disrepair' localityName :PRINTABLE:'Crapville' organizationName :PRINTABLE:'Crapco Inst. of Verminology' commonName :PRINTABLE:'Napoleon Bonaparte' emailAddress :IA5STRING:'nb@sh-hole.org' Certificate is to be certified until Dec 15 14:50:59 2012 GMT (3650 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated Signed certificate is in newcert.pem

   As before, when you sign the certificate it should print a bunch of information. If all it does is ask for the password and print

   Signed certificate is in newcert.pem

   this means the certificate was NOT signed, and there is NO new signed certificate in newcert.pem.
   Put the signed certificates in the correct location:

   cp -p newcert.pem /etc/ipsec.d/certs/myCert.pem cp -p newreq.pem /etc/ipsec.d/private/myKey.pem

   Note that some versions require the certificates to be in the /etc/ipsec.d/ instead of the /etc/ipsec.d/certs/ directory.
6. (Optional) generate RSA keys and put them in /etc/ipsec.secrets if this is not done automatically. Make sure it contains a line starting with ": RSA { "

   /usr/local/sbin/ipsec --help cp /etc/ipsec.secrets /etc/ipsec.secrets.bak /usr/local/sbin/ipsec rsasigkey 1024

   Edit /etc/ipsec.secrets, and insert the new RSA key manually.
   Add a line pointing to your X.509 RSA certificate, containing the password you used in creating it, in plaintext form:

   : RSA /etc/ipsec.d/private/myKey.pem "CleartextPassword"

   At this point, the ipsec.secrets file should look like this:

   # This file holds shared secrets or RSA private keys for inter-Pluto # authentication. See ipsec_pluto(8) manpage, and HTML documentation. # RSA private key for this host, authenticating it to any other host # which knows the public part. Suitable public keys, for ipsec.conf, DNS, # or configuration of other implementations, can be extracted conveniently # with "ipsec showhostkey". : RSA /etc/ipsec.d/private/myKey.pem "MyClearTextPassword" : RSA /etc/ipsec.d/private/joeKey.pem "MyClearTextPassword" : RSA { # RSA 1024 bits malaria Sun Dec 15 10:00:15 2002 # for signatures only, UNSAFE FOR ENCRYPTION #pubkey=0sAQN7f4nLYZNh59942EA46r ... etc... #IN KEY 0x4200 4 1 AQN7f4nLYZN ... etc... # (0x4200 = auth-only host-level, 4 = ipsec, 1 = RSA) Modulus: 0x7b7f89cb619361e7df4 ... etc... PublicExponent: 0x03 # everything after this point is secret PrivateExponent: 0x149541a2a1e59 ... etc... Prime1: 0xd57d8b7fa43e5e0624f97c ... etc... Prime2: 0x9416bb7dc7989e7bc5c92a ... etc... Exponent1: 0x8e53b2551823d99404a ... etc... Exponent2: 0x62b9d253da265bd42e8 ... etc... Coefficient: 0x4dd87794b5cd1e86a ... etc... } # do not change the indenting of that "}"

   Note that if you have two different keys for the same client, Freeswan will only use the first one.
   Note that you use the host's password, not the remote user's password, for each PEM file.

   Make sure each of those hexadecimal numbers is on a single long line and that each line starts with a tab character, except for the first line of each entry.
   Of course, this file needs to be protected:

   ls -l /etc/ipsec.secrets -rw------- 1 root root 3933 Dec 10 00:31 /etc/ipsec.secrets

7. Make sure it can find the key

   ipsec showhostkey ; RSA 2048 bits carbon Sat Dec 7 12:50:09 2002 carbon. IN KEY 0x4200 4 1 AQOE8...[long string of numbers]...mOU9whJ

5. Create User Authentication Certificates

1. Create a different Certificate for each SSH Sentinel Client, using the remote user's name, email address, and assigned password (the information you type will be visible to the user, so don't type stuff like "joe luser phb futthead"). The software will create a signed CA in the file newreq.pem.

   cd /usr/local/ssl/misc ./CA.pl -newcert

   When it says:

   Enter PEM pass phrase: Verifying password - Enter PEM pass phrase:

   Use the password that you used earlier in creating the host CA certificate.
   When it says:

   Common Name (eg, YOUR name) []:Bucky W. Bartmeister / Remote

   enter the remote user's name and email address. This must be different from the name used when creating every other CA, otherwise you will get the error:

   ERROR:There is already a certificate for /C=US/ST=Disrepair/L=Crapville/O=Crapco/CN=Napoleon

   It's also good idea to add the organization as well as the user's name, in case the user somehow gets two or more certificates. This will help prevent the user from trying to connect with the wrong certificate.

   Sign the certificate request with your OpenSSL root CA certificate. When it asks for PEM pass phrase, use the password you used when creating the CA certificate, not the remote user's password.

   ./CA.pl -signcert Getting request Private Key Enter PEM pass phrase: Generating certificate request Using configuration from /usr/local/ssl/openssl.cnf Enter PEM pass phrase: Check that the request matches the signature Signature ok The Subjects Distinguished Name is as follows countryName :PRINTABLE:'US' stateOrProvinceName :PRINTABLE:'Disrepair' localityName :PRINTABLE:'Crapville' organizationName :PRINTABLE:'Crapco Inst of Verminology' commonName :PRINTABLE:'Remote Malaria' emailAddress :IA5STRING:'nb@sh-hole.org' Certificate is to be certified until Dec 15 15:25:17 2012 GMT (3650 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated Signed certificate is in newcert.pem

2. Create a PKCS#12 formatted certificate package for each remote user. This allows the remote users to import their certificates.

   cd /usr/local/ssl/misc /usr/local/ssl/bin/openssl pkcs12 -export \ -inkey newreq.pem \ -in newcert.pem \ -name "OpenSSL client certificate" \ -certfile demoCA/cacert.pem \ -caname "OpenSSL Root CA certificate" \ -out lkcs12_certpack_for_user.p12

   It will ask for the following:

   Enter PEM pass phrase: Enter Export Password: Verifying password - Enter Export Password:

   The PEM pass phrase is the password you used in creating the CA. The Export Password will be the user's password. The software will convert the certificate into a password-protected binary file called

   lkcs12_certpack_for_user.p12

   Rename the p12 file and store it in a safe location in case the user loses it

   cp lkcs12_certpack_for_user.p12 lkcs12_certpack_for_joe.p12

   Give this file, along with the Export Password, to the remote user.
3. Copy the user's CA and key to the standard locations:

   cd /usr/local/ssl/misc cp newcert.pem /etc/ipsec.d/certs/joeCert.pem cp newreq.pem /etc/ipsec.d/private/joeKey.pem

4. Add the new path to /etc/ipsec.secrets

   : RSA /etc/ipsec.d/private/myKey.pem "my cleartext password" : RSA /etc/ipsec.d/private/joeKey.pem "my cleartext password"

5. Restart FreeS/WAN if it's running, so it reads the new information.
6. Run this command and make note of the "issuer" and "subject" lines. These will be needed later in 'leftid' and 'rightid' lines in ipsec.conf.

   /usr/local/sbin/ipsec auto --listall

6. Configure FreeS/WAN

Next, edit /etc/ipsec.conf to configure FreeS/WAN.

1. Start with a sample ipsec.conf file and edit it

   # /etc/ipsec.conf - FreeS/WAN ipsec configuration file # basic configuration config setup # THIS SETTING MUST BE CORRECT or almost # nothing will work; interfaces="ipsec0=eth0" klipsdebug=none plutodebug=none plutoload=%search plutostart=%search uniqueids=yes strictcrlpolicy=yes # defaults for subsequent connection descriptions # (mostly to fix internal defaults which, in # retrospect, were badly chosen) conn %default keyingtries=1 disablearrivalcheck=no authby=rsasig keyexchange=ike # max is 28800s ikelifetime=28800s # max is 86400s keylife=86400s pfs=yes compress=no right=%any rightrsasigkey=%cert #left=%defaultroute left=192.168.100.1 leftcert=certs/myCert.pem auto=add leftsubnet=0.0.0.0/0 #leftsubnet=192.168.100.0/24 conn dhcp type=tunnel rekey=no ikelifetime=60s keylife=90s rekeymargin=10s right=%any leftprotoport=udp/bootps rightprotoport=udp/bootpc auth=esp esp=aes128-md5 ike=aes128-md5 auto=add conn network # Left security gateway, subnet # behind it, next hop toward right. leftnexthop=192.168.100.4 type=tunnel auth=esp esp=aes128-md5 ike=aes128-md5 rightsubnetwithin=192.168.100.0/24

   This assumes the following:
   • The network is 192.168.100.0/24
   • The Linux server running FreeS/WAN is 192.168.100.1
   • The client has a static address of 192.168.100.4.
   • The client is not trying to send DHCP over IPSec. Note that if DHCP is activated in the client, it will grab an IP from DHCP regardless of the setting in SSH Sentinel.
2. Configure Freeswan for strict Certificate Revocation List (CRL) policy. This allows you to revoke the CA client certificates on a per-user basis.
   To do this, add the following line in /etc/ipsec.conf under "config setup":

   strictcrlpolicy=yes

7. Start the Server.

1. Enable proxy ARP and IP forwarding, and disable rp_filter

   cat /proc/sys/net/ipv4/conf/eth0/proxy_arp cat /proc/sys/net/ipv4/conf/eth0/rp_filter cat /proc/sys/net/ipv4/ip_forward echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter echo 1 > /proc/sys/net/ipv4/ip_forward

   These commands must be executed each time the server boots up. It is not necessary to compile a new kernel.
2. Restart ipsec to make it re-read the secrets files. If the AES support was compiled as a module, the module must be removed first:

   cd /etc/rc.d rmmod ipsec_aes service ipsec restart insmod ipsec_aes

   Otherwise just restart the service.

   ./ipsec restart

   Make sure it says something like:

   ipsec_setup: Starting FreeS/WAN IPSec 1.99... ipsec_setup: KLIPS debug `none' ipsec_setup: KLIPS ipsec0 on eth0 192.168.100.1/255.25 5.255.0 broadcast 192.168.100.255 ipsec__plutorun: Starting Pluto subsystem... ipsec_setup: ...FreeS/WAN IPSec started pluto: Starting Pluto (FreeS/WAN Version 1.99) pluto: including X.509 patch (Version 0.9.15) pluto: ike_alg_register_enc: Activating OAKLEY_AES_CBC: Ok (ret=0) pluto: Changing to directory '/etc/ipsec.d/cacerts' pluto: loaded cacert file 'myCAcert.pem' (1224 bytes) pluto: Changing to directory '/etc/ipsec.d/crls' pluto: loaded crl file 'myCrl.pem' (499 bytes) pluto: could not open my default X.509 cert file '/etc/x509cert.der' pluto: OpenPGP certificate file '/etc/pgpcert.pgp' not found pluto: listening for IKE messages pluto: adding interface ipsec0/eth0 192.168.100.1 pluto: loading secrets from "/etc/ipsec.secrets" pluto: loaded private key file '/etc/ipsec.d/ private/myKey.pem' (2180 bytes) pluto: loaded private key file '/etc/ipsec.d/ private/joeKey.pem' (2139 bytes)

3. Verify all the installed and valid certificates:

   /usr/local/sbin/ipsec auto --listall

   It should say something like:

   # /usr/local/sbin/ipsec auto --listall 000 List of Public Keys: 000 000 Dec 12 21:17:29 2002, 1024 RSA Key AwEAAcs6 z, until Dec 24 23:27:14 2002 ok 000 ID_DER_ASN1_DN 'C=US, ST=Disrepair, L=Crapville, O=Crapco, CN=remote, E=remoteuser@ sh-hole.org' 000 Dec 11 22:40:45 2002, 1024 RSA Key AwEAAbIc P, until Dec 09 23:34:00 2003 ok 000 ID_DER_ASN1_DN 'C=US, ST=Disrepair, L=Crapville, O=Crapco, CN=carbon, E=nb@sh-hole. org' 000 000 List of User/Host Certificates: 000 000 Dec 11 22:40:45 2002, count: 2 000 subject: 'C=US, ST=Disrepair, L=Cra ville, O=Crapco, CN=carbon, E=nb@sh-hole.org' 000 issuer: 'C=US, ST=Disrepair, L=Cra ville, O=Crapco, CN=Napoleon, E=nb@sh-hole.org' 000 pubkey: 1024 RSA Key AwEAAbIcP, h as private key 000 validity: not before Dec 09 23:34:0 0 2002 ok 000 not after Dec 09 23:34:0 0 2003 ok 000 000 List of CA Certificates: 000 000 Dec 11 22:40:45 2002, count: 1 000 subject: 'C=US, ST=Disrepair, L=Cra ville, O=Crapco, CN=Napoleon Bonaparte, E=nb@s h-hole.org' 000 issuer: 'C=US, ST=Disrepair, L=Cra ville, O=Crapco, CN=Napoleon Bonaparte, E=nb@s h-hole.org' 000 pubkey: 1024 RSA Key AwEAAbt0A 000 validity: not before Dec 09 23:24:56 2002 ok 000 not after Dec 06 23:24:56 2012 ok 000 000 List of CRLs: 000 000 Dec 11 22:40:45 2002, revoked certs: 0 000 issuer: 'C=US, ST=Disrepair, L=Cra ville, O=Crapco, CN=Napoleon Bonaparte, E=nb@s h-hole.org' 000 updates: this Dec 09 23:27:14 2002 000 next Dec 24 23:27:14 2002 ok

   /sbin/ifconfig should show a new entry for ipsec:

   ipsec0 Link encap:Ethernet HWaddr 00:E0:18:55:D4:31 inet addr:192.168.100.1 Mask:255.255.255.0 UP RUNNING NOARP MTU:16260 Metric:1 RX packets:2086 errors:0 dropped:75 overruns:0 frame:0 TX packets:2644 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 RX bytes:181893 (177.6 Kb) TX bytes:1615904 (1.5 Mb)

   ps -aux | grep ipsec should say:

   root /bin/sh /usr/local/lib/ipsec/_plutorun --debug none --uniqueids yes --nocrsend --strictcrlpolicy yes --dump --load %search --start %search --wait --pre --post --log daemon.error --pid /var/run/pluto.pid root /bin/sh /usr/local/lib/ipsec/_plutorun --debug none --uniqueids yes --nocrsend --strictcrlpolicy yes --dump --load %search --start %search --wait --pre --post --log daemon.error --pid /var/run/pluto.pid root /bin/sh /usr/local/lib/ipsec/_plutoload --load %search --start %search --wait --post root logger -p daemon.error -t ipsec__plutorun root /usr/local/lib/ipsec/pluto --nofork --debug-none --uniqueids --strictcrlpolicy root grep ipsec

   route -n should show new routes for ipsec:

   Before a client connects:

   Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0

   After a client connects:

   Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.100.20 192.168.100.20 255.255.255.255 UGH 0 0 0 ipsec0 192.168.100.10 192.168.100.20 255.255.255.255 UGH 0 0 0 ipsec0 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0

The server is now fully configured. The next step is configuring the Windows client.

8. Set up SSH Sentinel on the client.

Getting any Windows VPN client software to work properly with IPSec can be difficult. The software manipulates the Windows registry and installs DLLs and low-level drivers that are not completely removed by the Windows uninstall utility. This causes cruft to rapidly accumulate in your computer. Be sure to back up your computer before starting. Moreover, VPN clients are not all created equal. I tested the following Windows clients:

1. PGPvpn 7.1.1: PGPnet 7.1.1 was easy to install, but difficult to get rid of. Once installed, bits and pieces of PGPnet will always remain on your computer. It was possible to import signed p12 keys into PGPnet, but we ran into the message

   Informational Exchange message for an established ISAKMP SA must be encrypted

   There was no clue about what if anything this message might mean, or what could be done about it. No success connecting to FreeS/WAN.
2. Cisco VPN client also installed easily, and was able to import the user's P12 certificate with no problem. However, there was no way to specify the encryption protocol, and I could find no documentation nor any evidence on the Internet that anyone had ever gotten it to work with anything other than Cisco's dedicated hardware. No success connecting to FreeS/WAN.
3. PGP-FW 6.58 is a freeware version of PGPnet available from MIT's Web server and other sites. It installed rapidly and easily. I have no idea what its user interface looks like, because during the installation it trashed the Windows registry and system directory, forcing a reinstallation of the operating system.
4. Windows 2000 and XP supposedly have VPN software built in. From what I've heard, it is difficult to make it work. Undoubtedly, some of your users will be running older versions of Windows such as ME or 98, which makes this option undesirable. It is also worth considering that Microsoft could well change its implementation of the protocol in the future to lock users into a Windows-only solution. I did not test either the W2K or XP software.
5. PPTP Microsoft also has something called PPTP (point-to-point tunneling protocol) which is not regarded as secure. I did not test this.
6. SSH Sentinel is a much more sophisticated program and is highly configurable. With the documentation on their Website, and some wild guesses to fill in several steps that were omitted from their instructions, I had little difficulty connecting to the Linux FreeS/WAN server. Despite the fact that the licensing fee is $65.00 per user, SSH Sentinel looked pretty good in comparison to the other options. Of course, after testing the other ones, my level of expectation was markedly reduced.

   When SSH Sentinel was installed, the Windows computer was no longer able to browse the local network. According to the FAQ at the vendor's Website, to regain the LAN functionality that you had before you installed this software, it is not only necessary to uninstall it, but also to manually remove the SSH Virtual Adapter, which is a hidden device, using the Windows Device Manager (Control Panel->Administrative tools-> Computer Management -> Device Manager ->View -> Show Hidden Devices -> Network Adapters -> SSH Virtual Adapter (sshvnic) -> click right mouse button -> Uninstall -> OK).

   However, this did not cure the problem and reinstallation of the operating system was necessary to re-enable browsing. A simple reinstallation of W2K over the old version was insufficient; a disk format was required.

   As a workaround, it was found that typing the command

   windump -i 2

   or

   windump -i 3

   in a DOS window sometimes re-enables browsing. The effect only lasts until the next reboot. However, after this command is issued, SSH Sentinel no longer works at all. To test whether there could be some incompatibility with the NDIS drivers installed by SSH Sentinel and the Realtek 8139 network card, we installed a different network card (Netgear FA-311) on the Windows machine. With this card, SSH Sentinel became flaky, often requiring one or two attempts (which required a reboot) before it would establish a VPN connection. However, as with the Realtek card, no pings were ever returned with the Netgear card over the VPN connection. Also, with the Netgear card, running WinDump and SSH Sentinel simultaneously caused spontaneous reboots of the Windows machine.

9. Installing SSH Sentinel - Instructions for Windows Users

Before starting, make sure you have the following:

1. A copy of SSH Sentinel.
2. Your X.509 certificate created by the Network Administrator. This certificate contains an RSA key that will identify your computer. Do not share your key with anyone. This would allow them to have complete access to your computer.
3. The special assigned password needed to open your X.509 certificate.
4. The IP address of the Institute's VPN gateway (hint: 65.198.102.xx).

1. Back up everything on your hard disk. If you decide to uninstall SSH Sentinel at a later date, you may encounter problems with networking.
2. If you have previously installed any other VPN software, remove it by clicking on "Add/Remove Software" in the Control Panel. Also, if you're using Windows 2000 or XP, turn off ipsec in the control panel. This is very important.
3. Click on the light blue and gray SSH Sentinel Icon.
4. Follow the instructions when it says to move mouse randomly.
5. Select "Host domain name" as the primary identifier. Enter the host name e.g., SEPTICEMIA, SYPHILIS, or whatever you call your computer.
6. Create a Self-signed certificate.
7. It will then run diagnostics. Wait until it picks a cipher to use before clicking next. It should pick Rijndael. Click next.
8. It will then install SSH Accession and reboot your computer.

1. If your computer reboots correctly, click Start->Programs->SSH Sentinel->SSH Sentinel Policy Editor.
2. Click Key Management Tab.
3. Highlight the "My Keys" so it turns Blue.
4. Right-click on "My Keys" (Click the RIGHT mouse button) and select "Import".
5. When the "Open" Dialog box comes up, click on "Files of type" and select "PKCS #12 certificate files (*.pfx, *.p12)".
6. Scrape any crumbs off the floppy disk containing the X.509 Certificate that was given to you by Tom and put the disk into your computer.
7. Type the password given to you by Tom that allows you to open the X.509 Certificate.
8. It will ask, Are you sure you want to add this certificate? Answer Yes. Are you sure you want to add this certificate in the trusted certification authorities? Answer Yes.
9. Click on Apply. Whenever you make a change, it is necessary to click on Apply.

Note: The VPN is only active for traffic between your home computer and the Institute's network. Connections to the Internet are not affected. Also, if you close the VPN tunnel, your connection will return to normal and will no longer be encrypted. If you want, you can change the settings in SSH Sentinel so all traffic from your computer goes through the VPN.

SETTING UP THE VPN FOR THE FIRST TIME:

1. Click on the Security Policy tab of the SSH Policy Editor.
2. Highlight "VPN Connections" so it turns blue.
3. Click Add
4. Gateway: Click the small IP box at right, and type the IP address of the Institute's VPN Gateway (65.198.102.xx)
   Remote network: Click the small IP box at right, and type 0.0.0.0 and 0.0.0.0.
   Click OK.
   Authentication key: select the certificate that has your name on it.
   Do not click "Use Legacy Proposal".
   Click "Properties...".
   Do not check "Acquire virtual IP address".
   Do not click "Extended authentication".
   Keep ipsec/IKE proposal set to "normal".
   Under ipsec/IKE proposal, click "Settings..."
   Make sure the settings are:

   IKE proposal Encryption algorithm: AES(Rijndael) Integrity function: MD5 IKE mode: main mode IKE group: MODP 1024 (group 2) IPSec proposal: Encryption algorithm: AES(Rijndael) Integrity function: HMAC-MD5 IPSec mode: tunnel PFS group: MODP 1024 (group 2) Attach only the selected values to the proposal: leave unchecked

   Click the Advanced tab and make sure the settings are:

   Security association lifetimes: leave as default Audit options: Audit this rule Advanced options Apply IP compression Off Discover PMTU On Pass NAT devices Off Open on start-up Off Deny split tunneling On

   Click OK
   Click Apply
   It might say "This IP address may be invalid. The reverse mapping failed." This is okay.
   Click OK again until the window disappears..
   
5. If you want the VPN tunnel to be activated automatically when you reboot, click the Advanced tab and click "Open on start-up". Don't change the other settings.
6. Click Apply.
7. If you are using a modem, connect to your ISP in your usual manner.
8. Test the connection by clicking "Diagnostics" on the SSH Sentinel Policy Editor main window. It should say: "Diagnostics Complete." This means the VPN is configured properly.

CONNECTING TO THE VPN

1. If you are using a modem, connect to your ISP in your usual manner. If you have a permanent connection, you can leave the VPN running continuously.
2. Open the VPN connection by right-clicking on the blue+white square (the SSH Sentinal Tray Icon) on your Windows taskbar. Move the mouse up to "Select VPN" and click on the submenu that contains the Institute's VPN gateway IP address that you entered earlier. (This should be the only one). It should say "The VPN tunnel was established successfully." The VPN tunnel is now activated and you should be able to fully browse the Institute's network and access its computer resources just as if you were plugged into the network.
3. SSH Statistics, which can be selected from the task bar icon, should show a blue dot under "Security Associations". If it says "No security associations", this means the VPN has not yet been activated.

VIEWING VPN STATISTICS

Right-click on the icon and select the top menu item, "SSH Sentinel Statistics". The purple line in the graph shows you how many encrypted packets are going through the VPN. The Bar graph at left shows how fast the encryption is going.

10. Set up VPN over a dialup line

The next step is to try connecting over a dialup line. It's necessary to set both ends to "any" because the remote user could have any IP. Here is a sample ipsec.conf file for remote dialup users:

# /etc/ipsec.conf - FreeS/WAN IPSec configuration file config setup interfaces=%defaultroute klipsdebug=none plutodebug=none plutoload=%search plutostart=%search uniqueids=yes strictcrlpolicy=yes conn %default keyingtries=1 disablearrivalcheck=no authby=rsasig keyexchange=ike ikelifetime=28800s keylife=86400s pfs=yes compress=no leftcert=certs/myCert.pem auto=add conn remote type=tunnel auth=esp esp=aes128-md5 ike=aes128-md5 left=%defaultroute leftsubnet=0.0.0.0/0 right=%any rightid="C=US, ST=Disrepair, L=Crapville, O=Crapco, CN=Remote Malaria, E=nb@sh-hole.org" rightrsasigkey=%cert rightsubnetwithin=0.0.0.0/0 auto=add

The main differences are:

1. 'leftid' and 'rightid' are set to the Distinguished Name used by the user's certificate. This can be found in the error log when you try to connect without it, or by typing

   /usr/local/sbin/ipsec auto --listall

   Without 'leftid' and 'rightid', you will get messages saying "no connection is authorized". There are other ways of specifying 'leftid' and 'rightid' that will also work.
2. 'right' must be set to '%any'. Pluto will then subtsitute the appropriate IP address, hopefully, for '%any' when the user connects. 'leftsubnet' and and 'rightsubnetwithin' must be set to 0.0.0.0/0, which is equivalent to "everyone". If instead of '%any' you set 'right' to some IP address, such as the remote PC's IP number, or an IP number on your internal network, you'll get messages saying "no connection is known". The "no connection is known" message will also occur if the remote IP doesn't fall within the range specified in 'rightsubnetwithin'.
3. On the other hand, if you set 'right' to the number provided by your ISP for the PPP connection, you will get past "no connection is authorized", and and possibly make it past "no connection is authorized", and all the way to "no suitable connection".
4. 'leftsubnet' is not necessary to setup the VPN, but without it the remote client will only be able to talk to the VPN gateway.
5. Note that 'rightsubnet' and 'rightsubnetwithin' cannot coexist.

1. My Computer ->Network and Dialup Conniptions->Right-click on "Dial-Up connection"->Sharing->Shared Access->Check "enable internet connection sharing for this connection"->OK
2. After you change this, reboot and make sure the blue SSH sentinel icon on the task bar is active (not grayed out).
3. At this point, if everything goes well, SSH Sentinel will be able to set up a VPN. Any existing non-VPN connections will stop responding. The SSH Statistics graph will show a purple line, and "Encryption" will say something other than "0K". This means the VPN is more or less functional.
4. You should also use tcpdump to check the packets coming into the gateway to ensure that they are using ESP.

11. Routing on the gateway

In our test, our network was

Windows PC -> dialup-ISP.net -> IPSec gateway -> destination host

Running tcpcump on the IPSec gateway showed that the packets were being received and forwarded to the destination host. On the destination, tcpdump showed the packets being received. However, the reply was not going back to the VPN gateway, but to dialup-ISP.net, bypassing the VPN gateway altogether, and hence were lost.

To solve this, you need to activate a NAT proxy service on the VPN gateway.

1. Install iptables(www.iptables.org) if necessary.
2. Recompile and install a kernel on the gateway to include the following:

   CONFIG_PACKET CONFIG_NETFILTER CONFIG_IP_NF_CONNTRACK CONFIG_IP_NF_FTP CONFIG_IP_NF_IPTABLES CONFIG_IP_NF_IRC CONFIG_IP_NF_MATCH_LIMIT CONFIG_IP_NF_MATCH_MAC CONFIG_IP_NF_MATCH_MARK CONFIG_IP_NF_MATCH_MULTIPORT CONFIG_IP_NF_MATCH_TOS CONFIG_IP_NF_MATCH_TCPMSS CONFIG_IP_NF_MATCH_STATE CONFIG_IP_NF_MATCH_UNCLEAN CONFIG_IP_NF_MATCH_OWNER CONFIG_IP_NF_FILTER CONFIG_IP_NF_TARGET_REJECT CONFIG_IP_NF_TARGET_MIRROR CONFIG_IP_NF_NAT CONFIG_IP_NF_TARGET_MASQUERADE CONFIG_IP_NF_TARGET_REDIRECT CONFIG_IP_NF_TARGET_LOG CONFIG_IP_NF_TARGET_TCPMSS CONFIG_IP_NF_COMPAT_IPCHAINS CONFIG_IP_NF_COMPAT_IPFWADM

   For details about these options, see the documentation, such as Oskar Andreasson's Iptables Tutorial (http://www.linuxsecurity.com/resource_files/firewalls/IPTables-Tutorial/iptables-tutorial.html) .
3. On the gateway, enter the following two commands:

   iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -A FORWARD -j ACCEPT

   These should be put in /etc/rc.d/boot.local along with the 'echo' commands described earlier so they are automatically issued after a reboot.
4. On the client, set the name server and WINS server for the Dial-Up Connection (My computer->Control panel->Network and dialup connections->right-click on Dial-Up connection->Properties ->Networking->Internet protocol(TCP/IP)->Properties-> Advanced->DNS and WINS).
5. You should now be able to ping internal addresses in your network via the encrypted tunnel.

12. Windows Browsing over a dialup line

      HOSTS ALLOW = 63.127.146.192/255.255.255.192  

The strategy will be:
(1) get remote browsing to work without the "hosts allow" line
(2) get NAT working on the gateway
(3) get remote browsing to work with the "hosts allow" line.

1. Temporarily change your firewall to allow netbios packets in and out.
2. Temporarily remove the "hosts allow" line from /etc/samba/smb.conf and restart samba.
3. Set up a Samba WINS server somewhere on your network.
4. Initiate the VPN connection over the dialup line as described above.
5. Set the WINS server in Windows' Dialup Connection Properties.
6. Check whether Windows can browse when the user types the Samba host name: Click on "My network places" and type the hostname in the Address box at the top, e.g., \\DIPHTHERIA. After a few seconds, the client should see the Windows shares represented as small icons.
7. In most cases, it's desirable for browsing to occur without the user having to type anything. To do this, change the Windows client's Workgroup setting: Control Panel->Network and Dialup connections->Network Identification->Properties->Member of Workgroup. Set the appropriate workgroup name and reboot.
8. Type ipconfig /all in a DOS box to make sure the default TCP/IP parameters weren't scrambled. For some reason, Windows uses a change of the Workgroup as an opportunity to scramble its other network parameters. SSH Sentinel won't start unless it has an IP address and Default Gateway.
9. Click My Network Places->Entire network->Entire contents Microsoft windows network. You should see an icon with all the little Windows computers at work.

The bind interfaces only option in smb.conf is also recommended, because this prevents IP spoofing.

bind interfaces only = True interfaces = eth0 lo

Therefore, we must continue our holy quest to get the øæ©#¥ñ@ thing working. Although nowhere in any documentation files is this mentioned, you must configure the VPN gateway to perform NAT before remote browsing will work.

13. Set up NAT ('Masquerading') on the VPN gateway

• VPN Masquerade HOWTO http://www.linuxsecurity.com/docs/LDP/VPN-Masquerade-HOWTO.html
• VPN Masquerade home page http://www.impsec.org/linux/masquerade/ip_masq_vpn.html

Procedure:

1. Restore the "hosts allow" line in /etc/samba/smb.conf and restart samba.
2. Make sure iptables is compiled into the kernel as described above.
3. tail -f /usr/var/log.smbd will tell you immediately whether the masquerading is working, or whether it is still using the IP provided by your ISP.
4. On the gateway, enter the following commands:

   iptables -F iptables -F -t nat (gets rid of previous iptables entries) iptables -X iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 65.198.102.xx iptables -A FORWARD -j ACCEPT iptables -L -t nat (list all rules)

SNAT is used instead of MASQUERADE because the VPN gateway has a static IP address.

Unfortunately, we can't connect yet, because Windows browsing uses Netbios broadcasts. Netbios packets don't seem to get encrypted by SSH Sentinel in this configuration, so NAT doesn't get a chance to work on them. The WINS server (if it's properly configured) will therefore reject the SMB request because it's coming from outside.

So let's go on to DHCP, which is a better solution anyway. Keep those iptables commands.

14. Set up Virtual IP using Manual Addresses

If the user's ISP uses NAT, you will probably get messages like:

malaria pluto[13581]: "network"[5] 64.157.57.180 #4: cannot respond to IPSec SA request because no connection is known for 0.0.0.0/0===123.123.123.123 ... etc

The ideal solution to this would be to provide users with a virtual IP number. This would have other advantages. For instance, it would make it easy for the remote users to appear to be present on the corporate network, allowing them to browse and send email through your SMTP server without the necessity of activating the server as a mail relay.

However, this is not so easy. Tracing the packets with WinDump on a client running SSH Sentinel has one of three possible effects: (1) SSH Sentinel will die horribly; (2) Windows will die horribly; or (3) both. When SSH Sentinel is configured to have a virtual interface, the behavior is even more difficult to troubleshoot. So you should make sure the VPN configuration works with static IPs as described in previous sections before moving on to Virtual IP.

For the gateway:

1. Make sure the 'echo' and 'iptables' statements described in sections 7 and 13, respectively, have been executed on the gateway.
2. Make sure a functional WINS server is running on the network, and that access control with "hosts allow" is working. (If users discover that they can browse remotely merely by specifying your WINS server, they will dispense with the VPN tunnel altogether and happily browse without encryption across the Internet. At this point, who could blame them?)
3. Use the same /etc/ipsec.conf as described before. The critical section is:

   conn remote type=tunnel auth=esp esp=aes128-md5 ike=aes128-md5 left=%defaultroute leftsubnet=0.0.0.0/0 rightrsasigkey=%cert right=%any rightid="C=US, ST=Disrepair, L=Crapville, O=Crapco, CN=Remote Malaria, E=nb@sh-hole.org" rightsubnetwithin=0.0.0.0/0 auto=add

1. Change the properties for the VPN Connection in SSH Sentinel client so that "Acquire Virtual IP address" is checked.
   
2. Check "Specify Manually" and enter a valid, unused IP address and subnet mask from the network on which the gateway is running.
3. Keep "Remote network" as "any" (0.0.0.0/0.0.0.0).

I'm showing a screen dump because the previous 2,000 times I tried this with virtual IP activated it never worked, and I was actually a little shocked to see this. Evidently, it's essential to setup iptables on the gateway first, or SSH sentinel will simply do nothing when you try to ping, with no error messages on either the client or the server, and no packets going anywhere. But now, we could suddenly browse everywhere except the gateway itself.

The connection had the following properties:

1. The client's "flashlight" icon was displayed for over 30 seconds before the icons appeared.
2. The logs on the destination server (ENTROPY) showed it was a netbios connection between CHOLERA (the Windows remote client), but with the address of the VPN gateway (65.198.102.xx), which means NAT was working:

   [2003/01/12 19:29:18, 2] lib/access.c:check_access(321) Allowed connection from (65.198.102.xx) [2003/01/12 19:29:18, 2] smbd/reply.c:reply_special(92) netbios connect: name1=ENTROPY name2=CHOLERA

3. WINS name resolution also worked, and the browse list of other computers on the network was visible after another long delay.
4. Because of the long delay, Windows will sometimes give up and say "The network path could not be found". Sometimes, the second attempt will work.
5. As on a local LAN, it's necessary to login with the same username on the Windows PCs at both ends to gain access.
6. Clearly, connecting was a Herculean battle for the software. A lot of packets were dropped by the wayside in the struggle, but the Statistics window clearly showed that the connection was encrypted, as evidenced by the purple line in the graph. (The high number of plaintext packets was the result of earlier tests).
   

15. Set up Virtual IP using DHCP

For the client:

1. Change the SSH Sentinel client from using a manual IP to DHCP (Obtain an IP address automatically and Obtain DNS server address automatically).
2. Change the properties for the VPN Connection in SSH Sentinel client so that "Acquire Virtual IP address" is checked.
   In this example, the client uses a static IP of 192.168.100.4 on its LAN interface. This number is not used. When the client establishes a VPN, the client will obtain another number from the VPN gateway by DHCP on its 'virtual' interface. Because this number is internal to the network on which the server is situated, the client is granted complete access to the network's resources.
3. Change the settings in the Policy Manager on the client:

   Security gateway: 65.198.102.xx Remote network: any (0.0.0.0/0.0.0.0) Acquire Virtual IP address = checked Protocol = DHCP DNS Server = 65.198.102.xx WINS Server = 63.127.146.xxx6

   In a real setting, DNS and WINS servers would be provided by the DHCP server and would be left blank.
4. Click Apply.

1. Set up a DHCP server on the gateway running FreeS/WAN. This is relatively simple to do: create an /etc/dhcpd.conf file and start the dhcpd server in /etc/rc.d. Make sure it's working before continuing.
2. Make sure CONFIG_PACKET (Packet socket) and CONFIG_FILTER (Socket Filtering) are enabled in your kernel configuration.
3. Create a leases file so dhcpd will start:

   touch /var/lib/dhcp/dhcpd.leases

4. Obtain dhcprelay from http://www.strongsec.com/freeswan/dhcprelay/
5. Install dhcprelay on the gateway server. Version 0.3.1 or greater is needed if the DHCP server will be on the same host. NOTE: some distributions already have a DHCP relay called 'dhcrelay' [sic]. Be sure to get rid of it first. Dhcprelay can be very troublesome software, so it's recommended to compile it with the debug option. Be sure to get version 0.3.1 or higher.

   tar-xzvf dhcprelay-0.3.1.tar.gz cd dhcprelay-0.3.1 ./configure --enable-debug make make install

6. Backup /etc/dhcpd.conf and rewrite it to handle IPSec users:

   # /etc/dhcpd.conf authoritative; option domain-name "sh-hole.org"; option subnet-mask 255.255.255.192; option domain-name-servers 65.198.102.xx, 63.127.146.xxx; option netbios-name-servers 63.127.146.xxx; # WINS server option netbios-name-servers 63.127.146.xxx; # datagram distribution server # option netbios-dd-server 63.127.146.xxx; # can be 1=broadcast 2=WINS 4=broadcast # then WINS 8=WINS then broadcast option netbios-node-type 8; ddns-update-style interim; #vpn client class class "vpn-clients" { match if option agent.circuit-id = "ipsec0"; } # dummy subnet for lan clients to stop dhcpd from complaining subnet 65.198.102.64 netmask 255.255.255.192 { } subnet 0.0.0.0 netmask 0.0.0.0 { pool { allow members of "vpn-clients"; range 65.198.102.67 65.198.102.69; option broadcast-address 65.198.102.127; option routers 65.198.102.65; default-lease-time 3600; max-lease-time 7200; } pool { deny members of "vpn-clients"; range 65.198.102.70 65.198.102.126; option broadcast-address 65.198.102.127; option routers 65.198.102.65; default-lease-time 60000; max-lease-time 72000; } }

7. Edit /usr/local/etc/dhcprelay.conf

   LOGFILE="/var/log/dhcprelay.log" DEVICES="ipsec0" SERVERDEVICE="lo" DHCPSERVER="65.198.102.xx"

   If the DHCP server is on a different host, set SERVERDEVICE="eth0" instead. The 'Devices' line is a comma separated list and must not contain spaces.
   Caution: don't edit /etc/dhcprelay.conf by mistake. Also, if you reinstall dhcprelay , it's necessary to re-create your conf file, because it will be overwritten.
8. If you are using SuSE Linux, edit /etc/sysconfig/dhcpd and change the interface line from:

   DHCPD_INTERFACE="eth0"

   to

   DHCPD_INTERFACE="lo eth0"

   In earlier versions of SuSE, make the change in /etc/rc.config. Don't do what I did and change NETDEV_0 by mistake. Otherwise, make whatever change is necessary to make the DHCP server listen on the loopback device.
9. You will get a message:

   dhcpd: Multiple interfaces match the same subnet: lo eth0 dhcpd: Multiple interfaces match the same shared network: lo eth0

10. Enable dhcprelay and launch it from /etc/rc.d/boot.local or rc.local:

    cd /etc/rc.d insserv dhcprelay ./dhcprelay start

    Substitute the interface and address of your IPSec gateway. FreeS/WAN must be already running when you start the dhcp relay. If you restart FreeS/WAN, you need to restart DHCP-relay too.
11. Make sure it's going:

    ps -aux | grep dhcp /usr/sbin/dhcpd lo eth0 /usr/local/sbin/dhcprelay

12. The /etc/ipsec.conf file should not be changed, although it should be possible to narrow 'rightsubnetwithin' to the virtual address scope for SSH Sentinel remote clients.
13. Restart the services in the following order: ipsec dhcpd dhcprelay

    cd /etc/init.d ./ipsec restart ./dhcpd restart ./dhcprelay restart

sent MR3, ISAKMP SA established
Informational Exchange message for an established 
ISAKMP SA must be encrypted 

Creating and installing new signed certificates had no effect. If we switched back to manual virtual IP, the message went away. Evidently, the authentication procedure is completely different depending on whether DHCP or manual virtual IP is used.

Changing the client's "Remote network" setting to the correct subnet address instead of 0.0.0.0/0 had no effect. Changing 'rightsubnetwithin' to the same subnet address had no effect. Turning dhcprelay on or off had no effect.

We also tried eliminating the iptables commands on the server to no avail. Annoyingly, every time SSH Sentinel tried and failed to connect, the dialup line was left in an unusable state and we had to re-establish the dialup connection. Occasionally the line would hang before the "must be encrypted" message on the server was wisible in the telnet window; but later examination of the logs showed that it was there.

16. Conclusions

With the connection between SSH Sentinel and FreeS/WAN, we were able to browse the network a few times. However, the browse list took several minutes to appear and browsing often did not work at all, giving error messages that would be discouraging to Windows users. The connection was too unreliable and slow to be useful, and too difficult for Windows users to set up.

It's also tedious to add new users, requiring for each user the editing of ipsec.conf and ipsec.secrets, adding two files (to /etc/ipsec.d/certs and /etc/ipsec.d.private), and keeping records of the user's password and assigned fake IP address. To the difficulty in keeping all this in sync should be added to the tremendous effort in troubleshooting connections for users, many of whom will probably miss one or more steps.

Another disadvantage on the Windows side is that the vendor does not respond to requests for customer assistance or to bug reports. On the Unix side, Usenet and the Freeswan user mailing list are useless for finding solutions to problems -- the answers tend to be either "It worked for me but I have no idea what I did", or answers that are either blatantly incorrect or mere restatements of the question, as if restating the question were a way of answering it.

As a result of all these endless problems, we finally deleted FreeS/Wan and SSH Sentinel and purchased a Symantec VPN appliance.

17. Diagnostic tests

1. Check the client configuration from a DOS window. ipconfig /all should show two interfaces:

   Windows 2000 IP Configuration Host Name . . . . . . . . . . . . : cholera Primary DNS Suffix . . . . . . . : Node Type . . . . . . . . . . . . : Peer-Peer IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : sh-hole.org Ethernet adapter {072BFF2B-4BBE-4A4D-90E7-E8FB35DEB801}: Connection-specific DNS Suffix . : sh-hole.org Description . . . . . . . . . . . : SSH Virtual NIC Physical Address. . . . . . . . . : 0A-B2-C7-2E-D3-7E DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 192.168.100.10 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : DHCP Server . . . . . . . . . . . : 192.168.100.11 DNS Servers . . . . . . . . . . . : 65.198.102.xx 63.127.146.xxx Primary WINS Server . . . . . . . : 63.127.146.xxx Lease Obtained. . . . . . . . . . : Monday, December 23, 2002 12:41:59 PM Lease Expires . . . . . . . . . . : Monday, January 18, 2038 10:14:07 PM Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : sh-hole.org Description . . . . . . . . . . . : Realtek RTL8139(A)-based PCI Fast Ethernet Adapter Physical Address. . . . . . . . . : 00-E0-18-C7-1D-DF DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 192.168.100.16 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.100.1 DHCP Server . . . . . . . . . . . : 192.168.100.1 DNS Servers . . . . . . . . . . . : 65.198.102.xx 63.127.146.xxx Primary WINS Server . . . . . . . : 63.127.146.xxx Lease Obtained. . . . . . . . . . : Monday, December 23, 2002 11:45:35 AM Lease Expires . . . . . . . . . . : Tuesday, December 24, 2002 4:25:35 AM

   The Windows commmand route print also may give helpful information:

   Interface List 0x1 ........................... MS TCP Loopback interface 0x2 ...0a b2 cc 2e d3 7e ...... SSH Virtual NIC 0x1000004 ...00 e0 18 c7 1d df ...... NDIS 5.0 driver ======================================================================== ======================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.100.1 192.168.100.16 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.100.0 255.255.255.0 192.168.100.10 192.168.100.10 1 192.168.100.0 255.255.255.0 192.168.100.16 192.168.100.16 1 192.168.100.1 255.255.255.255 192.168.100.16 192.168.100.16 1 192.168.100.10 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.100.16 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.100.255 255.255.255.255 192.168.100.10 192.168.100.10 1 192.168.100.255 255.255.255.255 192.168.100.16 192.168.100.16 1 224.0.0.0 224.0.0.0 192.168.100.10 192.168.100.10 1 224.0.0.0 224.0.0.0 192.168.100.16 192.168.100.16 1 255.255.255.255 255.255.255.255 192.168.100.10 192.168.100.10 1 Default Gateway: 192.168.100.1 ======================================================================== Persistent Routes: None

2. Check routing on the server.

   route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.100.16 192.168.100.10255.255.255.255 UGH 0 0 0 ipsec0 192.168.100.10 192.168.100.4 255.255.255.255 UGH 0 0 0 ipsec0 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0

3. Ping the client from the server. You should be able to ping the IP of the virtual interface, but not the IP of the real interface.

18. Bugs

1. SSH Sentinel has a few bugs - for example, if you change the network in the policy editor more than once, it may trash its configuration and you will have to reinstall it.

2. Clients lose the ability to browse their local LAN if they install it. In addition to uninstalling the software (Control Panel->Add/Remove Programs), it is necessary to use the Device Manager to remove the Virtual Adapter (see above for details).

19. FreeS/WAN Error Messages

1. %defaultroute cannot cope!!!
   If computer is standalone, it will say this:

   Dec 7 15:01:40 carbon ipsec_setup: no default route, %defaultroute cannot cope!!!

   This means you have to add a default route on the server, or remove %defaultroute from ipsec.conf. For example, type:

   route add default gw carbon

   where carbon is a gateway. Note that this will probably screw up a lot of things, including ppp. To get rid of the default route, type

   route delete default gw carbon

   afterwards.

   You could also start a ppp connection, which should automatically add a default route (although most likely not a useful one).

   A better way is to edit /etc/ipsec.conf , commenting out %defaultroute, and adding a real route:

   config setup # THIS SETTING MUST BE CORRECT or almost nothing will work; # %defaultroute is okay for most simple cases. #interfaces=%defaultroute interfaces="ipsec0=eth0"

   If the server has a real IP number, you should already have a default route.

2. `rsasigkey' errors

   carbon Pluto[6741]: failure to fetch key for (none) from DNS: can only query DNS for key for ID that

   FreeS/WAN wants to get the key from a DNS server. Check in the default section of /etc/ipsec.conf and comment out the %dns lines.

   conn %default keyingtries=0 disablearrivalcheck=no authby=rsasig leftrsasigkey=%dns <-remove this line rightrsasigkey=%dns <-remove this line

3. Make sure it can find the key

   carbon:/usr/local/sbin/etc# ipsec showhostkey ; RSA 2048 bits carbon Sat Dec 7 12:50:09 2002 carbon. IN KEY 0x4200 4 1 AQOE8...[long string of numbers]...mOU9whJ

   If you are merely connecting two networks together, you don't need to set up an SSL-based certificate authority. Just add the RSA keys to /etc/ipsec.conf:

   rightrsasigkey=AQOE8 ...OU9whJ

   Each line in ipsec.conf must start with a tab, unless between "conn" entries.
4. ISAKMP SA messages:

   Informational Exchange message for an established ISAKMP SA must be encrypted

   This message could mean almost anything. It might mean, for instance, that the key used by the client is not recognized by the server. Clients often use keys long after you think you have deleted them. If there is more than one key on the client, delete them all and install only the key that is known to be good.

   Another possible cause is the rightid in /etc/ipsec.conf must match the identity in the certificate exactly. For example, if you had

   rightid="C=US, ST=Disrepair, L=Crapville, O=Crapco, CN=Napoleon Bonaparte, E=nb@sh-hole.org"

   in ipsec.conf, but the certificate had

   rightid="C=US, ST=Disrepair, L=Crapville, O=Crapco, CN=N. Bonaparte, E=nb@sh-hole.org"

   it might give this error. It might also give the error "no suitable connection". The easiest way to fix this is to copy the error message from the logs and paste it into 'rightid'.

   Check to make sure the DN in the cert is identical with the rightid specified in ipsec.conf:

   /etc/ipsec.d/certs > openssl x509 -in tomCert.pem -noout -subject subject= /C=US/ST=Disrepair/L=Crapville/O=Crapco/CN=Napoleon cat /etc/ipsec.conf | grep rightid rightid="C=US, ST=Disrepair, L=Crapville, O=Crapco, CN=Napoleon"

   The error might also mean that the client software simply is not compatible with FreeS/WAN because it continues to send unencrypted data after an SA is established.

5. To change the key

   ipsec newhostkey

6. You either get

   ipsec__plutorun: whack error: "network" leftrsasigkey RSA public-key data malformed (input does not begin with "AQOE8O16NYXGdMeir26rL5vhexmO/J/x55Undw315UdMrsw3zqOJqMqBf4

   or

   ipsec__plutorun: ipsec_auto: fatal error in "network": connection has no "leftrsasigkey" parameter specified

   depending on whether a left leftrsasigkey is present.
   Make sure you enter the correct key. Notice if you type

   ipsec hostkey

   it prints "AQOE8O16NYXGd....", but in /etc/ipsec.secrets there is a line that starts

   #pubkey=0sAQOE8O16NYXGd....

   Add the "0s" to the beginning of the leftrsasigkey and rightrsasigkey strings. RSA keys are necessary for both left and right if the line

   authby=rsasig

   appears in ipsec.conf. However, as described above, it will look for the RSA keys in files in the /etc/ipsec.d/certs/ directory instead of /etc/ipsec.secrets if you change the lines in ipsec.conf to

   rightrsasigkey=%cert leftrsasigkey=%cert

7. More information can be obtained by typing

   /usr/local/sbin/ipsec barf | more

20. Windows Error Messages

1. \\(Server) is not accessible. The network path was not found.
   1. Despite appearances, "Diagnostics" does not start the VPN connection. You must click on "Select VPN" from the SSH Sentinel menu on the task bar. ipconfig /all command should show no valid IP address and ping should not work until the VPN is established.
   2. Make sure IP forwarding is enabled on the server.
2. Policy Manager won't start.
   SSH Sentinel won't start unless the Windows computer already has an IP address.
3. Policy Editor hangs while updating security policy.
   SSH Sentinel installation is trashed. If this repeats after rebooting, SSH sentinel must be reinstalled.

21. Connection problems

1. Able to ping in one direction but not the other.
   Check the logs to make sure DHCP is being relayed correctly.
   

   dhcpd: DHCPDISCOVER from 00:e0:18:c7:1d:df via eth0 dhcpd: DHCPOFFER on 192.168.100.19 to 00:e0:18:c7:1d:df (cholera) via eth0 dhcpd: DHCPREQUEST for 192.168.100.19 (192.168.100.1) from 00:e0:18:c7:1d:df (cholera) via eth0 dhcpd: DHCPACK on 192.168.100.19 to 00:e0:18:c7:1d:df (cholera) via eth0 dhcpd: DHCPDISCOVER from 00:e0:18:c7:1d:df via 192.16 8.100.1 dhcpd: DHCPOFFER on 192.168.100.9 to 00:e0:18:c7:1d:d f via 192.168.100.1 dhcpd: DHCPDISCOVER from 00:e0:18:c7:1d:df via 192.16 8.100.1 dhcpd: DHCPOFFER on 192.168.100.10 to 00:e0:18:c7:1d: df via 192.168.100.1 dhcpd: DHCPDISCOVER from 00:e0:18:c7:1d:df via 192.16 8.100.1 dhcpd: DHCPOFFER on 192.168.100.10 to 00:e0:18:c7:1d: df via 192.168.100.1

   In the above example, 192.168.100.1 is the DHCP and IPSec server. The first DHCP offers, for a non-VPN connection, was through eth0. When the VPN was started, the relay sent the responses through 192.168.100.1 instead.
   The logs (/var/log/dhcprelay.log) should show the correct virtual IP number (192.168.100.10 in this example) being relayed:

   +--------------------------------------------------- | DHCPACK (BOOTREPLY) +--------------------------------------------------- | Addr: unknown: 1f (Size: 6) | Hops: 0 | TID: c571d19b | Sec.: 61478 | Flags: 0000 | C IP: 0.0.0.0 | Y IP: 192.168.100.10 | S IP: 127.0.0.1 | R IP: 127.0.0.1 | MAC: 00:e0:18:c7:1d:df | Server: | File: +--------------------------------------------------- | Type: DHCPACK | Server: 127.0.0.1 | Lease-Time: 269352960 | Net-Mask: 255.255.255.0 | Routers: 192.168.100.1 | DNS Server: 65.198.102.xx, 63.127.146.xxx | Renewal-Time: 134676480 | Reb.-Time: 1309409280 | Broadcast: 192.168.100.255 | Wins-Server: 63.127.146.xxx | Domain: sh-hole.org | Circuit ID: 69 70 73 65 63 30 (ipsec0) +--------------------------------------------------- DEBUG: dhcprelay.c: pass_back() stopped DEBUG: dhcprelay.c: pass_back() started DEBUG: dhcprelay.c: got a invalid dhcp packet (xid) DEBUG: dhcprelay.c: pass_on() started DEBUG: dhcprelay.c: got a DHCPDISCOVER +--------------------------------------------------- | DHCPDISCOVER (BOOTREQUEST) +--------------------------------------------------- | Addr: unknown: 1f (Size: 6) carbon:/etc/init.d# ps -aux | grep dhc root /usr/sbin/dhcpd eth0 lo root tail -f /var/log/dhcprelay.log root /usr/local/sbin/dhcprelay ipsec0 lo 192.168.100.1

   Check to make sure the Windows machine has a gateway for the VPN

   ipconfig /all

Sources

1. DHCPv4 Configuration of IPSec Tunnel Mode HOWTO http://www.strongsec.com/freeswan/dhcprelay/
2. http://www.strongsec.com/freeswan/install.htm
3. http://www.ssh.com/products/sentinel/SSH-Sentinel-1.3-FreeSWAN.pdf
4. http://www.freeswan.org
5. http://www.strongsec.com/freeswan/
6. http://www.strongsec.net/
7. http://lists.freeswan.org/pipermail/users
8. http://www.freeswan.org/freeswan_snaps/CURRENT-SNAP/doc/trouble.html
9. http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/faq.html