home  wiki

FreeSWANandWindowsHowto

Please note this wiki page is a work in progress. Corrections or requests for clarification are very welcome.


What is FreeSWAN?

From the External linkFreeSWAN homepage: FreeSWAN is an implementation of Internet Protocol Security (IPSEC) and Interactive Key Exchange (IKE) for Linux. IPSEC uses strong cryptography to provide both authentication and encryption services. Authentication ensures that packets are from the right sender and have not been altered in transit. Encryption prevents unauthorised reading of packet contents.

Why would I want to use FreeSWAN?

I'm using FreeSWAN to authenticate remote wireless users so they can gain further access to my network.

Why is this page here?

Getting FreeSWAN to work with Windows is a concept that is not well documented on the Internet. No one site will tell you everything you need to know. I spent far too much time chasing up different websites to confirm details or proceedures. It all has to be put in the one place.

What other instructional pages are out there?

http://www.jacco2.dds.nl/networking/freeswan-l2tp.html - great instructions on getting Windows to work FreeSWAN using IPSEC/L2TP. Very few details on getting pppd and l2tpd going though. I haven't used this approach, yet.

http://www.natecarlson.com/linux/ipsec-x509.php - guide to setting up FreeSWAN and Windows using the FreeSWAN X.509 patch.

http://www.strongsec.com/freeswan/install.htm - X.509 patch installation and configuration guide. Not a detailed guide for Windows clients, but great for setting up FreeSWAN.

http://www.securityfocus.com/infocus/1519 - introduction to Microsoft's implementation of IPSEC and L2TPD in Windows.

0. Assumptions


  1. You are trying to make a secure connection from the Windows machine, to the Linux gateway.
  2. The Linux machine must:
    1. Have FreeSWAN with X.509 patches installed. Instructions on how to do this are available at the External linkFreeSWAN website, External linkFreeswan.ca, and the External linkX.509 patch homepage.
    2. For Freeswan 2.02 on Debian you'll need the libgmp3-dev package installed to compile.
    3. Have a static IP address.
  3. The Windows machine must:
    1. be running Windows XP. The procedure for Windows 2000 is similar, so the instructions below might still work
    2. Have the Windows XP support tools installed. You can install these from the do this from the 'Support/Tools' directory on the XP CD. Run the setup program, and you must choose 'Complete installation' to install the tools we require.
    3. For an attempt in Windows 2000 have a chance, at least SP2 must be installed.
  4. Both machines are on the same subnet. If this isn?t the case, look into the use of the 'leftnexthop' and 'rightnexthop' settings for FreeSWAN?s /etc/ipsec.conf configuration file ? the current version of FreeSWAN does not interface with the route table at all, so requires the next hop information to be able to find the other end of the tunnel.

1. Creating and installing certificates


You will need to use the openssl package to create the framework for a Certificate Authority for all machines on your network to trust. Ensure this package is installed on your Linux machine by using apt-get or installing the relevant RPM.

Once installed, you will need to find the location of the CA.sh shell script (sometimes just CA) which we will be using to create the certificates. For Mandrake Linux 9.0, this file is located in /usr/lib/ssl/misc. Other locations might be /var/ssl/misc or /usr/share/ssl/misc.

1.1 Create a Certificate Authority


The config file for OpenSSL, openssl.conf, is located in the parent directory of the directory you located above. Open this file in your favorite text editor, so we can set the number of days the certificates we create will stay valid. Change default_days entry to 3650. Also set default_bits to 2048.

Change back to the misc directory, and create new CA certificates by issuing the command:

./CA.sh -newca


Press enter at the first prompt. You will then be asked for a pass phrase ? PEM files have their content protected by a pass phrase. This particular phrase is for your CA?s certificates. You will need it in later steps, so make sure you remember it.

Then enter the information that your CA will be identified by. Commercial CA?s leave some fields blank, so you only need to enter details that you deem necessary. In the examples below I have entered a country, state, and organisation name for my CA.

You now have your CA's keys residing in the demoCA directory.

To give FreeSWAN access to the CA?s public key, we need to put the key in a place and format FreeSWAN can use. The following command makes a copy of the Root CA in DER format, and outputs it to the right place:

openssl x509 -in demoCA/cacert.pem -outform DER -out /etc/ipsec.d/cacerts/RootCA.der


Now that your Root CA has been created, we can reduce life of subsequent certificates we create. Change this to ~5 years (1825 days) by editing openssl.conf and changing the default_days entry again.

Next, we need to create a certificate revocation list (CRL):

openssl ca -gencrl -out crl.pem


Move this to the right location:

mv crl.pem /etc/ipsec.d/crls


And we're done creating your CA.

1.2 Create a certificate for your Linux machine


Create a certificate for your Linux FreeSWAN gateway using the command:

./CA.sh -newreq


Enter another PEM pass phrase, and enter identification data for your gateway machine. Then use the CA certs to sign the request ("make it official") using the command:

./CA.sh -sign


Public and private keys are now in the files newcert.pem and newreq.pem. Rename these so they are easy to tell apart from other certificates:

mv newcert.pem host.pem
mv newreq.pem host.key


(replace 'host' with suitable machine name)

Copy host.key to your /etc/ipsec.d/private directory. We also need to tell FreeSWAN how to access this file - we do this by entering the PEM pass phrase into your /etc/ipsec.secrets file. The format should look like this:

RSA /etc/ipsec.d/private/silverstone.key "pass phrase"
An older version of /etc/ipsec.secrets will contain a lot of mathematical data relating to your private key as spat out by the fswcert program - with newer versions of FreeSWAN/X.509, this isn't necessary.

Next we can convert the public key to binary DER format and install it as FreeSWAN's default x509 certificate. This step is optional, depending on how you setup your IPSEC settings in /etc/ipsec.conf - but it is best to do it just in case:

openssl x509 -in newcert.pem -outform der -out /etc/x509cert.der


1.3 Create certificates for your Windows machines


This procedure is very similar to the one in the previous section, so look there if you need any clarification on the following commands.

Generate a private key and Certificate Request using ./CA.sh -newreq. Enter the details for your Windows machine.

Sign the request using ./CA.sh -sign.

Rename the two files newreq.pem & newcert.pem:

mv newcert.pem client.pem
mv newreq.pem client.key


Next, the files need to be transferred to the Windows machine. Windows accepts certificates in, amoungst others, PKCS#12 format:

openssl pkcs12 -export -in client.pem -inkey client.key -certfile demoCA/cacert.pem -out client.p12


The first pass phrase is the one used to create the client certificate. The second one you are asked to enter is for encryption of the .p12 file. You will need this again when you import the certificates on the Windows machine.

Record the ID of your client?s certificate, as spat out by the command:

openssl x509 -in client.pem -noout -subject


Later, this ID will be placed into your /etc/ipsec.conf file.

1.4 Importing certificates on the Windows client


Move the .p12 file to your Windows client machine. The file is somewhat protected by the pass phrase, but a secure move (eg. Floppy disk) is better than an unsecure one.

Download the "Windows 2000 VPN tool" from http://vpn.ebootis.de/ and extract the files from the zip file to a temporary directory on your hard disk, eg. C:\ipsec. For the sake of completeness, copy the 'ipseccmd.exe' file from C:\Program Files\Support Tools into this directory. (If you don't have 'ipseccmd.exe' or the 'Support Tools' directory, see the assumptions section at the top of this page.) This program is required by the ipsec tool.

The following instructions on how to import the certificates MUST BE FOLLOWED PRECISELY or else the import may not work properly and you will get "IKE failed to find valid machine certificate" errors later ? you have been warned.

Find the ipsec directory in Windows Explorer and double click the IPSec.msc file. This will bring up an MMC console that will allow the Root CA certificate to be installed correctly. Yes, the console is in German!

Expand the last entry in the list on the right, 'Zertifikate (Lokaler Computer)' which means 'Certificates (Local Computer)'. Select the 'Trusted Root Certification Authorities' folder. In the right pane, in the empty area under 'Certificates', right click and select All Tasks -> Import.

Follow the instructions in the Certificate Import Wizard, selecting your .p12 file and entering the pass phrase that the file was encrypted with. On the next screen, make sure you let Windows decide where to put the certificates that the file contains. Then confirm your selections on the final screen, click finish, and you should be told that the import succeeded. You should NOT be prompted to confirm if you want to add the root CA to any store ? if you get this prompt, the import will fail.

Go into the Certificates folder in the Trusted Root Certification Authorities store. Find your Root CA, and double click on it. In the details tab, click on the 'Subject' entry. Record, in reverse, the entries listed here as a comma separated list, eg:

C=AU, S=Victoria, O=Node DJJ CA


You will need these soon for your Windows ipsec.conf file. You can now close the MMC console ? don?t save changes to the IPSec.msc file.

2. IPSEC Configuration


2.1 Windows side configuration


At the start, Window?s IPSEC settings will be governed by the ipsec.conf file that came with the Windows 2000 VPN Tool. This provides an easy way to get IPSEC up and going, using settings for a simple client-server connection. We will build upon these settings later as your situation requires. The basic ipsec.conf file on your Windows client should look like this:

conn secure-me

left=%any # Local IP address
right=10.10.64.49 # Server IP address
rightca="C=AU, S=Victoria, O=Node DJJ CA" # RootCA DSN from earlier
network=auto
authmode=MD5
pfs=yes
auto=start

For my ipsec.conf files I always consider left = local and right = remote regardless of if we are on the client or server machine. By this standard, left above is the client machine?s IP address. If this is assigned by DHCP or unknown, %any is normally sufficient. right is the IP of the server you are connecting to. rightca is the DSN of your root CA that you noted earlier. The rest are standard options and can be left as they appear above.

Save the file after making your changes.

2.2 Linux side configuration


FreeSWAN?s settings are governed by the /etc/ipsec.conf file. Open this up in your text editor, and copy the following text into it - section headings should have no whitespace before them, and settings should be indented with one tab:

config setup

interfaces="ipsec0=wlan0"
klipsdebug=none
plutodebug=none
plutoload=%search
plutostart=%search
uniqueids=yes

conn %default

authby=rsasig
left=10.10.64.49
leftrsasigkey=%cert
rightrsasigkey=%cert
keyingtries=3
pfs=yes
auto=add

conn secure-me

right=%any
rightid="C=AU, ST=Victoria, O=NodeDJJ, CN=Dushku"
auth=esp
esp=3des-md5-96

You only need to change three settings to get this to suit your own connections. Under the config setup heading, replace wlan0 with the interface that client connections will come from. Under the conn %default heading, change left to the IP of your FreeSWAN server. And under conn secure-me, change rightid to the DSN of your client machine. Note that this must match how Windows identifies itself to FreeSWAN ? commas separate entries, and the 'State' field is denoted by ST not S.

3. Starting the connection


3.1 Firewall considerations


If you are running a firewall on your Linux machine, you will need to add rules to allow other machines to (1) authenticate with FreeSWAN, and (2) talk to the Linux box once the tunnel is up.

Step (1) involves allowing IPSEC traffic through. For key negotiations when the tunnel is first brought up, UDP port 500 is used on both ends of the connection. If you have an IPTables firewall with a default DROP policy for all default chains, adding lines similar to the following to your firewall script will get you started:

iptables -A INPUT -i wlan0 -p udp --sport 500 --dport 500 -j ACCEPT
iptables -A OUTPUT -o wlan0 -p udp --sport 500 --dport 500 -j ACCEPT


This is not an IPTables tutorial (see http://www.linuxsecurity.com/resource_files/firewalls/IPTables-Tutorial/iptables-tutorial.html for one of those) but here is a quick rundown of the first line above:

iptables ?A INPUT			append the rule that follows to the input chain:
-i wlan0				For traffic from the wlan0 interface...
-p udp				...that uses the UDP protocol...
--sport 500			...and originates from port 500...
--dport 500			...and is headed for port 500:
-j ACCEPT			accept this traffic.


You will also nee to let through the key exchange protocols. These are numbered 50 (ESP) and 51 (AH):

iptables -A INPUT -i wlan0 -p 50 -j ACCEPT
iptables -A OUTPUT -o wlan0 -p 50 -j ACCEPT
iptables -A INPUT -i ! wlan0 -p 51 -j ACCEPT
iptables -A OUTPUT -o ! wlan0 -p 51 -j ACCEPT


Step (2) involves allowing traffic from the IPSEC interface (eg. ipsec0, ipsec1, etc.) through your firewall. This will depending on exactly what resources on your system an authorised user will have access to. For access to all services on the local machine, the following IPTables rules will suffice:

iptables -A INPUT -i ipsec+ -j ACCEPT
iptables -A OUTPUT -o ipsec+ -j ACCEPT


The ipsec+ interface will match any interface starting with 'ipsec'. Consult the IPTables tutorial link above if you require more restricted access to the local machine.

3.2 Linux side


Restart (or start) FreeSWAN on your Linux box by typing something along the lines of service ipsec restart. FreeSWAN records a log of its activities in /var/log/secure, so do a tail /var/log/secure or your prefered method of checking logs to see if everything seems ok. Your log should look something like this:

Feb 24 02:35:38 silverstone ipsec__plutorun: Starting Pluto subsystem...
Feb 24 02:35:38 silverstone pluto[9501]: Starting Pluto (FreeS/WAN Version 1.99)
Feb 24 02:35:38 silverstone pluto[9501]:  including X.509 patch with

traffic selectors (Version 0.9.21)
Feb 24 02:35:38 silverstone pluto[9501]: Changing to directory

'/etc/ipsec.d/cacerts'
Feb 24 02:35:38 silverstone pluto[9501]:  loaded cacert file 'RootCA.der'

(892 bytes)
Feb 24 02:35:38 silverstone pluto[9501]: Changing to directory

'/etc/ipsec.d/crls'
Feb 24 02:35:38 silverstone pluto[9501]:  loaded crl file 'crl.pem'

(568 bytes)
Feb 24 02:35:38 silverstone pluto[9501]:  loaded my default X.509 cert

file '/etc/x509cert.der' (953 bytes)
Feb 24 02:35:39 silverstone pluto[9501]: added connection description

"secure-me"
Feb 24 02:35:39 silverstone pluto[9501]: listening for IKE messages
Feb 24 02:35:39 silverstone pluto[9501]: adding interface ipsec0/wlan0 10.10.64.49
Feb 24 02:35:39 silverstone pluto[9501]: loading secrets from

"/etc/ipsec.secrets"

The important line is added connection description "secure-me" ? this tells you that FreeSWAN liked your config and has added the 'secure-me' connection description to its list of possible connections. If this line isn?t there, check over the Linux configuration steps to make sure you haven?t missed anything.

3.3 Windows side


To turn on the IPSEC policies on the Windows machine, start a command prompt, navigate to the folder where you extracted the Windows 2000 VPN tool, and type ipsec. The tool will display details about the connection we defined, pause for 5 to 10 seconds while it does it?s work, then return you to the command line. It hasn?t actually started the tunnel yet ? just brought up the relevant policies in Windows. You can bring up the tunnel by pinging your Linux box:

ping 10.10.64.49


If you are lucky, you will see:

C:\>ping 10.10.64.49


Pinging 10.10.64.49 with 32 bytes of data:


Negotiating IP Security.
Reply from 10.10.64.49: bytes=32 time=2ms TTL=64
Reply from 10.10.64.49: bytes=32 time=1ms TTL=64
Reply from 10.10.64.49: bytes=32 time=2ms TTL=64


Ping statistics for 10.10.64.49:
 Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
 Minimum = 1ms, Maximum = 2ms, Average = 1ms


The connection attempt is also recorded by FreeSWAN in /var/log/secure, looking something like:

Feb 24 04:28:01 silverstone pluto[10356]: "secure-me"[1] 10.10.64.60 #1:

responding to Main Mode from unknown peer 10.10.64.60
Feb 24 04:28:02 silverstone pluto[10356]: "secure-me"[1] 10.10.64.60 #1:

Peer ID is ID_DER_ASN1_DN: 'C=AU, ST=Victoria, O=NodeDJJ, CN=Dushku'
Feb 24 04:28:02 silverstone pluto[10356]: "secure-me"[1] 10.10.64.60 #1:

sent MR3, ISAKMP SA established
Feb 24 04:28:02 silverstone pluto[10356]: "secure-me"[1] 10.10.64.60 #2:

responding to Quick Mode
Feb 24 04:28:02 silverstone pluto[10356]: "secure-me"[1] 10.10.64.60 #2:

IPsec SA established

As you can see, two connections are brought up for each IPSEC tunnel: the ISAKMP (Internet Security Association and Key Management Protocol) Security Association for key management, and the IPsec Security Association for data transfers.


Version 1 (current) modified Tue, 03 Jul 2007 23:12:00 +1000 by gummAY
[EditText] [Spelling] [Current] [Raw] [Code] [Diff] [Subscribe] [VersionHistory] [Revert] [Delete] [RecentChanges]
> home> about> events> files> members> maps> wiki board   > home   > categories   > search   > changes   > formatting   > extras> site map

Username
Password

 Remember me.
>

> forgotten password?
> register?
currently 0 users online
Node Statistics
building122
gathering192
interested464
operational248
testing201