Read LE VPN : FREESWAN SOUS LINUX text version

LE VPN : FREESWAN SOUS LINUX

· Accueil Suivre dans l'ordre ces étapes... · Le protocol IPSec · Configuration Linux · Compilation du kernel · Installation de FreeSwan IPSec · Configuration de FreeSwan IPSec · Exemple de config ! · Lancement d'un tunnel IPSec

Bienvenue à tous sur ce site où vous trouverez tous ce dont vous avez besoin pour réaliser un Réseau Privé Virtuel. (VPN Virtual Private Network) Tout du début à la fin, de A à Z... Enfin un site en français qui répond à toutes vos questions !!! De l'installation du protocole IPSec dans Linux grâce à l'implémentation de FreeSwan à la configuration des machines, des fichiers de config en mode texte... Même les débutants, qui ne connaissent rien ou pas grand chose, pourrons monter leurs propres VPN, en suivant les instructions ! Et si après de multiples efforts, vous ne parvenez pas à établir une liaison IPSec, vous pourrez toujours nous écrire, ou visiter notre forum à la recherche d'une réponse. Ecrire ici pour tous renseignements, questions... [email protected] Les étudiants sont aussi les bienvenus et peuvent poser leurs questions. Le VPN est une nouvelle technologie, qui est maintenant enseignée dans les écoles spécialisées Ajouter ce protole à Linux est assez simple. Certaines distributions de Linux l'intègrent dans une implémentation appelée FreeS/WAN. Avant de commencer l'installation, il est nécessaire de vérifier si elle n'est pas déjà installée. La présence du fichier /usr/local/sbin/ipsec signifie que le protocole est déjà sur le système.

· · · FreeS/WAN fonctionne grâce a 2 serveurs situés aux 2 extrémités des 2 sousreseaux à relier. Ces 2 serveurs nécessitent la même configuration FreeS/WAN pour fonctionner (fichier /etc/ipsec.conf voir plus loin) mais utilisé de façon symétrique. Les serveurs se servent d'une interface ipsec (il peut y en avoir 4) qui est un alias d'une interface réseau standard (eth0). Les informations cryptées ciruleront via cette interface.

·

L'interface ipsec est obtenue lors de la recompilation du noyau avec FreeS/WAN (traité plus loin).

Il faut tout d'abord préparer Linux à l'installation de freeswan (implémentation de IPSec). Le but du VPN est aussi de relier 2 réseaux locaux (LAN) distant. Par exemple un réseaux en 10.0.0.0 pourra pinguer une machine 192.168.0.1 distante de plusieurs kilomètres. Ces LAN sont biensûr chacun derrière une passerelle adressée publiquement. Règles générales d'implémentation d'IPSec : -> Une passerelle doit possèder 2 interfaces réseaux séparant logiquement et physiquement le réseau privé d'Internet -> -> -> Une passerelle est également un pare-feu à filtration de paquets Une passerelle possède des adresses IP statiques Aucun pare-feu ne doit se trouver sur le route entre les 2 passerelles. L'IP forwarding doit être autorisée sur les deux passerelles. Il faut vérifier : -> que le fichier /etc/sysconfig/network contient la ligne FORWARD_IPV4=YES -> et que le fichier

1 Installation des sources Il est tout d'abord nécesssaire d'avoir la source du noyau (kernel) de Linux car il doit être patché puis recompilé pour installer FreeS/WAN. Un noyau se récupère sur www.kernel.org par exemple. (récupérer une version stable, v2.4.18 par exemple). Ne soyez pas affayé si vous n'avez jamais compilé un noyau ! Ce n'est pas du tout compliqué ! Une fois la source récupérée (un fichier compressé tar.gz), il faut la décompresser dans le répertoire /usr/src/. La commande tar ­xzf kernel-

2.4.18.tar.gz permet la décompression. Un repertoire /usr/src/linux sera créé, dans lequel se trouvent les sources du nouveau kernel. Il faut maintenant configurer le noyau, pour l'instant sans intégrer FreeS/WAN afin de s'assurer que tout fonctionne (niveau réseau...) sans le protocole IPSec mais avec le nouveau kernel. 2 Phase de configuration du noyau Dans le répertoire /usr/src/linux, taper : make mrproper, puis : Pour une configuration du noyau en mode graphique : make xconfig Pour une configuration en mode texte : make menuconfig (méthode conseillée) Pour une configuration en mode texte pur (questionsréponses) : make config Choisissez une de ces trois commandes qui permettent la configuration du noyau. C'est à ce moment qu'il faut choisir les options. (Regarder bien dans les sections NETWORK, et veillez bien à prendre les bons drivers pour vos cartes réseaux !! Profitez en pour installer les fonctions de firewall de linux. Selectionner IPCHAINS) Une fois la configuration terminée, il faut sauvegarder et quitter.

3 Phase de compilation du noyau et des modules Les commandes suivantes vont vraiment compiler le noyau : (toujours dans usr/src/linux) Make dep clean bzImage modules modules_install La compilation prend quelques minutes selon la vitesse du PC.

4 Installation du nouveau noyau La commande make install permet l'installation... Après l'installation, il faudra taper lilo, qui permet de s'assurer que le chargeur de boot voit bien le nouveau kernel. Il faut maintenant redémarrer ! Et voir si tous se passe bien. Votre réseau doit fonctionner sans problèmes avant d'installer FreeSwan ! 1 Récupération du fichier d'installation Il faut tout d'abord télécharger FreeS/WAN sur le site www.freeswan.org par exemple. Un fichier du type freeswan-1.97.tar.gz est ainsi récupéré. Il faut le décompresser dans /usr/src (tar ­xzf freeswan-1.97.tar.gz). Un répertoire /usr/src/freeswan sera créé. 2 Compilation du kernel avec FreeS/WAN Il faut maintenant recompiler le noyau de Linux an lui intégrant le protocole IPSec. Dans le répertoire /usr/src/freeswan, il faut lancer make menugo. Le soft de configuration du kernel apparaît, dans le menu « Network interfaces », la section IPSec est dèjà sélectionnée. Il n'y a plus qu'a quitter en sauvergardant la configuration. Rien de plus !! Toujours dans le répertoire /usr/src/freeswan, il faut exécuter la commande make install, pour lancer la recompilation du noyau. Ceci fait, il faut redémarrer. Le noyau intègre maintenant le module KLIPS, le module de négociation dynamique des connections nommé PLUTO est démarré et de nouvelles entrées sont accessibles dans /proc/net. Si vous ne connaissez

rien à tous cela, ce n'est pas grave ! Vous pouvez continuer sans problème ! L'installation a ajouté bon nombre de fichiers ; parmis eux, /usr/local/sbin/ipsec, le fichier principal (permet la mise en route, l'arrêt, la configuration), et deux fichiers de configurations, /etc/ipsec.conf et /etc/ipsec.secrets. Seuls ces deux fichiers sont à modifier pour configurer une liaison IPSec. Le fichier /etc/ipsec.conf contient la configuration des modules KLIPS et PLUTO et la définition de chaque connection IPSec. Le fichier /etc/ipsec.secrets contient les clés servant à l'authentification des membres établissant une connection IPSec.

1 Paramètrage du module KLIPS (dans ipsec.conf) -> Définir les interfaces réseaux utilisées afin d'établir une connection IPSec : interfaces= « ipsec0=eth0 » -> Cette interface réseau doit possèder une route vers l'autre passerelle IPSec ou la route par défaut. -> Un maximum de quatre interfaces IPSec sont supportées : ipsec0 à ipsec3

2 Définition d'une connection (dans ipsec.conf) -> -> -> -> Type de connection : tunnel ou transport Paramètres TCP/IP de chaque passerelle IPSec et des réseaux privés Algorithme de chiffrage et d'authentification des paquets Mode d'authentification : clés partagées ou asymétriques (RSA)

-> ->

Clé publique de chaque passerelle (RSA) Mode d'initiation de la connection (automatique ou manuelle).

Dans ce cas, nous avons 2 LANs qui doivent être reliés à travers Internet. Chaque LAN est connecté à Internet via un routeur (ou modem etc...) avec des adresses IP statiques.

Les deux passerelles IPSec sont de simples PCs sous Linux. Ils disposent de 2 cartes réseaux chacun. Une carte avec une adresse publique, et l'autre avec une adresse privée. Par exemple, la passerelle de gauche : adresse IP publique 207.151.222.2, connecté à Internet via un routeur adresse IP privée 192.168.1.1 connecté au HUB du réseau privé.

Fichiers ipsec.conf et ipsec.secrets pour la configuration d'une liaison IPSec « sous réseau à sous réseau » authentification par RSA. Configuration de la passerelle de droite.

Ipsec.conf config setup interfaces="ipsec0=eth0" klipsdebug=none plutodebug=none plutoload=%search plutostart=%search conn %default keyingtries=0 conn site1-site2 left=207.151.222.2 leftsubnet=192.168.1.0/24 leftnexthop=207.151.222.1 right=172.35.55.8 rightsubnet=192.168.2.0/24 rightnexthop=172.35.55.1 auto=add auhby=rsasig [email protected] [email protected] leftrsasigkey=0x--clépublique-de-gauche rightrsasigkey=0x--clépublique-de-droite Ipsec.secrets

: rsa { # 256 bits, Fri Apr 12 13:29:47 2002 # for signatures only, UNSAFE FOR ENCRYPTION #pubkey=0x01035c3c464da4fb8c9a61fb8c798d91a5 Modulus: 0x5c3c464da4fb8c9a61fb8c798d91a5d5946 PublicExponent: 0x03 # everything after this point is secret PrivateExponent:0x3d7d525dbc41525da65e61193848 Prime1: 0x9c9e5f3bd5d345020052560b8a2a0bd4dd9 Prime2: 0x96c34af8e1d95fc3454551fc29f15a4c69b79 Exponent1: 0x686994d28e8ac0036e407b1715d3893b Exponent2: 0x648231fb413b952e5152c6a0e6dd9bcfb Coefficient: 0x05ac43c3b6a5d192f392c521b98334d6 }

Explications : Section conn site1-site2

Dans cette section on définit les adresses IP des passerelles entre lesquelles seront établies une connection IPSec. On définit aussi quels sont les sous réseaux derrières chacunes des passerelles. Définir les sous réseaux à pour but de grouper virtuellement les deux sous réseaux. Cela signifie qu'un poste d'adresse 192.168.0.2 (dans notre exemple) sera capable d'atteindre un poste d'adresse 192.168.1.2 d'un LAN distant.

Dans left= on tape l'adresse IP du la passerelle distante. Dans leftsubnet= on tape l'adresse du LAN distant(derrière la passerelle). Dans leftnexthop= on tape l'adresse IP du routeur distant derrière lequel se trouve la passerelle distante. Dans right= on tape l'adresse IP du la passerelle locale. Dans rightsubnet= on tape l'adresse du réseau local.(derrière la passerelle locale). Dans rightnexthop= on tape l'adresse IP du routeur derrière lequel se trouve la passerelle locale. Auto=add signifie que la connection IPSec sera activée manuellement. Authby=rsasig signifie qu'on a une authentification par RSA.

Section rightrsasigkey et leftrsasigkey

Chaque passerelle a une clé publique différente. Elle ont été générées pendant l'installation de FreesWan. Il faut donc garder les fichiers ipsec.secrets précieusement intact. La clé publique contenue dans le fichier ipsec.secrets (#pubkey=0x....) doit être copiée puis collée dans le fichier ipsec.conf dans rightrsasigkey=. La clé publique de la passerelle de droite (fichier ipsec.secrets de cette page) est donc à recopier dans le fichier ipsec.conf section rightrsasigkey=. La clé publique de la passerelle de gauche (passerelle distante), est à recopier dans leftrsasigkey=. configuration réalisée, on peut démarrer le service ipsec sur les deux passerelles. /usr/local/sbin/ipsec setup restart (on redémarre ipsec puisqu'on a modifier la config) puis /usr/local/sbin/ipsec auto ­up site1-site2 (site1-site2 est le nom de la connection définie dans ipsec.conf).

Ipsec practical configurations for Linux Freeswan 1.x.

Jean-Francois Nadeau. 2001/05/09

News 2001/05/09: I was at a LINUQ meeting tonight, a great Linux group in Quebec city promoting free software and Linux. They gave me the opportunity to introduce FreeSwan and VPNs to their members. My presentation (html) is available in french here. You can find the LINUQ group homepage here. Introduction : This tutorial describes the configuration needed to setup Ipsec tunnels in various situations such as RoadWarriors and NATed/Firewall gateways. This document assumes you have already installed Freeswan and knows a bit of the Ipsec/Freeswan terminology. You should read the Freeswan documentation before use of the present document. My Ipsec gateways are :

· · · · · · · · ·

Intel Pentium II 300 Mhz (much more than needed) 128 MB of RAM (32 MB is enough) Redhat 6.0 (with minor updates such as the nettools, netkit and ipchains packages. ) Kernel 2.2.14 to 2.2.19. Freeswan 1.5 to 1.9 I use 3DES-MD5 and ESP in all my configurations. All configurations are done in tunnel mode. I use most default values for rekeying, exept for RoadWarriors. The RoadWarrior always initiates the negociation and authentification of the tunnels.

*** All IP addresses used in this document were selected randomly

The practical configurations covered are : Simple subnet-to-subnet configuration (RSA). Subnet-to-subnet configuration with a NATed gateway (RSA).

RoadWarrior configuration : Freeswan-to-Freeswan (RSA). RoadWarrior configuration : NAI's PGPnet-to-Freeswan (PSK). RoadWarrior configuration : IRE's Safenet SoftPK-to-Freeswan (PSK). Using a central Ipsec gateway as a "tunnel hub". Expanding NT domain logon validation and network browsing through IPSec tunnels. Subnet-to-Subnet : Win2000-to-Freeswan (PSK).

Simple Subnet-to-Subnet configuration. This is the simplest case and easiest to setup. We have 2 LANs that we want to link together through the Internet. Each LAN is connected to the internet via router or firewall with static IP adresses. For example :

Both Ipsec gateways will have the same ipsec.conf configuration file. ipsec.conf config setup interfaces="ipsec0=eth0" klipsdebug=none plutodebug=none plutoload=%search : rsa { # 256 bits, Thu Apr 13 00:29:47 2000 # for signatures only, UNSAFE FOR ENCRYPTION #pubkey=0x01035c3c464da4fb8c9a61fb8c798d91a5 Modulus: 0x5c3c464da4fb8c9a61fb8c798d91a5d5946 ipsec.secrets*

ipsec.conf plutostart=%search PublicExponent: 0x03

ipsec.secrets*

# everything after this point is secret conn %default keyingtries=0 PrivateExponent:0x3d7d525dbc41525da65e61193848 Prime1: 0x9c9e5f3bd5d345020052560b8a2a0bd4dd9 Prime2: 0x96c34af8e1d95fc3454551fc29f15a4c69b79 conn site1-site2 left=207.151.222.2 leftsubnet=192.168.1.0/24 leftnexthop=207.151.222.1 right=172.35.55.8 rightsubnet=192.168.2.0/24 rightnexthop=172.35.55.1 auto=start authby=rsasig [email protected] [email protected] leftrsasigkey=0x--left-public-key rightrsasigkey=0x--right-public-key Exponent1: 0x686994d28e8ac0036e407b1715d3893b Exponent2: 0x648231fb413b952e5152c6a0e6dd9bcfb Coefficient: 0x05ac43c3b6a5d192f392c521b98334d6 }

*Not truly valid, you should create a RSA signature of at least 1024 bits on each gateway. And be carefull with the necessary whites spaces. On each gateway :

/usr/local/lib/ipsec/ipsec rsasigkey 1024 >> mykey

Then paste the key in /etc/ipsec.secrets. Finally, paste the value from the field #pubkey into the coresponding rsasigkey parameter in the ipsec.conf file.

Restart the ipsec service on both gateways and observe the logs for any errors.

This configuration assumes that both Ipsec gateways use the interface eth0 to reach the internet. Most default values were used here for simplicity.

Both gateways must have IP forwarding turned on to allow packets from the leftsubnet to reach the rightsubnet and vice-versa. Ipchains must be installed and used to permit traffic from leftsubnet to rightsubnet.

Remember that Ipsec is as secure as your gateways are. I recommend to only accept Ipsec traffic on the interface visible to Internet. On the left gateway :

# Default policies /sbin/ipchains -P input ACCEPT /sbin/ipchains -P forward DENY # Only allow ipsec traffic, ESP and AH from and to the Internet /sbin/ipchains -A input -p UDP -d 207.151.222.2/32 500 -j ACCEPT /sbin/ipchains -A input -p 50 -d 207.151.222.2/32 -j ACCEPT /sbin/ipchains -A input -p 51 -d 207.151.222.2/32 -j ACCEPT # Allows internal subnet access /sbin/ipchains -A input -s 192.168.1.0/24 -j ACCEPT # Allows traffic from and to internal LANs /sbin/ipchains -A forward -b -s 192.168.1.0/24 -d 192.168.2.0/24 -j ACCEPT # Default input policy back to deny /sbin/ipchains -P input DENY

Disable any unused services (inetd.conf) and protect the remaining services called from inetd (hosts.allow and hosts.deny). Do not run daemons that should not resides on a security gate. I.e DNS, Sendmail and such services with a big security history. I often run SSH on those gateways, its the only backdoor if your tunnel stops working. If using SSH here horrifies you, use a good internal PPP access with callback support... just in case.

That's it for the simple subnet-to-subnet case. The tricky ones coming...

Subnet-to-Subnet configuration with a NATed gateway.

This is the first tricky configuration as one of the gateways is behind a router/firewall doing Network Address Translation (NAT). I use the term NAT here for a 1 to 1 translation. I.e one external IP address is converted to 1 internal IP address and vice-versa. This is not masquerading or PAT. This configuration can only work using ESP, because AH does not support modifications in the IP header. As of Freeswan 1.3, this configuration also only works with RSA authentication. For example :

The difference is that the left gateway is no longer being exposed directly to the Internet. The trick here is to have 2 different configuration files :

Left gateway's ipsec.conf

Right gateway's ipsec.conf

Left gateway's ipsec.conf config setup interfaces=%defaultroute klipsdebug=none plutodebug=none plutoload=%search plutostart=%search

Right gateway's ipsec.conf config setup interfaces=%defaultroute klipsdebug=none plutodebug=none plutoload=%search plutostart=%search

conn %default keyingtries=0

conn %default keyingtries=0

conn site1-site2 left=%defaulroute leftsubnet=192.168.1.0/24 leftnexthop= right=172.35.55.8 rightsubnet=192.168.2.0/24 rightnexthop=172.35.55.1 auto=start authby=rsasig [email protected] [email protected] leftrsasigkey=0x--left-public-key rightrsasigkey=0x--right-public-key

conn site1-site2 left=210.31.25.4 leftsubnet=192.168.1.0/24 leftnexthop=210.31.25.1 right=%defaultroute rightsubnet=192.168.2.0/24 rightnexthop= auto=start authby=rsasig [email protected] [email protected] leftrsasigkey=0x--left-public-key rightrsasigkey=0x--right-public-key

The right gateway only have to see left as its external NATed address. This work because authentication is based on @sgx.yourdomain.com, not on a real IP address ( the @ says to KLIPS to not resolve that name to an IP. No need to put registered hosts names here).

Proceed the same way as the simple subnet-to-subnet configuration for your ipsec.secrets files.

The NAT/Firewall device was in fact a CISCO 1600 router in my setup. Don't forget that the router's access-lists (IOS) or firewall rules must let pass UDP 500 and ESP (50) for that setup to work.

Altough I did not had the chance to test it, this could work even if both gateways are NATed, if you adjust the configuration.

RoadWarrior Configuration : Freeswan-To-Freeswan.

This setup is usefull for moving users with laptop to connect to a central network using Ipsec. As most of the time they will be using a modem over an async connection to the ISP, my example describes that case.

The difficulties of this configuration origins from the fact that the initiator of the tunnel IP configuration (DHCP) is volatile and unknown from the right gateway. The configuration will have to reflect that situation and permit multiple users to connect at the same time. :

Left gateway's ipsec.conf

Right gateway's ipsec.conf

Left gateway's ipsec.conf config setup interfaces=%defaultroute klipsdebug=none plutodebug=none plutoload=%search plutostart=%search

Right gateway's ipsec.conf config setup interfaces="ipsec0=eth0" klipsdebug=none plutodebug=none plutoload=%search plutostart=%search

conn %default keyingtries=1

conn %default keyingtries=1

conn Road-Central left=%defaultroute leftsubnet= leftnexthop= right=172.35.55.8 rightsubnet=192.168.2.0/24 rightnexthop=172.35.55.1 auto=start authby=rsasig [email protected] [email protected] leftrsasigkey=0x--left-public-key rightrsasigkey=0x--right-public-key

conn Road-Central left=0.0.0.0 leftsubnet= leftnexthop= right=172.35.55.8 rightsubnet=192.168.2.0/24 rightnexthop=172.35.55.1 auto=add authby=rsasig [email protected] [email protected] leftrsasigkey=0x--left-public-key rightrsasigkey=0x--right-public-key

This setup works well with RSA authentication, and can work with PSK if you update ipsec.secrets automaticly on the RoadWarrior (had a script to do that).

To bring the ipsec tunnel up as I connect to the internet, I usually remove Ipsec from start-up : /sbin/chkconfig --del ipsec

And bring the ipsec service up and down with my PPP interface through ip-up.local and ip.down.local in the /etc/ppp directory. Don't forget to make those executable.

You can NOT have both RSA and PSK RoadWarriors as of Freeswan 1.3.

Some tips about routing & RoadWarriors :

· ·

·

IP forwarding must be activated (/etc/sysconfig/network) to permit routing to your LAN. Or you can also use the forwardcontrol parameter in ipsec.conf. If your gateway is also a masquerading gateway to the Internet, you should use the rightfirewall parameter in ipsec.conf and adapt the _updown script to ipchains (or anything used to control your firewall chains). The nodes on the protected subnet must use the ipsec gateway as their default gateway. Remember that the packets also needs to come back from your LAN to the RoadWarriors !

RoadWarrior configuration : NAI's PGPnet-to-Freeswan

Using Windows clients to access Freeswan is for me the key to integration of IPSec and the desktop. NAI's PGPnet is great for that task . It is pretty stable and transparent for the user. Remember that only the commercial copy of PGPnet can do tunnels as I will show in this example :

Here's the steps needed to setup PGPnet on the Win32 client (letfgateway) for that configuration (refer to NAI's documentation for installation) :

Steps Set up the adapter connected to the internet. Launch the PGPnet configuration tool and set defaults options

How to do it Start - Program - PGP - Set Adapter Select the network adapter connected to the internet Start - Program - PGP - PGPnet View - Options General Panel : Expert Mode Allow communications with unconfigured hosts Require valid authentication key Cache passphrases between logins *IKE Duration : 6h *IPsec : 6h Advanced panel : Selected options : Ciphers : Tripple DES Hashes : MD5 Diffie-Hellman : 1024 and 1536 Compression : LZS and Deflate Make the IKE proposal : Shared-Key - MD5 - 3DES -1024 bits on top of the list

Steps Make the IPSec proposal :

How to do it

NONE - MD5-TrippleDES -NONE on top of the list Select Perfect Forward Secrecy = 1024 bits Press OK Create the connection's definition. In the Hosts panel, ADD Name : Enter a name for the right gateway IPaddress : Enter its IP address visible to the internet (172.35.55.8) Select Secure Gateway Set shared Paraphrase : enter you preshared key Identity type : select IP address Identity : enter 0.0.0.0 Remote Authentication : select Any valid key Press Ok Select the newly created entry for the right gateway and click ADD, YES Name : Enter a name for the central subnet IP address : Enter its network IP address (192.168.2.0) Select Insecure Subnet Subnet Mask : enter its subnetmask (255.255.255.0) Press OK, YES, YES Test it Ping 192.168.2.1

*I choosed to rekey faster that Freeswan to solve a common rekeying problem with Win32 Ipsec clients.

Some Screenshots of that configuration.

Ipsec.conf and ipsec.secrets on right gateway :

ipsec.conf config setup interfaces="ipsec0=eth0" klipsdebug=none plutodebug=none plutoload=%search plutostart=%search

Ipsec.secrets 0.0.0.0 172.35.55.8 "mypresharedkey"

conn %default keyingtries=1

conn rw_pgp-site2 left=0.0.0.0 leftsubnet= leftnexthop= right=172.35.55.8 rightsubnet=192.168.2.0/24 rightnexthop=172.35.55.1 authby=secret auto=add

All your RoadWarriors will have to share the same PreShared Key.

See my tips about routing and RoadWarriors.

RoadWarrior Configuration : IRE's SafeNet/SoftPK-to- Freeswan

Using the same example as for PGPnet :

IRE's SafeNet/SoftPK (3DES) is a much lighter software to do Ipsec tunnels but does not integrates PGP in emails and local encryption. If your only goal is to do some Ipsec tunnels on a Win32 desktop, SafeNet is the good choice as it is cheaper than NAI's PGPnet.

Its configuration is not complex and works in most cases (exept with ADSL as it does not support a PPPoe interface).

Lets do the Safenet's setup on the Win32 desktop (left gateway) for the configuration above :

Steps Launch the Safenet Security Editor and create a new Security Policy.

How to do it Start - Program - Safenet Soft-PK - Security Policy Editor File - New Connection Enter a name for the connection

Set the connection's parameters

Select the newly created connection : Connection Security : Secure Remote Party Identity and Adressing : Select IP Subnet Enter the rightsubnet (192.168.2.0)

Steps

How to do it Enter its netmask (255.255.255.0) Protocol : ALL Select Connect using Secure Gateway Tunnnel ID Type : Select IP Address Enter right gateway IP address (172.35.55.8)

Expand the properties of the connection (left pane): Select the Identity branch. Select Certificate = none ID Type : Select IP Address Port : Select ALL Local Network Interface : Select the interface used to reach the internet. Click on Pre-Shared Key and enter your pre-shared key.

Select the Security Policy branch Phase 1 negociation mode : Main Mode Select Enable Perfect Forward Secrecy PFS Key Group : Diffie-Hellman Group 2 Select Enable Replay Protection.

Expand the properties of the Security Policy (left pane) : Expand the properties of Authentication Select the Proposal 1 branch

Steps

How to do it Authentication Method : Pre-shared Key Encrypt Alg : Tripple DES Hash Alg : MD5 SA Life : Seconds - 18000 Key Group : Diffie-Hellman Group 1 (Safenet 1.x) Diffie-Hellman Group 2 (Safenet 2.x)

Expand the properties of Key Exchange Select the Proposal 1 branch Select Encapsulation Protocol (ESP) Encrypt Alg : Tripple DES Hash Alg : MD5 SA Life : Seconds - 18000

File - Save Changes Test it. Ping 192.168.2.1

All your RoadWarriors will have to share the same PreShared Key.

The right gateway's configuration (Freeswan) will be the same as the previous example.

As I said earlier, the troubleshooting is a lot easier checking the logs on the responder (right gateway). Most of the problems origins from configuration errors and typos like different netmasks entered on each side.

See my tips about routing and RoadWarriors.

Using a central Ipsec gateway as a "tunnel hub"

If you got multiples subnets connected to a central one, lets say a few remote locations connected to your headquarters, you might want to connect them all using Ipsec to permit communications between those remotes locations. You could create a mesh, i.e a connection from one locations to each others on all your gateways. If you got only 2 or 3 remote locations, this will work. But as you add more and more locations, it is gonna be a pain to administer as you will have to update all your ipsec gateways each time you add another tunnel. If you got 10 or more locations, this could become impossible to maintain ( 10*10 = 100 tunnels !).

Using one central location as a "tunnel hub" simplifies connecting all those subnets together, as only one tunnel is added for a new location. There are 3 drawbacks to that solution :

· · ·

If the central gateway dies, all your tunnels stops working. You will need more bandwith at central gateway's site, as all ipsec tunnels will be routed through it. You will need more processing power on that central gateway, as packets going between 2 remote locations will be encrypted twice.

That configuration might look like this :

The remote locations are on the left side and the headquarters on the right. We want the subnets 192.168.1.0/24, 192.168.2.0/24 and 192.168.3.0/24 to communicate with each others and with the central network 192.168.0.0/24.

The trick to make this work is on the graphic... all remote locations are on a C class network just as the central location. But each SA are for a longer netmask at the central site. Each remote location will create a tunnel from their subnet to the central subnet 192.168.0.0/16. But the central subnet is a 192.168.0.0/24 network.When this is done, the central Ipsec gateway will have an eroute for each remote network. When someone on a remote location wants to talk to another remote location, lets say 192.168.1.8 to 192.168.2.16, it thinks the destination is on the central network, but the central Ipsec gateway have a specific eroute for

the 192.168.2.0/24 network, so it routes the packet through the good tunnel for that remote location. Networks : Central subnet : 192.168.0.0 255.255.255.0 Remote location 1 : 192.168.1.0 255.255.255.0 Remote location 2 : 192.168.2.0 255.255.255.0 Remote location 3 : 192.168.3.0 255.255.255.0

Ipsec tunnels : 192.168.1.0/24 --> 192.168.0.0/16 for remote location 1 192.168.2.0/24 --> 192.168.0.0/16 for remote location 2 192.168.3.0/24 --> 192.168.0.0/16 for remote location 3

The configuration is the same as the Simple subnet-to-subnet case, just remember the network mask trick and everything should work.

You can control wich remote locations can talk to another by adjusting your forwarding rules with ipchains on the central ipsec gateway.

Subnet-to-Subnet configuration : Win2000-to-Freeswan (PSK).

This is the most complex configuration, because of microsoft's strange way to represent a connection and its parameters. This section is far from being complete, as I did not find any simple way to explain this in details yet without making you get crazy through all the menus and options, I will at first try to explain Microsoft's logic of a tunnel mode connection.

We can use the simple subnet-to-subnet case as a model :

A connection in Microsoft's terminology is a Security Policy. An Ipsec Security Policy is configurable through an MMC console with the IP Security management Snap-in added.

When you create a new IP Security Policy (a connection) you must define rules for the traffic going throught it. You must define at least 2 rules for a tunnel mode connection to work :

· ·

One rule for the traffic going from the leftsubnet to the rightsubnet. One rule for the traffic going from the rightsubnet to the leftsubnet.

A rule defines a :

· · · ·

IP Filter. Describing the Ipsec subnets specifications (leftsubnet and rightsubnet). Filter Action. Describing the action to take when the filter applies (Require Security). Authentication Method. Desribing the authentication mode (PresharedKey). Endpoints . Describing the Ipsec gateway to reach (leftgateway or rightgateay).

Ipsec/IKE proposals, rekeying settings and PFS are defined inside the Filter Action.

This logic can be very confusing, as you can go from properties menus inside properties menus. Ouch !

The generics steps I recommend to make this setup work are :

1. 2. 3. 4.

Create a new MMC console and add the IP Security management Snap-in. Create a new security policy. Create a rule for the traffic from left-to-right. Edit that rule and create a IP Filter that specifies the source address as the leftsubnet and the destination address as the rightsubnet. 5. Specify to Require Security on that IP Filter. 6. Edit that Filter Action, enable Perfect Forward Secrecy, and make the Ipsec proposal 3DES-MD5 on top of the list. 7. Specify the enpoint to be the right gateway's IP address. 8. Enter your preshared key. 9. Create a rule for the traffic from right-to-left. 10. Edit that rule and create a IP Filter that specifies the source address as the rightsubnet and the destination address as the leftsubnet. 11. Specify to Require Security on that IP Filter. 12. Edit that Filter Action, enable Perfect Forward Secrecy, and make the Ipsec proposal 3DES-MD5 on top of the list. 13. Specify the enpoint to be the letf gateway's IP address. 14. Enter your preshared key. 15. Save your changes 16. Select you Security Policy, and Assign it through the Action Menu.

Test it :

1. 2. 3. 4. 5.

Ping a host on the other subnet, it should say at first "Negociating IP security". Ping it again to see if it works. Check the EventViewer for any errors. Check the logs on the Freeswan gateway for any errors. Run the ipsecmon program to see the connection status.

The longest SCREENSHOTS you've never seen to setup the previous example. 900 KB...you've been warned ;).

HINTS & LIMITATIONS :

· · ·

·

Configure the Freeswan gateway just like you would be creating a Freeswan-toFreeswan tunnel using PSK for authentication. Be sure to install the Microsoft Encryption Pack for Win2000 before trying anything. It adds 3DES support to the OS, so don't even think something will work without it ! If you modify a Security Policy after it has been assigned, you must restart the Ipsec service (or wait the default 240 minutes of the Ipsec service to read its configuration again).. A RoadWarrior configuration is difficult to do here. Because Win2k does not let you enter 0.0.0.0 as your endpoint. Altough a client to subnet configuration works, the Win2k client needs a static IP address.

I will need feedbacks to make this section clear, so don't hesitate to send me some comments !

Introducing FreeS/WAN and IPsec

Duncan Napier FreeS/WAN (Secure Wide Area Network) is a tool that permits the secure transmission of data over untrusted networks, such as the Internet. The central component of FreeS/WAN is the IETF's (Internet Engineering Task Force) IPsec (Internet Protocol SECurity) specification. Among other things, IPsec is designed to support Virtual Private Networks (VPNs). While FreeS/WAN is Linux-based, it conforms to the IETF's IPsec specification and is known to be interoperable with many other vendor's implementations of IPsec. (Refer to the official Web site, http://www.freeswan.org, for the latest news.) The FreeS/WAN project was started by John Gilmore, is maintained by numerous energetic individuals, and is freely available in source code under the GNU General Public License. IPsec is an extension to the Internet Protocol (IP) that provides authentication and encryption at the OSI Reference Model transport layer. IPsec has been mandated into the IETF's specification of IP version 6 (IPv6). Three protocols are used to handle encryption and authentication: ESP (Encapsulating Security Payload); AH (Authentication Header); and IKE (the Internet Key Exchange). All of these components are included in the FreeS/WAN implementation of IPsec, and are generally invisible to the end user. The ESP and AH handle encryption and authentication, while IKE negotiates the connection parameters, including the initialization, handling, and renewal of encryption keys. The only encryption scheme currently supported by FreeS/WAN is 3DES (the triple DES or Data Encryption Standard, the current standard for IPsec encryption). Authentication is carried out using MD5 digests of a so-called shared secret (a shared key). The shared key could be a mutually agreed upon character string or RSA private keys. FreeS/WAN's KLIPS (kernel IPsec) component, which is compiled into the Linux kernel, implements AH, ESP, and the handling of packets. IKE processes are carried out through FreeS/WAN's standalone pluto daemon. The IETF RFCs and Internet drafts on these and related topics may be found at the official FreeS/WAN Web site. The site also contains full on-line manpages and documentation, as well as numerous links to the full IETF specifications, user-developer mailing lists, mailing list archives, and other IPsec-related sites. FreeS/WAN is an implementation of the IPsec standard through its KLIPS and IKE components. Currently, FreeS/WAN provides support for IPsec over IP version 4 (IPv4), although at the time of writing, FreeS/WAN support for IPv6 was in progress.

FreeS/WAN is meant to be a fully compliant IPsec implementation that imposes a minimum of overhead and will run even on low-end PCs that use the Linux OS. The overhead imposed and measured performance will depend on the configuration of the hardware platform as well as the network bandwidth that is being served. I recently set up a network of FreeS/WAN firewalling gateways (RedHat 6.1, standard 2.2.12 kernel, FreeS/WAN 1.4 running 3DES encryption/MD5 authentication, using IPchains 1.3.9 for firewalling) interconnected through a 512-kb/s DSL (digital subscriber line) WAN (widearea network). The hardware platforms were off-the-shelf Dell Dimension 133-MHz Pentium machines with 32 MB of RAM; the only modification was the installation of 2 Intel Ether Express 10/100 network cards on each machine. The uncompressed sustained transfer rate for a single session in this particular case was measured to be about 450kb/s or about 90% the theoretical maximum. The file transfer showed virtually no effect on either CPU or memory loading. Some performance numbers for FreeS/WAN and other VPN-capable products are given in http://www.epm.ornl.gov/~dunigan/vpnperf.html FreeS/WAN is written and tested around RedHat's implementation of the Linux operating system, but FreeS/WAN is known, with no or slight modification, to work with SuSE, Slackware, and Debian distributions as well. FreeS/WAN has also been reported to work on Linux systems that run non-Intel CPUs, such as the DEC 64-bit Alpha, Motorola Power PC, Sun's SPARC, MIPS, and StrongARM. FreeS/WAN interoperates to varying degrees with the IPsec implementations of other vendors, including Cisco IOS 12.0 and later, Open BSD, Raptor Firewall, CheckPoint FW-1, F-Secure VPN, Xedia Access Point, PGP 6.5/PGPnet, IRE Safenet/SoftPK, Freegate 1.3, Borderware 6.0, Timestep Permit/Gate 2520, Sun Solaris, Intel/Shiva LANrover, and Windows 2000. The official FreeS/WAN Web site has a regularly updated compatibility list with the latest version of its online documentation. The following details the steps required to build a FreeS/WAN VPN-firewall gateway from scratch. The steps to configuring a site-to-site VPN with firewalls on both ends are also included. Numerous other variants, such as point-to-site, site-to-multisite, and point-topoint connections are also possible with slight modifications, but will not be covered here. Installation Due to the regulation of cryptographic tools and applications in some countries, FreeS/WAN is generally not included in the compiled Linux kernel of most Linux distributions. SuSe Linux version 6.3 has been reported to have shipped in Europe with FreeS/WAN compiled in the kernel. FreeS/WAN versions 1.1 and later are known to compile with the Linux 2.0.x and 2.2.x kernels. Refer to the FreeS/WAN Web site for information on the Linux 2.3 kernel, or later versions. The following example was compiled on a standard RedHat 6.1 distribution. FreeS/WAN requires the Linux kernel to be recompiled. The kernel source usually resides in /usr/src/linux. If you need a more recent version of the kernel, download the kernel source and install in /usr/src/linux. Recompiling the Kernel with FreeS/WAN 1. Download the FreeS/WAN source code and digital signatures from: http://www.freeswan.org or:

ftp://ftp.xs4all.nl/pub/crypto/freeswan 2. Move the tar.gz file to: /usr/local/src/ 3. Go to: /usr/local/src/: cd /usr/local/src/ 4. Untar the tarfile, set permissions, and go into the FreeS/WAN source directory: cat /usr/local/src/freeswan-x.x.tar.gz | gunzip | tar xvf - \ chown -R root:root freeswan-x.x 5. Do a test configure and compile of the kernel (usually found in /usr/src/linux) to ensure a functioning kernel. Go into the kernel source root: cd /usr/src/linux make config make dep make bzimage You may wish to load and boot off the kernel as a test, using LILO (refer to section 8). 6. Run the make utility that sets the kernel compilation option using a menu interface. (For other options, see FreeS/WAN documentation): cd /usr/local/src/freeswan-x.x make menugo This particular choice will run the curses-based menu-driven kernel configurator. In nearly all cases, the default options will suffice. Make sure that you choose the option to save the kernel configurations. Go into the Linux source directory and run bzImage: cd /usr/src/linux make bzImage 7. Copy the resulting boot image to the /boot partition: cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-ipsec 8. Edit the boot loader config file /etc/lilo: boot=/dev/hda map=/boot/map install=/boot/boot.b prompt timeout=100 image=/boot/vmlinuz-ipsec label=linux-ipsec root=/dev/hda1 read-only image=/boot/vmlinuz-2.x.x label=linux root=/dev/hda1 read-only

Rerun LILO and you should see: linux-ipsec * linux 9. Reboot the machine. IPsec starts automatically from init.d scripts, which are installed by default during the FreeS/WAN installation. Once the machine has restarted, FreeS/WAN will need to be configured. Configuring TCP/IP for FreeS/WAN The machine running FreeS/WAN functions as a gateway and will require IP forwarding to be enabled between the interfaces. To do this in Linux, change the parameter in /etc/sysconfig/network from: FORWARD_IPV4=false to: FORWARD_IPV4=true Configuring IPsec with FreeS/WAN For the following discussion, assume the network setup shown in Figure 1 is a site-to-site VPN. The file /etc/ipsec.conf will need to be customized. The other parameters (e.g., in the defaults section) can generally be left as is. Refer to the man page for ipsec.conf for full details on the syntax for ipsec.conf files. On server 1.2.3.4, the following network entries are made (Listing 1). On server 5.6.7.8, the converse applies, and left and right are interchanged (Listing 2). Replace the espenckey and espauthkey with keys generated from /usr/local/bin/ranbits, the random key generator that is installed with FreeS/WAN. To reset or restart FreeS/WAN using manual keying, type: /etc/rc.d/init.d/ipsec restart /usr/local/bin/ipsec manual -up

conn_name

where conn_name is the interface name specified by the conn header in /etc/ipsec.conf. Check that the tunnel is set up by typing: /usr/local/sbin/ipsec eroute to display the extended routes on your system. For the above example on the right subnet, expect to see something like: 192.168.1.0/24 -> 192.168.0.0/24 => [email protected]

which shows the tunnel between the subnets and the remote (left subnet) gateway. Once the above setup is complete, you should be able to ping any node on the subnet at the other end of the VPN. Note that you cannot access remote private subnets from any point outside these subnets, including from your own IPsec gateway.

The above setup is for a manually keyed system, which is less secure than an autoconnection keyed system. It should only be used for testing purposes, since it does not use the key management and exchange systems that FreeS/WAN uses for secure cryptographic exchange. FreeS/WAN and Firewalls If you are running a firewall, you will have to allow access through the firewall. An example of such a setup would comprise a tunnel between two firewalls. FreeS/WAN runs well on Linux firewalls with the standard distribution of ipchains. Note that running a FreeS/WAN IPsec tunnel through any device with NAT (Network Address Translation) or IP masquerading will have unpredictable results and is not recommended (refer to documentation, http://www.freeswan.org). If the IPsec gateway is not the platform that performs NAT/masquerading, then it is strongly recommended that the IPsec gateway lies in front of the NAT/masquerading platform. A sample firewall script containing filtering rules for FreeS/WAN is available from the FreeS/WAN Web site. In addition to many of the familiar rules for ipchains, the following directives are required to enable the passage of data packets across the WAN. On Server 1.2.3.4, the following firewalling rules should be added: ipchains -A forward -p all -j ACCEPT -s 192.168.0.0/24 -d 192.168.1.0/24 ipchains -A forward -p all -j ACCEPT -s 192.168.1.0/24 -d 192.168.0.0/24 \ \

These rules must appear before the masquerading rule. The masquerading rules will look like this: #

# FORWARD RULES # ipchains -P forward DENY # ipchains -A forward -p all -j ACCEPT -s 192.168.0.0/24 -d 192.168.1.0/24 ipchains -A forward -p all -j ACCEPT -s 192.168.1.0/24 -d 192.168.0.0/24 ipchains -A forward -p all -j MASQ -s 192.168.0.0/24 -d 0.0.0.0/0 On server 5.6.7.8, the converse is done: \ \ \

ipchains -A forward -p all -j ACCEPT -s 192.168.1.0/24 -d 192.168.0.0/24 ipchains -A forward -p all -j ACCEPT -s 192.168.0.0/24 -d 192.168.1.0/24

\ \

Again, these rules appear before the masquerading rule, and it should look like this: # # FORWARD RULES # ipchains -P forward DENY # ipchains -A forward -p all -j ACCEPT -s 192.168.1.0/24 \ -d 192.168.0.0/24 ipchains -A forward -p all -j ACCEPT -s 192.168.0.0/24 -d 192.168.1.0/24 ipchains -A forward -p all -j MASQ -s 192.168.1.0/24 \ -d 0.0.0.0/0 Once the above manually keyed solution works (try pinging between subnets as a test), an autokeyed solution that uses the IKE (Integrated Key Exchange mediated via the pluto daemon) can be tested. Autokeyed Connection In order to activate the autokeying, a shared secret is placed in the /etc/ipsec.secrets file. This file should be readable only to the root user. The shared secret can be any difficult-to-guess string that is identical in the ipsec.secrets file on each machine. For the above example, left network, it has the following format: 192.168.0.253 192.168.1.253: PSK \ "jx2V2S5grnATGH86gerEpi6Vjl1RTmkuTmS1TRSnuR 1R525WTuTn321m4luVRRjWWU2uR2U3VnkU" where two IP addresses correspond to the ends of the tunnel, separated by a colon, PSK, and a string enclosed in quotes. An alternative is to use RSA private keys (refer to the man page for ipsec.secrets). The following shows the relevant portion of the /etc/ipsec.conf file for the example network, which is identical to the manual key example above, except with manual keying parameters removed: conn left-test type=tunnel left=1.2.3.4 leftnexthop=1.2.3.5 leftsubnet=192.168.0.0/24 right=5.6.7.8 rightnexthop=5.6.7.9 rightsubnet=192.168.1.0/24 keyexchange=ike keylife=8h keyingtries=0 To automatically restart, replace: auto=add with:

auto=start To restart IPsec, run the startup script: /etc/rc.d/init.d/ipsec restart The use of auto=start will automatically bring up the IPsec interface. If you use a firewall, you will need to allow access through the following ports: 500 (UDP), 50, and 51. For IKE (Internet Key Exchange), carried out by the pluto daemon, which handles the negotiation of connection parameters, acceptable algorithms, key sizes, key, and so forth, requires a the UDP protocol connection on port 500. The resulting firewall script would be: ipcha ins -A input -p udp -j ACCEPT -s 0.0.0.0/0 -i eth0 -d $IPSECGW 500 where $IPSECGW is the Internet IP address of the a remote gateway requesting a connection. For added security, the source IP should be stated explicitly. ESP (Encapsulated Security Payload) provides authentication and encryption of the payload contents and requires port 50 to be opened: ipchains -A input -j ACCEPT -i eth0 -p 50 -s $IPSECGW The authentication header (AH) requires access through port 51: ipchains -A input -j ACCEPT -i eth0 -p 51 -s $IPSECGW Troubleshooting There are several troubleshooting tools available that will give detailed debugging information. Two useful tools are ipsec barf and ipsec look (refer to manpages ipsec_barf and ipsec_look). The barf utility collects, formats, and labels the system configuration and logfile information, which it then dumps to standard output as ASCII text. It is primarily intended as a comprehensive remote diagnostic tool that dumps output to a file that the troubleshooter can then analyze for errors. The outpt of the look utility is a pared-down subset of the barf information. Another useful practice is to turn on debugging by setting the parameters assigned to klipsdebug and plutodebug in /etc/ipsec.conf config setup: klipsdebug=all plutodebug=all and restart FreeS/WAN. There is also a mailing list for reporting problems. Refer to the FreeS/WAN documentation. Other Configurations There are numerous themes and variations that you can apply to the above configuration. Point-to-site, site-to-multisite, and point-to-point configurations are some of the other configuration possibilities. Extruded subnet configurations allow the loaning of IP addresses at remote sites over private lines. A common configuration is the socalled "Road Warrior" configuration, which allows remote users with dynamically assigned IP addresses and an IPsec client to tunnel into a private network. FreeS/WAN can work in

environments that use dynamically assigned IP addresses. Refer to the FreeS/WAN documentation on these topics, as well as links to discussions of other example configurations. Conclusion With the increasing penetration of broadband technologies into the ISP market, it is now practical to use the Internet to connect geographically dispersed clusters of private networks. It is apparent that VPN products will greatly enhance the safe and secure interconnectivity of networked devices, whether they are used for communication, monitoring, entertainment, or other purposes. Given the impending explosion of network-capable consumer electronics, FreeS/WAN provides an inexpensive option to secure networking for our everyday world. Sources 1. The official FreeS/WAN Web site and references cited therein: http://www.freeswan.org 2. Linux FreeS/WAN manpages and documentation. 3. Kurt Seifried's Linux Administrator's Guide, specifically the section on IPsec: http://www.securityportal.com/lasg/ipsec

Administering Linux IPSec Virtual Private Networks

Duncan Napier In my article "Introducing FreeS/WAN and IPSec" in the November 2000 issue of Sys Admin magazine, I discussed the basics of setting up IPSec for Linux using the FreeS/WAN package. This article will discuss some of the more advanced features of FreeS/WAN that you can leverage to implement flexible and reliable IPSec VPNs. The ultimate source of information on FreeS/WAN is the official FreeS/WAN Web site (http://www.freeswan.org). The Web site has links to virtually all the tools and information that you will need to implement IPSec on Linux. An Overview of IPSec IPSec is an extension to the Internet Protocol (IP) that provides not just encryption but also authentication at the transport layer (layer 3 of the OSI Reference Model). The next generation of IP, IP version 6 (IPv6), supports IPSec natively, since IPSec is a requirement of the IETF's specification for IPv6. IPSec is a collection of protocols. Three protocols are used to handle encapsulation, encryption, and authentication -- the AH (Authentication Header), the ESP (Encapsulating Security Payload), and the IKE (Internet Key Exchange). IPSec is typically transparent to end users. Applications do not need to be rewritten nor do users need to be retrained to use IPSec-based networks. End users need not even be aware that they are using IPSec to tunnel data through an insecure network. The AH and ESP handle encryption and authentication. The AH is added after the IP header but before the data (payload); see Figure 1. The AH carries authentication

information, typically an MD5 (Message Digest Algorithm) or SHA (Secure Hash Algorithm) generated key. The AH is purely for authentication and used to verify that the senders are who they say they are. The AH does not perform encryption. ESP provides for one or both of encryption and authentication. It may be used with or without AH. While it is possible to set up tunnels with only one of authentication or encryption deployed, this method leaves communications open to numerous forms of attack. Encryption is carried out using a block cipher (a symmetric or shared-key cipher operating on fixed-size blocks of plaintext), with 3DES being commonly used. Figure 2 illustrates the encapsulation process. RFCs for the deployment of other encryption algorithms (e.g., IDEA, Blowfish, and RC4) have been published and are actively supported by vendors. Encryption keys are shared using IKE. IKE negotiates the connection parameters, including initialization, handling, and renewal of encryption keys. Authentication is carried out using privately shared secrets (e.g., a secret phrase) or RSA cryptographic keys that guarantee the identities of both parties. IKE is based on the Diffie-Hellman method for exchanging authentication tokens. Bulk encryption algorithms, such as triple DES or Data Encryption Standard, are used to encrypt data. Hash algorithms such as MD5 and SHA provide authentication of each packet. Connections are "re-keyed" (i.e., a new authentication key is negotiated) at frequent time intervals for added security. IPSec inserts header and encrypted payload data into an existing IP (often non-IPSec) packet. This allows IPSec data to traverse any IP network. A primary reason for the widespread adoption of IPSec (in contrast to IPv6) is that all IP networks (including IP version 4) can pass IPSec traffic with no modification to the underlying network. IPSec has been implemented both in hardware and software. All major vendors of network hardware and software applications support IPSec networking. Virtually all networked operating systems now support IPSec. IPSec also enjoys considerable support in the Open Source community. Although virtually all IPSec implementations are compliant with the existing RFCs, they may not necessarily interoperate. IPSec implementations from different vendors should be tested to ensure that they are fully compatible. FreeS/WAN -- An Open Source IPSec Implementation for Linux FreeS/WAN is composed of two distinct components. The first is KLIPS (KerneL IP Security), a collection of modifications to the standard Linux kernel. For information on compiling KLIPs into a standard Linux kernel, see my previous article or the FreeS/WAN documentation. The second component is the standalone Pluto daemon, which is also installed and configured in the FreeS/WAN install process. Pluto handles IKE protocol authentication requests and interacts with the KLIPS components of the kernel, which handle encapsulation and encryption. FreeS/WAN IPSec is configured through the ipsec.conf file. Once FreeS/WAN is installed on the system, virtually all configuration changes involve editing the ipsec.conf configuration file. Another file, ipsec.secrets, holds authenticators (i.e., cryptographic key sets, shared secrets). The ipsec application (not to be confused with the IPSec protocol -- see the manpage for ipsec) is a set of utilities that control and invoke the IPSec implementation. The ipsec application also contains, among other utilities, a troubleshooting aid, utilities to bring IPSec tunnels up and down, as well as querying the status of each IPSec tunnel. All we need to start building VPNs is to edit the ipsec.conf and ipsec.secrets files and then invoke IPSec through the ipsec application. Introduction to ipsec.secrets and ipsec.conf Files

The ipsec.conf file contains most of the configuration and control information for FreeS/WAN and is located by default in the /etc directory. The man page for ipsec.conf gives full details. The ipsec.conf file is a text file and comprises one or more sections. Anything following a "#" is a comment. A section typically begins on an un-indented new line with two space-separated strings. For example, in Listing 1(a), the section starts with the line: config setup "config" defines the type of section, and "setup" is the section label that identifies each section of a given type. Generally, the types are either "config", which specifies FreeS/WAN system settings, or "conn", which contains the configuration parameters of each VPN tunnel. Each VPN tunnel has it own conn section. Lines within a section are whitespace-indented from the left-hand margin and of the form: klipsdebug=none KLIPS debugging (parameter klipsdebug) is turned on or off by setting it to "all" or "none", as shown above. In all ipsec.conf files, the first section "config setup" contains a section that deals specifically with FreeS/WAN settings, that is, interfaces and connections to negotiate when IPSec is enabled. The following line configures the default gateway on the machine as the interface for all the VPN tunnels: interfaces=%defaultroute Parameter values that are preceded by a "%" indicate a system variable that is loaded by FreeS/WAN when the tunnel is brought up. The value of %defaultroute (the default IP route) is loaded from the system routing table. The following lines: klipsdebug=none plutodebug=none turn off debugging for KLIPS and Pluto. Verbose debugging information is generated when these parameters are set to "all", which can be helpful for troubleshooting. The lines: plutoload=%search plutostart=%search tell Pluto to search (%search) for connections to negotiate. Pluto scans the ipsec.conf file for connections that will be loaded ("conn" sections, see below) and negotiates access for the VPN tunnel where appropriate. The other option explicitly specifies which tunnels to negotiate (e.g., "plutoload="connection_1 conection_2"" will enable the tunnels defined in the "conn connection_1" ,"conn conection_2" sections and ignore others). The section: conn %default

sets the default settings for all parameters for all tunnels that follow. You can think of it as holding global parameters for the rest of the "conn" sections. The line: keyingtries=0 tells IKE to continue attempting indefinitely to re-key a failed connection. Many other parameters can be defined, and most have preset defaults, for example the key exchange mechanism defaults to IKE ("keyexchange=ike") and the default time between re-keyings is 8 hours ("keylife=8h"). The default authentication method for FreeS/WAN is a publicly shared key (PSK) set with: authby=secret The PSK is generally a secret alphanumneric string shared by both parties. Listing 2(a) shows the contents of a typical ipsec.secrets file that holds the PSK and IP address of the sharing parties for the connections in Listings 1(b) and (c). The ipsec.secrets file contains confidential information and should only be made readable and writable by root. In Listing 1(a), all sections after the "conn %default" section define a series of tunnels that I will explore in more detail. Connection specifications are written in terms of "left" and "right" hosts, rather than in terms of local and remote. Which participant is considered left or right is arbitrary; FreeS/WAN determines this based on internal information (e.g., the local IP address). This permits use of identical connection specifications on both systems. IPSec can be used to support secure and transparent host-to-host, subnet-to-subnet, or subnet-to-host tunnels. FreeS/WAN's power and flexibility can be demonstrated with some real-world VPN scenarios. Example Configurations A Transport Mode (Host-to-Host) IPSec VPN -- Listing 1(b) IPSec has two modes -- transport mode and tunnel mode. Transport mode provides source-to-destination protection of the datagrams only. It authenticates, encapsulates, and encrypts the IP data only, but leaves the transport headers (IP information) intact (see Figures 1(a) and 2(b)). As a result, transport mode is typically used to build authenticated host-to-host encrypted tunnels. In Listing 1(b), the machine IP 1.2.3.4 peers through an encrypted tunnel with another machine, IP 5.6.7.8. Figure 3 illustrates this scenario. The line "auto=start" signals that the tunnel connection be brought up when invoked from IPSec. A Tunnel Mode (Subnet-to-Subnet) IPSec VPN -- Listing 1(c) In tunnel mode, a new IP header is created and encapsulates the entire original IP datagram, effectively hiding information about the original sender (Figures 1 and 2(c)). Encapsulation enables complete packets from one network to "tunnel" through other networks. One application is the use of IPSec gateways that connect trusted private networks through an untrusted public one (e.g., the Internet). Figure 4 shows such a configuration. Tunnel Mode IPSec VPN with RSA Authentication -- Listing 1(d) and (e)

The RSA algorithm patent expired in September 2000, and RSA-based authentication is now freely available for FreeS/WAN. IPSec uses RSA keys for authentication, not encryption. Symmetric bulk ciphers are used at the data encryption stage, and keys for these ciphers are distributed using the RSA keys. RSA-based authentication allows network administrators to distribute public RSA keys to all who wish to communicate via IPSec. Possession or theft of the public key does not endanger security because only the bearer of the secret private key (presumably the legitimate owner of the key pair) can complete the authentication process. In Listing 1(d), the rightid and leftid lines ensure that authentication is restricted to specific IP addresses. The ipsec utility run with rsasigkey option generates a public-private key pair in the required format for the ipsec.secets file (see the manpage for ipsec_rsasigkey for further information). Public keys generated by the rsasigkey can then be cut-and-pasted into the ipsec.conf and assigned to leftrsasigkey and rightrsasigkey as in Listings 1(d)-(f). Listing 2(b) shows the ipsec.secrets entry accompanying Listing 1(d) with the RSA key output from generated rsasigkey. FreeS/WAN can also implement X.509 certificates (commonly used for the Secure Sockets Layer -- SSL), which are created and distributed by a trusted third party, called the certification Authority (CA). The X.509 implementation was developed independently from the FreeS/WAN project and is freely available from by StrongSec.com (see http://www.strongsec.com/freeswan/). Once the certificate has been stored locally on the FreeS/WAN host in a specified location, entries leftrsasigkey=%cert and leftrsasigkey=%cert specify use of the certificates. Third-party tools for authentication based on PGPNet are also available (http://www.zengl.net/freeswan/download/). The PSK method uses a single, mutually shared secret as a primary authenticator and the IP addresses as a secondary authenticator. RSA authentication only requires appropriate knowledge of public and private keys of the communicating parties. Therefore, for FreeS/WAN installations that use RSA key pairs, fixed IP addresses no longer serve as identifiers. As a result, RSA authentication can be used to authenticate users having dynamically assigned IP addresses. Listing 1(e) shows such a setup where the local IP address of a gateway with a dynamically assigned IP (defined by the line left=%defaultroute) is loaded automatically. The rightid and leftid lines are used as an extra verification step. These lines can either contain an IP address (Listing 1(d)), a fully qualified domain name (at the risk of bringing down the tunnel should DNS lookups fail), and a non-DNS resolved name preceded by an "@" (as in Listing 1(f)). The last option is basically an arbitrary pair of shared keys. However, unlike the PSK authentication case, security is not endangered for RSAauthenticated installations by theft of this information alone. Road Warrior IPSec VPN Configuration with RSA Authentication -- Listing 1(f) This setup is virtually the same as that for Listing 1(e) except that, instead of a subnetto-subnet connection, we have implemented a subnet-to-host VPN (Figure 5). Thus, there is only one subnet defined. Note the line auto=add, as opposed to auto=start. Instead of bringing up the tunnel, the tunnel is merely "added" onto the static-IP side in a listening state. The tunnel lies dormant and "wakes up" when the host having auto=add set is contacted by the dynamic IP side (the laptop in Figure 5), which has its conn section set to auto=start. FreeS/WAN and Firewalls

In the example listings following 1(a), one or both of the FreeS/WAN gateways is also a router. In many scenarios, these gateways would also be firewalls. Under many circumstances, these firewalls would do Network Address Translation (NAT). Running a FreeS/WAN IPSec tunnel through any device with NAT (Network Address Translation) or IP masquerading will have unpredictable results and is not recommended. If the IPSec gateway is not itself the platform that performs NAT/masquerading (i.e., the tunnel terminates at the NAT gateway), then it is strongly recommended that the IPSec gateway lie in front of the NAT/masquerading platform. Essentially, IPSec must verify the packets before they are rewritten for NAT. The reason for this is that when NAT rewrites the IP headers of packets, the alteration causes the packets to fail IPSec's integrity checks (Figures 1 and 2). Some attempts are being made to overcome this problem, including at least one IETF Internet Draft (http://search.ietf.org/internet-drafts/draftaboba-nat-ipsec-04.txt) and RFC 2709. FreeS/WAN runs on Linux firewalls using the standard distribution of ipchains. FreeS/WAN has also been tested with the Linux 2.4 Kernel's iptables firewalling tools. Iptables has numerous new features that add many enhancements to the firewalling features of ipchains. For Pluto's automatic keying to work, port 500 must be accessible to UDP packets on each of the IPSec gateway hosts. ESP uses protocol 50; AH uses protocol 51 and, if either ESP and AH are used, the firewall rules must be set up accordingly. Sample firewall scripts containing filtering rules for FreeS/WAN are available from the FreeS/WAN Web site. Many canned firewalling scripts, such as those from David Ranch's TrinityOS or the Seattle Firewall Project (SeaWall), contain specific options for configuring firewalls that are IPSec gateways. Generic IPSec settings work for FreeS/WAN. You can further secure IPSec VPNs in addition to the authentication features within FreeS/WAN by restricting connections at the IP level through firewall IP filtering. If, for example, you need to modify the firewall configuration as the status of a connection changes, you can use FreeS/WAN's updown feature in the ipsec.conf file to run modifications to the ipchains script and auto-configure routing tables. Opportunistic Encryption For large systems of interconnected gateways and hosts, keeping track of authentication keys quickly becomes an unmanageable task. Each VPN tunnel has to be laboriously preconfigured with appropriate key and peering information in conn sections at both ends of each tunnel. Consider a complex full-meshed VPN topology with many tunnels, where every node connects once to every other node. The task of manually adding and accounting for all possible peers on each machine increases dramatically as we increase the number of remote gateways. The present situation of connection sections scales poorly in the absence of a key management infrastructure. The latest version of FreeS/WAN (Version 1.9.1 at time of writing) attempts to alleviate some of these issues with opportunistic encryption. Opportunistic encryption does not require prearranged connection, nor does it require the administrators of IPSec gateways to communicate connection section information to each other. In essence, outgoing packets are examined at the IPSec gateway to see whether an encrypted connection to the destination is allowed. If an encrypted connection is permitted, the packet is encrypted. The conn section may look like Listing 1(g), which only specifies the current subnet. The destinations of all outgoing packets are checked for a public key through a DNS record that publishes public keys. In conventional implementations of DNS using BIND,

the public key is merely a string placed in the domains TXT records for that host. For opportunistic encryption to work, control of the DNS reverse maps is required. Because connections to DNS servers are based only on very loose trusts and generally not authenticated, this system is not considered completely secure. The IETF's SDNS security working group is currently drafting the full specification of a secure DNS system. Among the enhancements is a secure KEY resource record that addresses the issue of storing cryptographic public keys. Refer to documentation for FreeS/WAN 1.9.1 and later for this interesting and potentially useful enhancement. Conclusion The recent rise of ubiquitous access to networking and explosive growth of network capacity has pushed interconnectivity to unprecedented levels in recent years. Distributed computing, increasingly mobile users, and growth in the numbers and capabilities of mobile communication/networking devices are driving us toward a more networked future. I hope that this article has demonstrated that the FreeS/WAN Project has risen to meet the challenges of secure and scalable open standards for VPN networking

Information

LE VPN : FREESWAN SOUS LINUX

42 pages

Find more like this

Report File (DMCA)

Our content is added by our users. We aim to remove reported files within 1 working day. Please use this link to notify us:

Report this file as copyright or inappropriate

562399