Linux VPN

Introduzione alle VPN

Una VPN (Virtual Private Network) è un collegamento fra due reti private attraverso la rete pubblica. Una VPN sfrutta i meccanismi di trasporto di Internet per effettuare connessioni fra delle reti remote e scambiare dati fra queste in modo trasparente, come se fossero collegate da un linea diretta.
Il traffico che passa per le VPN viene criptato per garantire la riservatezza dei dati, dal momento che attaversa Internet per delle rotte non note a priori e non controllabili.
Gli host che gestiscono le VPN devono avere un IP pubblico per stabilire un link con il relativo peer e devono entrambi implementare lo stesso protocollo per gestire la VPN.
Una VPN, oltre a collegare due reti remote tramite i loro gateway, può collegare un singolo host client a un server VPN su Internet e tramite quello accedere alla rete privata che gli sta dietro.

L'importanza e la diffusione delle VPN è cresciuta con la crescita di Internet: rispetto a linee dedicate dirette, permettono la connessione fra sedi remote di un'azienda o qualsiasi entità in modo decisamente più economico e amministrabile, pur presentando gli inconvenienti inevitabili dovuti all'uso di Internet: maggiori problemi di sicurezza, meno garanzie di affidabilità e velocità minima.

I PROTOCOLLI USATI PER LE VPN
Qualsiasi metodo per criptare del traffico di rete fra due host remoti può essere usato per creare una VPN, anche protocolli generalmente utilizzati per altri scopi con SSH o SSL.
I protocolli comunemente usati per una VPN sono comunque dedicati a questo scopo e, in diversi modi ottengono risultati analoghi: la creazione di un tunnel criptato entro il quale veicolare i pacchetti di due reti distanti.

IPSEC
E' lo standard più diffuso, generalmente non semplice da configurare ma supportato da molti vendor e sistemi operativi.
Cisco lo supporta sia sui Firewall Pix che nello IOS dei suoi router, per cui esistono versioni dedicate, con supporto hardware per velocizzare la criptazione dei dati.
Microsoft lo supporta nativamente su Windows 2000 e XP e, tramite un client dedicato, su Windows 98/ME/NT.
Per Linux, FreeBSD e altri Unix esistono soluzioni diverse, tra quelle opensource FreeS/Wan è la più nota. Sun supporta IPSec da Solaris 8 in poi.
Checkpoint Firewall-1, SonicWall, Raptor, Shiva, Lucent e molti altri prodotti e produttori lo supportano in soluzioni software o in network appliance dedicate.

PPTP
Protocollo sviluppato da Microsoft e supportato, oltre che su Windows, anche da altri fornitori e prodotti software.
Su Linux e altri Unix ne esiste una versione opensource chiamata PoPTop e altre implementazioni meno diffuse.
E' un adattamento del PPP che permette di stabilire collegamenti punto-punto tramite Internet, risulta meno sicuro di IPsec ma generalmente più semplice, almeno su Windows, da configurare e utilizzare.
Utilizza la porta 1723 TCP per il canale di controllo e il protocollo GRE (IP type 47) per incapsulare i dati.

L2TP
Standard che si basa sul protocollo L2F di Cisco e crea connessioni punto-punto incapsulando PPP (layer2) e quindi permettendo il trasporto anche di protocolli diversi da IP.
I pacchetti incapsulati vengono trasportati tramite UDP per cui può essere nattato facilmente.
Rispetto a IPSec è carente nella criptazione del payload ma ha un overhead minore.

Protocolli proprietari
Molti vendor oltre a supportare i protocolli più diffusi implementano nelle loro soluzioni VPN dei protocolli proprietari che possono rendere più semplice la configurazione di un tunnel fra dispositivi dello stesso produttore ma, ovviamente, difettano in interoperabilità con implementazioni di terzi.
Su Linux è diffuso il protocollo CIPE seppur con scarse possibilità di interoperabilità con dispositivi di terzi e VPND che usa un protocollo custom, oltre a soluzioni particolari come l'uso di ppp incapsulato su SSH.

Introduzione a FreeS/WAN

FreeS/WAN è una delle implementazioni IPsec per Linux più diffuse. Può essere utilizzato per gestire decine di tunnel sulla stessa macchina in grado di comunicare tramite IPsec anche con dispositivi di terzi.

INTRODUZIONE E FEATURES
FreeS/WAN è composto da 3 parti principali:
Klips E' un modulo per il kernel, che va compilato sul kernel corrente (ed è in genere piuttosto sensibile alle variazioni di versione, per cui è bene utilizzarne la versione compatibile con il proprio kernel). Gestisce AH e ESP modificando di conseguenza i pacchetti IP gestiti dal kernel.
pluto E' un demone che gestisce il protocollo IKE per la negoziazione dei tunnel.
User tool vari, che generalmente possono essere invocati dal comando ipsec, con cui di fatto si eseguono tutte le operazioni di gestione delle VPN.

Tramite FreeS/WAN si possono configurare tunnel net-to-net, ai cui estremi si trovano dei gateway delle due reti remote da connettere, oppure si può avere un singoli VPN gateway a cui si collegano client remoti anche con IP variabili (configurazioni roadwarrior, tipicamente utilizzabili su portatili o dial-up stations).
L'interoperabilità con altri software e device IPsec (da Cisco a Microsoft, da Checkpoint a Solaris) è buona, soprattutto se si usano le patch per il supporto di certificati x.509.
Una versione parallela a quella ufficiale che si base su di essa e aggiunge tutte le patch più interessanti (supporto NAT, x.509, algoritmi di criptazione alternativi a 3DES ecc) è Super FreeS/WAN.
Una caratteristica interessante, proposta dagli autori di FreeS/WAN come estensione dello standard IPsec (che loro vorrebbero ratificata in future RFC) è l'Opportunistic Encryption (OE) che, basandosi sul DNS per lo scambio delle chiavi pubbliche, rende l'implementazione di nuovi tunnel molto più rapida e snella.
Al momento è possibile utilizzare questa feature solo fra due VPN gateway basati su FreeS/WAN.
Molte soluzioni VPN (network appliance e distribuzioni standard dedicate) basate su Linux utilizzano FreeS/WAN, spesso con interfacce grafiche che ne semplificano l'installazione e la configurazione.
Fino alla versione 1.99 l'unico protocollo di criptazione supportato è 3DES. DES non viene supportato per la scarsa sicurezza, il supporto AES è previsto nelle future versioni ufficiali o disponibile nelle patch di Super FreeS/WAN. Gli autori, non a torto, non ritengono necessario implementare altri protocolli che complicherebbero il progetto.

INSTALLAZIONE
L'installazione direttamente dai sorgenti richiede un patching del kernel per includere i moduli forniti da FreeS/WAN. Non è ovviamente pratica che può essere felicemente portata a termine da un utente poco esperto ma, per chi è abituato a ricompilarsi il kernel, non presenta particolari difficoltà.
Dal sito ufficiale sono scaricabili anche dei comodi rpm (al momento per RedHat 7 e 8) che rendono l'installazione molto più semplice: basta un rpm -i di freeswan-module.*.rpm e freeswan.*.rpm.
Notare che per usare questi RPM si devono usare i kernel modulari standard di RedHat: se si usa un proprio kernel ricompilato autonomamente è il caso di considerare l'installazione da sorgenti.
Prima di procedere alla configurazione ai due estremi del tunnel è bene assicurarsi che ci sia connettività IP fra i due per evitare troppe perdite di tempo di fase di troubleshooting del setup.
A livello di firewalling, un tunnel IPsec ha bisogno di poter far comunicare i due gateway sulla porta UDP 500, in entrambi i sensi, per il protocollo IKE, inoltre si deve permettere il passaggio di pacchetti IP type 50 per il protocollo ESP, che quindi non usa TCP o UDP per il trasporto, e i pacchetti IP type 51 per il protocollo AH (che, comunque, non viene abilitato di default da FreeS/WAN).
Si trovano in rete inoltre, gli RPM per RedHat che già comprendono le patch per il supporto di certificati x509, fondamentali per l'interoperabilità con le soluzioni IPsec di vari produttori.

CONFIGURAZIONE
FreeS/WAN di default si aspetta il suo file di configurazione in /etc/ipsec.conf e un eventuale /etc/ipsec.secrets con le chiavi RSA o elementi per l'autenticazione fra host. Altri file come certificati e revocation lists devono stare nella directory /etc/ipsec.d/.
Nel file di configurazione, che prevede un discreto numero di direttive, si intende generalmente il lato sinistro (left) come quello locale e quello destro (Right) come quello Remoto ma questa è solo una convenzione in quanto i termini possono essere scambiati.
Il file di configurazione prevede diverse sezioni, all'interno delle quali si definiscono direttive con formato parametro=valore (una per riga, precedute da almeno uno spazio, anche in presenza di # per i comment, senza righe vuote all'interno della stessa sezione).
Le impostazioni generalmente da fornire per ogni tunnel sono:
- Gli host ID dei server VPN e il modo con cui si autenticano (hostid).
- L'IP pubblico del server locale (left)
- L'IP del suo default gateway pubblico (leftnexthop)
- La rete locale a cui il server è collegato (che dovrà essere messa in comunicazione con la rete remota (leftsubnet).
- L'IP pubblico del server remoto (right, può essere un %any per indicare un IP arbitrario)
- L'IP del suo default gateway pubblico (rightnexthop può essere un generico %defaultroute)
- La rete locale a cui il server remoto è collegato (che dovrà essere messa in comunicazione con la rete locale (rightsubnet).
- Il metodo di autenticazione utilizzato (authby).

GESTIONE
Tramite il comando ipsec si possono gestire tutte le userland utility fornite con FreeS/WAN.
Con ipsec --help è possibile vedere tutti i comandi eseguibili, per o quali esistono ottime man pages con prefisso ipsec_ (es: man ipsec_whack).
Qui si elencano alcune opzioni particolarmente utili:
ipsec verify Verifica se il sistema può gestire un tunnel IPsec. Utile per capire in fretta se ci sono problemi di base che precludono il funzionamento.
ipsec setup --start Avvia il servizio IPsec (carica il kernek module Klips e lnacia Pluto per gestire IKE). Coincide, in installazioni basate su RPM a /etc/rc.d/init.d/ipsec start.
ipsec setup --stop Stoppa il servizio IPsec, droppando tutti i tunnel eventualmente attivi.
ipsec whack --status Mostra lo stato corrente del sistema IPsec
ipsec auto --listall Elenca tutte le chiavi PSK, RSA o i certificati x509 che possono essere accettati (leggendo i contenuti da /etc/ipsec.secrets
ipsec newhostkey --output /etc/ipsec.secrets --hostname io.openskills.info Genera una nuova chiave RSA per l'host io.openskills.info e la aggiunge al file ipsec.secrets
ipsec barf Visualizza a video una grande quantità di informazioni utili per il debugging e il troubleshooting in caso di problemi.

Installazione di FreeS/WAN tramite RPM

L'installazione di FreeS/WAN è intrinsecamente complicata, dal momento che richiede la compilazione di un modulo altamente sensibile alle differenze di versione del Kernel.
Dal sito ufficiale, comunque, si possono scaricare degli RPM precompilati per RedHat, per i quali l'unica attenzione da seguire è il rispetto della versione del proprio kernel.

[root@GIOVE root]# ftp ftp.xs4all.nl
Connected to ftp.xs4all.nl (194.109.6.26).
[...]
ftp> cd pub/crypto/freeswan/binaries/RedHat-RPMs
ftp> ls Notare che esistono diverse directory per ogni Kernel version ufficiale di RedHat
227 Entering Passive Mode (194,109,6,26,8,21).
150 Opening ASCII mode data connection for file list
drwxr-xr-x   2 freeswan user         4096 Nov  4 22:31 2.4.18-10
drwxr-xr-x   2 freeswan user         4096 Nov  4 22:31 2.4.18-14
drwxr-xr-x   2 freeswan user         4096 Nov  4 22:31 2.4.18-17.7.x
drwxr-xr-x   2 freeswan user         4096 Nov  4 22:31 2.4.18-17.8.0
drwxr-xr-x   2 freeswan user         4096 Nov 18 10:06 2.4.18-18.7.x
drwxr-xr-x   2 freeswan user         4096 Nov 18 10:06 2.4.18-18.8.0
drwxr-xr-x   2 freeswan user         4096 Dec 23 10:13 2.4.18-19.7.x
drwxr-xr-x   2 freeswan user         4096 Jan  4 06:57 2.4.18-19.8.0
drwxr-xr-x   2 freeswan user         4096 Feb 13 15:50 2.4.18-24.7.x
drwxr-xr-x   2 freeswan user         4096 Feb 13 15:50 2.4.18-24.8.0
drwxr-xr-x   2 freeswan user         4096 Nov  4 22:31 2.4.18-3
drwxr-xr-x   2 freeswan user         4096 Nov  4 22:31 2.4.7-10
drwxr-xr-x   2 freeswan user         4096 Nov  4 22:31 2.4.9-34
-rw-r--r--   1 freeswan user          285 Oct 16 00:25 README
lrwxrwxrwx   1 freeswan user           26 Nov  4 22:44 freeswan-rpmsign.asc -> .
./../freeswan-rpmsign.asc
ftp> cd 2.4.18-14
[...]
ftp> get freeswan-1.99_2.4.18_14-0.i386.rpm
[...]
ftp> get freeswan-module-1.99_2.4.18_14-0.i386.rpm
[...]
[root@GIOVE root]# rpm -i freeswan-module-1.99_2.4.18_14-0.i386.rpm
warning: freeswan-module-1.99_2.4.18_14-0.i386.rpm: V3 RSA/MD5 signature: NOKEY, key ID 5a7e4731
do not forget to install the userland utilities
[root@GIOVE root]# rpm -i freeswan-1.99_2.4.18_14-0.i386.rpm
warning: freeswan-1.99_2.4.18_14-0.i386.rpm: V3 RSA/MD5 signature: NOKEY, key ID 5a7e4731
invoke "service ipsec start" or reboot to begin
[root@GIOVE root]# service ipsec start
ipsec_setup: Starting FreeS/WAN IPsec 1.99...
ipsec_setup: insmod: ipsec: no module by that name found
ipsec_setup: insmod failed, but found matching template module 53cb1f7e.
ipsec_setup: Copying /lib/modules/2.4.18-14/kernel/net/ipsec/53cb1f7e to /lib/modules/2.4.18-14/kernel/net/ipsec/i                                  psec.o.
ipsec_setup: /sbin/insmod /lib/modules/2.4.18-14/kernel/net/ipsec/ipsec.o
ipsec_setup: Using /lib/modules/2.4.18-14/kernel/net/ipsec/ipsec.o
ipsec_setup: Symbol version prefix ''
ipsec_setup: WARNING: eth0 has route filtering turned on, KLIPS may not work
ipsec_setup:  (/proc/sys/net/ipv4/conf/eth0/rp_filter = `1', should be 0)

Installazione di Super FreeS/WAN da sorgenti

Super FreeS/WAN è una versione di FreeS/WAN con incluse alcune delle patch non ufficiali più richieste quali supporto certificati x509, transversal NAT per gestire tunnel anche attraverso connessioni nattate, algoritmi di criptazione aggiuntivi oltre al 3DES di default, notifica e cancellazione delle SA.
Di fatto, pur presentando alcune feature sperimentali, è la soluzione necessaria per creare tunnel con device di terzi tramite certificati x 509 o per situazioni particolari in cui uno dei due estremi del tunnel viene a sua volta nattato da un firewall.

Come per la versione ufficiale di FreeS/WAN, anche questa versione "con gli steroidi" può essere comodamente installata tramite gli RPM (compatibili RedHat 7 e 8) forniti sul sito.
Per chi è pratico di compilazioni di kernel, comunque, il patching è una procedura piuttosto semplice.
cd /usr/src/
wget http://download.freeswan.ca/super-freeswan/super-freeswan-1.99.5.1.tar.gz
tar -zxvf super-freeswan-1.99.5.1.tar.gz
cd super-freeswan-1.99.5.1/
Si scarica, si scompatta, si entra nella directory creata, in cui sono presenti varie sottodirectory e file tra cui:
doc/ Directory con abbondante documentazione (che si trova anche online)
klips/ pluto/ Directory con i sorgenti per i moduli kernel e le userland utilities
rpm-in File di specs per costruire un RPM

make menugo
Con questo comando si apre il familiare menu di configurazione del kernel con già aggiunti, sotto la voce Networking options, i moduli aggiuntivi relativi a FreeS/WAN e con le altre opzioni del kernel precedentmente impostate in una compilazione precedente (è buona cosa operare sulle configurazioni di un kernel già testato, di cui si è certi che funzioni la parte di networking per normali operazioni in rete). Ovviamente, a prescindere da dove si trova la directory super-freeswan-1.99.5.1 da cui si lancia make menugo (il giusto posto sarebbe /usr/src/super-freeswan-1.99.5.1/) ci si aspetta di avere i sorgenti del kernel che si vuole patchare in /usr/src/linux). I moduli preimpostati di FreeS/WAN vanno generalmente bene, a questi si possono aggiungere alcuni algoritmi di criptazione opzionali, che vengono caricati come sotto-moduli (notare che 3DES è incluso di default come algoritmo principale e può essere incluso anche come modulo aggiuntivo).
Dopo la scelta dei moduli si può uscire, salvando la configurazione, e automaticamente viene lanciata la ricompilazione del kernel e dei moduli, tanto che alla fine basterà copiare l'immagine del kernel ottenuta (/usr/src/linux/arch/i386/boot/bzImage) e configurare il LILO o GRUB del caso.
Il Makefile fornito è piuttosto completo e oltre a fornire l'opzione tutto-fare make menugo presenta altre opzioni parziali come make menumod per ricompilare solo i moduli IPsec aggiuntivi.
Terminata la compilazione del nuovo kernel e dei suoi moduli, installato il kernel e aggiornato il file di configurazione del boot loader, è possibile riavviare la macchina e iniziare a lanciarsi nel criptico mondo di IPsec.

I dettagli sulla configurazione sono spiegati altrove, ma è utile sarebe le posizioni dei file che contano:
/etc/ipsec.conf E' il file di configurazione. Ne viene creato uno di esempio che deve ovviamente essere modificato.
/etc/ipsec.secrets Contiene le chiavi e le eventuali password per gestire le autenticazioni fra gli estremi del tunnel
/etc/ipsec.d/ E' una directory in cui si trovano certificati e chiavi
/usr/local/sbin/ipsec E' il comando ipsec (uno script shell) con cui si può gestire praticamente ogni aspetto di FreeS/WAN
/usr/local/lib/ipsec Contiene i vari sotto-comandi di ipsec, che possono essere anche eseguiti direttamente (meglio evitare, dal momento che il comando ipsec imposta anche un environment adeguato, prima di eseguire i sottocomandi)
man ipsec e man ipsec_sottocomando Fornisce ottima e puntuale documentazione

VPND, Virtual Private Network Daemon

Vpnd è una alternativa relativamente semplice e piuttosto funzionale per realizzare VPN interamente basate su Linux (e altri Unix). I dati tra le due reti remote vengono criptati, dai gateway dove gira il demone VPND con l'algoritmo Blowfish, dopo uno scambio manuale preventivo di chiavi.
Necessita delle libreirie zlip e del supporto SLIP sul kernel per funzionare.

INSTALLAZIONE
Prima di installare verificare che il kernel supporti l'interfaccia SLIP (Serial Line Internet Protocol), che viene utilizzata da vpnd per effettuare la connessione tramite linea seriale (modem) o IP.
Decompressi i sorgenti lanciare i soliti configure/make:
root@urano:/usr/src/vpnd#./configure
root@urano:/usr/src/vpnd# make
gcc -DCOMPRESS -DLINUX -DLINUX2 -Wall -O3 -fno-inline  -DCRYPTOX86 -DMD5_HMAC_FAST -DSHA1_HMAC_FAST -DRMD160_HMAC_FAST   -c -o vpnd.o vpnd.c
.....

CONFIGURAZIONE
Il file di configurazione di Vpnd è di default  /etc/vpnd.conf, nel caso si usi il modem per effettuare la  VPN è necessario configurare anche il file di inizializzazione della connessione vpnd.chat.

In aggiunta anche un file contente la "key" di codifica dei dati, che può essere vpnd.key nel caso si abbia scelto il formato base (con il comando ./vpnd -m), vpnd.lcl.key o vpnd.rmt.key
nel caso del formato esteso (cioè una key sul server e una key sul client remoto con il comando ./vpnd -x dir/key/).
In entrambi i casi la key di codifica deve essere copiata nella macchina client attraverso, ovviamente una modalità sicura (es: scp) prima di poter stabilire il tunnel.
Effettuare la stessa procedura di installazione per la macchina Linux all'altro capo della VPN.

GESTIONE
Si può lanciare il demone con il comando vpnd oppure aggiungendo le seguenti opzioni:
vpnd -f /dir/vpnd.conf utilizza un file di configurazione con path diverso dallo standard(/etc/vpnd.conf)
vpnd -n forza vpnd a non diventare un demone

/etc/vpnd.conf

Di seguito il file di configurazione vpnd.conf lato server.
Il file lato client si differenzia solo per la dichiarazione "mode client" e IP.

# File di Configurazione Lato SERVER
mode server
#
# IP e porta del client remoto
client 123.123.123.17 3001
#
# IP e porta del server
server 234.234.0.2 2001
#
# IP dell'interfaccia SLIP locale utilizzata da Vpnd
local 192.168.10.100
#
# IP dell'interfaccia SLIP remota utilizzata da Vpnd
remote 192.168.10.200
#
# Intervallo di tempo tra un ping di controllo e l'altro
keepalive 10
#
# Numero massimo di tentativi del ping
noanswer 3
#
# Il percorso della key di codifica
keyfile samples/key
#
# Il pid file del demone vpnd
pidfile /var/run/vpnd.pid
#
# Ogni quanti secondi viene cambiata la chiave di crittazione
keyttl 120
#
# Settaggio del random device
randomdev /dev/urandom
#
# MTU (maximum-transfer-unit) se settato deve essere identico nella configurazione client
mtu 1500

/etc/ipsec.conf

E' il file di configurazione di FreeS/WAN che contiene tutte le informazioni di base tranne le chiavi e le password per l'autenticazione che stanno in /etc/ipsec.secrets.
Come in molti casi simili, un # ad inizio riga vale come commento, viene diviso in sezioni che possono contenere una o più direttive su righe diverse, le righe vuote non vengono considerate (ma non ci devono essere righe vuote all'interno di una sezione) e può essere usata la direttiva include per importare nel file di configurazione file esterni (es: include ipsec.conf.clienti ), utile per facilitare la gestione e la configurazione di diversi tunnel.
Una sezione inizia con una riga nel formato tipo nome dove tipo indica quale tipo di sezione segue e il nome è arbitrario. Sotto la definizione della sezione devono seguire righe precedute da almeno uno spazio (o un TAB) nella forma attributo=valore, dove, in genere, si definisce solo un valore per riga.

Come affrontare questo Topic nei corsi

Questo argomento è piuttosto complesso e potenzialmente molto lungo da descrivere e approfondire.
Per evitare sovrapposizioni di argomenti si prevede di trattarlo con due approcci e intensità diversi nei due corsi in cui è previsto:

- Corso Linux Security
Affrontare il tema Linux VPN in modo generale, esporre le alternative con cui si possono realizzare VPN sotto Linux, accennare appena più approfonditamente a FreeSWAN e alla sua logica (cenni su come si installa e configura). Non fare alcuna esercitazione pratica su questo Topic.

- Corso Internet Access Server
Trattare questo argomento in modo più approfondito. Analizzare nel dettagli FreeSWAN ed affrontarne le relative esercitazioni pratiche.

LINUX IPSECTOOLS-RACOON & CISCO VPN MINI-HOWTO

Come configurare una VPN ipsec tra un router cisco e Linux 2.6.xx con ipsectools / Howto setup an ipsec VPN beetween a cisco router and a linux box  2.6.xx with ipsectools

LINUX IPSECTOOLS-RACOON & CISCO VPN MINI-HOWTO
Author : Andrea Pierini ([email protected])
Version: 0.1 May, 4th 2005

INTRODUCTION

This document describes how to setup an ipsec VPN tunnel with pre-shared keys authentication beetween a Linux box with 2.6.xx kernel, ipsectools  and a Cisco router with crypto IOS enabled software.
I will describe the configuration of both systems, using a real working example.

BACKGROUND
PREREQUISTES
You will need a Linux 2.6.xx kernel (I tested it on a 2.6.10 kernel), with all the kernel ipsec stuff.
Basically you should enable the following options before compiling the new kernel:

Networking support (NET) [Y/n/?] y
*
* Networking options
*
PF_KEY sockets (NET_KEY) [Y/n/m/?] y
IP: AH transformation (INET_AH) [Y/n/m/?] y
IP: ESP transformation (INET_ESP) [Y/n/m/?] y
IP: IPsec user configuration interface (XFRM_USER) [Y/n/m/?] y
Cryptographic API (CRYPTO) [Y/n/?] y
HMAC support (CRYPTO_HMAC) [Y/n/?] y
Null algorithms (CRYPTO_NULL) [Y/n/m/?] y
MD5 digest algorithm (CRYPTO_MD5) [Y/n/m/?] y
SHA1 digest algorithm (CRYPTO_SHA1) [Y/n/m/?] y
DES and Triple DES EDE cipher algorithms (CRYPTO_DES) [Y/n/m/?] y
AES cipher algorithms (CRYPTO_AES) [Y/n/m/?] y

For more informations about the kernel setup, take a look at the various guides and how-to's. You will also need the ipsectools (wich includes the racoon isakmp server). The latest tools can be downloaded from http://ipsec-tools.sourceforge.net. I used the ipsec-tools-0.5.2 version.

You will also need a Cisco router with ipsec/3des IOS Software release.
I used a Cisco 837 ADSL router.
GOALS
I want to connect a remote office LAN to the main office LAN using an internet ADSL line through a VPN tunnel. Internet access from the remote office should be redirected to the main office for security and  internal policies reasons.

LAYOUT
In order to keep things simple, all references to network devices and configuration in this document will be with respect to the following network configuration:

Remote Office LAN
           ^
           v
         Ethernet0 Loopback0
------------|----------|-----
|Remote Office cisco router |
|         ROR               |
------------|----------------
         ATM0.1
            ^
            |                --------------------------
            -->Internet <--> |Main Office cisco router|
                             ------------|-------------
                                     Ethernet0
                             ^
                                         v
                            eth0
                               --------|------------
                             | Linux Router& VPN  |
                                  |     LRV            |
                                  -------|-------------
                                    eth1
                                         ^
                                         V
                                Main Office LAN


The Main Office has a public Class C Network, variably subnetted. The Remote Office ha a private Class C network.  More in depth, this is the ip adressing scheme:

Office Lan: 192.168.1.0/24
Remote Office Router (ROR) Ethernet0 = 192.168.1.1
Remote Office Router Loopback0 = 82.Y.Y.1 mask 248
Remote Office Router ATM0.1 = 83.Z.Z.2 mask 252

Main Office Lan: 196.X.X.128/25
Linux Router & VPN (LRV) eth0 = 196.X.X.2 mask 248
Linux Router & VPN (LRV) eth1 196.X.X.129 mask 128

As mentioned earlier, all traffic including internet, generated from the remote office should go through the VPN which two endpoints are  ROR and LRV.

IMPLEMENTATION
LINUX SIDE

The eth0 interface of LRV represents the endpoint of the tunnel.
All traffic coming from the remote subnet 192.168.1.0 exits the tunnel at this level and should be processed. There are 2 possibilities:

1.    The packets are destined for the Main Office Lan
2.    The packets are destined for the internet

The first one does not need any special treating, the second one needs further processing in terms of NAT.
These are the steps for the implementation:

a)    configure VPN
b)    configure iptables


VPN
I will not discuss about the ipsec protocol, ah, esp, isakmp and so on, but assume that you are already familiar with it. If not look at the related links. We will use the triple-des (3DES) encryption algorithm, the SHA1 hash algorithm, the Diffie-Hellman exponentiations group 2 (1024) and pre-shared keys authentication.
We need to edit 3 file: /etc/ipsec.conf,  /etc/racoon.conf, /etc/psk.txt

The ipsec.conf file will look like this:

#!/usr/sbin/setkey -f
#
# Flush SAD and SPD
flush;
spdflush;
# Remote Office - Main Office VPN
spdadd 0.0.0.0/0 192.168.1.0/24  any -P out ipsec
esp/tunnel/196.X.X.2-82.Y.Y.1/require;
spdadd 192.168.1.0/24  0.0.0.0/0 any -P in ipsec
esp/tunnel/82.Y.Y.1-196.X.X.1/require;

This file contains the policies for the racoon daemon, i.e. under which conditions racoon should start the tunnel. Please note that we are using the tunnel mode and the esp protocol.

The raccon.conf contains the following entries:

path include "/etc";
path pre_shared_key "/etc/psk.txt";
padding
{
    maximum_length 20;    # maximum padding length.
    randomize off;        # enable randomize length.
    strict_check off;    # enable strict check.
    exclusive_tail off;    # extract last one octet.
}
listen
{
    #isakmp ::1 [7000];
    isakmp 196.X.X.2 [500];
    #admin [7002];        # administrative's port by kmpstat.
    #strict_address;     # required all addresses must be bound.
}
# Specification of default various timer.
timer
{
    # These value can be changed per remote node.
    counter 5;        # maximum trying count to send.
    interval 20 sec;    # maximum interval to resend.
    persend 1;        # the number of packets per a send.

    # timer for waiting to complete each phase.
    phase1 90 sec;
    phase2 90 sec;

}
# here begins the configuration of the Remote Office - Main Office VPN
remote 82.Y.Y.1  {
        my_identifier address 196.X.X.2;
        exchange_mode aggressive,main;
        initial_contact off;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
}
sainfo anonymous
{
        pfs_group 2;
        encryption_algorithm 3des;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate;
        lifetime time 3600 sec;

}

Basically, we define the remote peer 82.X.X.1 and the parameters to use for the phase1 IKE negotiation. Next we specify the parameters that may be used for the setup of the security associations. The definitions are not specific for an IP address (anonymous)
The psk.txt contains the shared secret key:

    82.Y.Y.1    VerYsEcretKey


IPTABLES
We are certainly already using iptables, given that our Linux box is exposed to the internet ;-)
Our firewall script must contain additional entries in order to allow the ipsec traffic and the NAT settings.
The ipsec protocol uses the following ports:

·    Udp Port 500 for ISAKMP
·    Ip port 50 for ESP (51 for AH)

Here are our rules:

#this is for isakmp
/sbin/iptables -A INPUT -i eth0 -p udp --sport 500 -s 82.Y.Y.1 -d 196.X.X.2  --dport 500 -j ACCEPT
/sbin/iptables -A OUTPUT -o external -p udp -s 196.X.X.2 --sport 500 -d 82.Y.Y.1 --dport 500 -j ACCEPT
#and this is for esp
/sbin/iptables -A INPUT -i eth0 -p 50 -s -s 82.Y.Y.1  -d 196.X.X.2  -j ACCEPT
/sbin/iptables -A OUTPUT -i eth0 -p 50 -s -d 82.Y.Y.1  -s 196.X.X.2  -j ACCEPT

Last but not least the NAT rules: we only want web and telnet access for the clients of the Remote Office:

/sbin/iptables -t nat -A POSTROUTING -o eth0 -p tcp -s 192.168.1.0/24 -d ! 196.X.X.0/24 --dport 23  -j SNAT --to 196.X.X.129
/sbin/iptables -t nat -A POSTROUTING -o eth0 -p tcp -s 192.168.1.0/24 -d ! 196.X.X.0/24 --dport 80  -j SNAT --to 196.X.X.129

CISCO SIDE
Ok, we are all familiar with Linux, but Cisco is a little bit different. In order to proceed, you should know the basic configuration commands of the IOS.

These are the configuration steps:

1.    Configure interfaces
2.    Configure the crypto policies
3.    Configure access lists
4.    Apply crypto maps and access lists to the interfaces

INTERFACES
This is the easiest step. We will configure 3 interfaces: ethernet0, ATM0.1 and Loopback0.
Our Telco provider has supplied to us an ADSL line with 8 public ip's (82.X.X.1/28). The external public IP is 83.Y.Y.2
      !
interface Loopback0
ip address 82.Y.Y.1 255.255.255.248
no ip route-cache
no ip mroute-cache

!
interface Ethernet0
ip address 192.168.1.1 255.255.255.0
no ip mroute-cache
hold-queue 100 out
!
interface ATM0.1 point-to-point
ip address 83.Y.Y.2 255.255.255.252
no ip route-cache
no ip mroute-cache
pvc 8/35
encapsulation aal5snap
!
!
ip route 0.0.0.0 0.0.0.0 ATM0.1
      !
Why should we create the Loopback0? Very simple: My telco provider does not permit any traffic generated from the ATM interface (83.Y.Y.2), so we will use one of the 8 ip's as the VPN endpoint.

CRYPTO POLICIES
First, we'll need to configure the phase1 ike negotiations:
      !  
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
lifetime 3600
crypto isakmp key 0 VerYsEcretKey address 196.X.X.2
crypto isakmp keepalive 3600
!
What are we doing? We define a policy number 1, in which we setup the security configurations.
Next we define the secret key and the lifetime parameters that should match the counterpart.
After that, we will setup the crypto map that is used during the phase2 negotiation in order to apply the encryption tunnel.

!
crypto ipsec transform-set MyTransformSet esp-3des esp-sha-hmac
!
crypto map MyMap local-address Loopback0  -> here we tell that the originating ip is 82.Y.Y.1 !!
crypto map MyMap 10 ipsec-isakmp
set peer 196.X.X.2
set transform-set MyTransformSet
set pfs group2
match address 100 -> this is the access list 100!
!
!

ACCESS LISTS
There are 2 main reasons to define the access list: protect our network and define which traffic should be encrypted through the VPN.
A very simple access list, which only permits the ipsec protocols is the following:

!
Access list 110 permit esp 82.Y.Y.0 0.0.0.7 196.X.X.0 0.0.0.255
Access list 110 permit udp 82.Y.Y.0 0.0.0.7 196.X.X.0 0.0.0.255 eq isakmp
Access list 111 permit esp 196.X.X.0 0.0.0.255 82.Y.Y.0 0.0.0.7
Access list 111 permit udp 196.X.X.0 0.0.0.255 82.Y.Y.0 0.0.0.7  eq isakmp
!

Now we will define a special access list for the VPN:
!
access-list 100 permit ip 192.168.1.0 0.0.0.255 any
!
Here we say that the traffic originated from 192.168.1.0 network and directed to any destination should be encrypted, i.e. should use the vpn tunnel. The access list 100 is applied to the crypto map MyMap.






APPLY MAPS AND ACCESS LISTS
Finally we should apply the access lists and crypto map to the specific interfaces:
!
Interface ATM0.1
ip access-group 111 in
ip access-group 110 out
crypto map MyMap
!

TEST AND TROUBLESHOOTING

Now we are ready to test the system. Start racoon in foreground mode with debugging enabled:
/usr/local/sbin/setkey -f /etc/ipsec.conf
/usr/local/sbin/racoon -f /etc/racoon/racoon.conf -F -ddd

Try to ping a host on the Remote Office Network, you should get a lot of messages telling you what racoon is doing.
If everything is ok you should receive an answer to your pings. Try to do same thing on the remote network, then try to access the internet, the main office lan and so on.
In case of problems look at the debug output, use tcpdump, the firewall rules, etc...
On the cisco router enable debugging: debug crypto isakmp, debug ip packets.

DRAWBACK AND IMPROVEMENTS
The main drawback is that we also crypt unnecessary traffic. Web browsing originated from Remote Office Lan does not need to be encrypted but should go through our Linux box. A good solution and possible improvement would be the use of GRE tunnel combined with ipsec but could lead to MTU problems.

THANKS TO
- Ralf Spenneberg for the ipsec-howto.pdf which helped me a lot!
- Renzo Rossi for all the "cool" things he told me about Cisco's ipsec implementation
- All the Linux folk

That's all!

RELATED LINKS

http://www.tldp.org
http://www.ipsec-howto.org/ipsec-howto.pdf
http://www.tldp.org/HOWTO/Networking-Overview-HOWTO.html
http://www.tldp.org/HOWTO/Net-HOWTO/index.html
http://www.tldp.org/HOWTO/VPN-Masquerade-HOWTO.html
http://www.tldp.org/HOWTO/VPN-HOWTO/
http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/
http://www.kernel.org
http://ipsec-tools.sourceforge.net
http://www.spenneberg.org/VPN/Kernel-2_6_IPsec
http://www.netcraftsmen.net/welcher/papers/ipsec1.html
http://www.cisco.com/warp/public/105/IPSECpart1.pdf

Introduzione a PopTop - PPTP Server OpenSource

PopTop è l'implementazione pptp opensource più diffusa ed utilizzata per permettere ad un sistema Unix, tipicamente Linux, di fare da server PPTP per client che supportano questo protocollo per VPN (implementato nativamente su Windows).

Per funzionare poptop si appoggia al pppd comunemente disponibile nelle varie distribuzioni Linux e richiede una configurazione relativamente semplice, ma se si deve interoperare con client Windows E supportare i suoi metodi di default di autenticazione (MSCHAP v2)  e criptazione (MPPE) è necessario avere il supporto del modulo mppe nel kernel, con qualche complicazione in più per il setup iniziale.

INSTALLAZIONE
Dal sito ufficiale è facilmente raggiungibile l'area download che si appoggia a sourceforge.
Si presentano diversi tipi di file (tar.gz dei sorgenti o pacchetti precompilati per alcune delle prinicpali distribuzioni):
- mppe module builder serve per avere il supporto mppe e qundi avere piena interoperabilità con client Windows. Vengono utilizzati due componenti: il comodissimo dkms che permette di ricompilare on.the-fly moduli aggiuntivi del kernel quando questo viene aggiornato (evitando il rischio che il modulo mppe diventi inutilizzabile al primo aggiornamento del kernel) e il vero e proprio modulo mppe, kernel_ppp_mppe, pacchettizzato in modo da essere usato con dkms.
- ppp che contiene anche il server pppd in una versione sufficientemente aggiornata o patchata per supportare mppe (quella di default presente nella propria distribuzione potrebbe non farlo).
- pptpd il server PopTop vero e proprio.

Per l'installazione si suggerisce l'uso dei pacchetti rpm precompilati e di generarsi i propri rpm partendo dagli rpm dei sorgenti (Installare il src.rpm e ricostruire il pacchetto RPM per la propria macchina con rpmbuild -ba /usr/src/redhat/SPEC/pptpd.spec).
SU Debian pptpd è disponibile direttmanete (apt-get install pptpd).
Se si vuole procedere compilando i sorgenti leggere la documentazione sul sito ufficiale.

CONFIGURAZIONE
I file di configurazione essenziali sono 3 /etc/pptpd.conf, /etc/ppp/options.pptpd e /etc/ppp/chap-secrets:
/etc/pptpd.conf contiene informazioni su quali IP assegnare ai client che si collegano e qualche parametro che generalmente non si modifica.
DI fatto il suo contentuo potrebbe limitarsi a qualcosa tipo:
option /etc/ppp/options.pptpd Esplicita la posizione del file che contiene i parametri ppp da usare per le connessioni pptp
localip 10.0.0.60 L'IP sulla rete interna del server PPTP
remoteip 10.0.0.110-119 Il range di IP che si vuole assegnare ai client PPTP che si collegano sulla rete interna.
Può inoltre servire impostare:
bcrelay eth0 Abilita il broadcast dai client alla rete interna (qui su interfaccia eth0), necessario per queli protocolli che si basano su broadcast per funzionare correttamente (può essere utile per sfogliare reti Windows)

/etc/ppp/options.pptpd contiene i parametri ppp da utilizzare ed è quello dove è più importante prestare attenzione ad alcuni dettagli che determinano quali metodi di autenticazione e protocolli di criptazione utilizzare.
In particolare per definire se usare il protocollo mppe e il metodo di autenticazione esistono due diverse sintassi a seconda della versione del pppd installata a disposizione (notare che questo di fatto è un file di configurazione del ppp e di come negoziare la connessione ppp fra server e client).

La sintassi vecchia, che vale per il fork mppe compatibile di ppp 2.4.1, prevede parametri come:
-chap Rifiuta autenticazione CHAP
-mschap Rifiuta autenticazione MSCHAP
+chapms-v2 Forza l'uso di autenticazione basata su MSCHAP v2
mppe-128 Imposta supporto mppe con cifratura a 128 bit
mppe-stateless Abilita mppe in modalità stateless
(Questi sono quelli che forzano MSCHAP2 e mppe e sono compatibili con le impostazioni standard delle VPN Windows).

La sintassi nuova, valida per ppp 2.4.2 e successivi prevede, sempre per i parametri di default per client Windows:
refuse-pap Rifiuta autenticazione PAP (plaintext)
refuse-chap Rifiuta autenticazione CHAP
refuse-mschap Rifiuta autenticazione MSCHAP
require-mschap-v2  Forza l'uso di autenticazione basata su MSCHAP v2
require-mppe  Imposta supporto mppecon cifratura a 128 bit
nomppe-stateful Abilita mppe in modalità stateless

Altri parametri generalmente usati, comuni a tutte le versioni, sono:
lock Crea un file di lock per il server pppd. Nel dubbio, lasciarlo.
debug Abilita il debug della connessione, di solito si trovano i log in /var/log/messages
name nome_server Imposta il nome del server pptd. Deve coincidere con quanto scritto in /etc/ppp/chap-secrets
mtu 1500 Imposta l'MTU dei pacchetti
auth Richiede l'autenticazione del client. Necessario su un server ppp
proxyarp Imposta sul server una arp entry con l'IP assegnato al client, necessario per rendere quest'ultimo visibile agli altri host nella lan del server.
nobsdcomp Disabilita compressione BSD
ms-wins 10.0.0.150 Imposta l'IP del server WINS da assegnare ai client
ms-dns 10.0.0.150 Imposta l'IP del server DNS da assegnare ai client

Le login e le password utilizzabili per i collegamenti vanno scritte in /etc/ppp/chap-secrets la cui sintassi è semplice, preve una riga per utente, con i seguenti dati separati da un tab: nome utente, nome del server (specificato con l'opzione "name" in /etc/ppp/options.pptpd), password (in chiaro!) e eventuale IP da cui il client può collegarsi (usare * per non imporre restrizioni). Ad esempio:
pippo      nome_server      pippo_password      *
Se si è compilato pptp con il supporto smbauth, è possibile autenticare gli utenti via samba, con una configurazione tipo
*      nome_server      &/etc/samba/smbpasswd      *
E' inoltre possibile autenticare gli utenti usando un server radius, per dettagli consultare la documentazione sul sito ufficiale.

FIREWALLING E NETWORKING
Ogni client connesso crea una nuova interfaccia sul server, chiamata ppp0 per il primo, ppp1 per il secondo e via dicendo.
A livello di firewalling si devono quindi considerare diversi aspetti:
- deve essere abilitato il traffico, nella catena di FORWARD, fra la rete interna del firewall e queste interfacce pppX. Ovviamente si possono configurare le limitazioni che servono (accesso solo a determinati host interni ecc.).
- L'interfaccia esterna del vpn server deve permettere l'accesso, dall'IP del client, alla porta tcp 1723 (per l'autenticazione) e il protocollo di trasporto GRE (ip type 47) per il tunnel.
- L'ip forwarding deve essere abilitato sul kernel.

Un esempio essenziale di configurazione delle iptables su un VPN server dove eth0 è l'interfaccia interna e l'eth1 è quella esterna può essere (qui vengono previsti solo due collegamenti ppp contemporanei):
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -p tcp --dport 1723 -i eth1 -j ACCEPT
-A INPUT -p gre -i eth1 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A FORWARD -i eth0 -j ACCEPT
-A FORWARD -i ppp0 -j ACCEPT
-A FORWARD -i ppp1 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
COMMIT

In genere, per qualsiasi VPN server che per natura deve essere accessbile da arbitrari IP esterni e avere una interfaccia su una rete interna, non è il massimo avere le porte su cui si negozia il tunnel sempre accessibili. Al riguardo valutare soluzioni di port knocking che aprano la possibilità di accedere solo a determinate condizioni.

VPN ipsec roadwarrior - Racoon

In questo infobox verra' illustrato come configurare una vpn roadwarrior utilizzando l'implementazione nativa dello stack ipsec nel kernel Linux ed il demone IKE Racoon.    
Con il termine roadwarior si indica una situazione particolare di VPN, dove ad un estremo del tunnel si abbiano client con un indirizzo IP dinamico, e quindi non noto a priori.      
In particolare l'esempio riportato riguarda la configurazione di una vpn dal mio pc di casa verso un terminatore vpn basato su openswan, la cui configurazione non verra' trattata in questo infobox.      
Sono consapevole che la configurazione proposta sia comunque ampiamente migliorabile, l'intenzione e' solo quella di condividere senza voler spacciae nulla per soluzione definitiva.    
Ovviamente le chiavi e gli indirizzi IP utilizzati  sono state cambiate rispetto alla configurazione reale attualmente in uso.    

In particolare i dettagli della parametri utilizzati per la configurazione sono i seguenti:    

- Indirizzo IP locale: 192.168.1.101    
- Indirizzo IP Gateway remoto: 217.39.121.37    
- Encryption domain lcale: 172.16.108.88/32    
- Encryption domain remoto: 10.0.0.0/8    
- Metodo autenticazione: chiave RSA    
- Parametri Fase 1 IKE    
    Algoritmo cifratura: 3DES    
    Algoritmo hashing: MD5    
    Diffie Hellman Group: Group 5 (modp 1536)    
- Parametri Fase 2 IKE    
    Algoritmo cifratura: 3DES    
   Algoritmo hashing: MD5    
           
Utilizzando il supporto nativo del kernel per ipsec non e' necessario applicare  patch o compilare alcun modulo, ma e' sufficiente installare i pacchetti racoon ed ipsec-tools:    

apt-get install ipsec-tools racoon    

Il file di configurazione principale e' /etc/racoon/racoon.conf dove andranno definiti i diversi parametri della vpn e le direttive per il demone IKE:    

path certificate: la directory dove racoon dovra' cercare i certificati o le chiavi rsa utilizzate per l'autenticazione    
path pre_shared_key: specifica il file dove sono definite le preshared key utilizzate per le diverse vpn. Non utilizzando una preshared key per la vpn in oggetto ometteremo questa direttiva.    
  
path certificate "/etc/racoon";    
    
listen: specifica le porte sulle quali racoon dovra' stare in ascolto. Poiche' per la mia macchina linux si trova dietro ad un router-firewall che esegue un source nat sui pacchetti provenienti dalla mia lan e' importante specificare che racoon stia in ascolto anche sulla porta 4500 in modo che possa essere utilizzata per un eventuale nat-traversal. Le due keyword per indicare le porte su cui stare in ascolto sono isakmp ed isakmp_natt.      
Come si puo' notare dalle seguenti linee del file di configurazione oltre alle porte viene indicato anche l'indirizzo IP dove il demone dovra' stare in ascolto.    
Se non si specifica alcuna direttiva listen racoon stara' in ascolto su tutte le interfacce disponibili. Utilizzando pero' la funzionalita' di nat-traversal e' necessario specificare l'indirizzo sul quale saranno in ascolto le porte:    
  
listen {    
       isakmp 192.168.1.101 [500];    
       isakmp_natt 192.168.1.101 [4500];    
        }    
    
La direttiva remote specifica invece i parametri per la fase 1 IKE. Nel caso in oggetto e' stato indicato l'indirizzo IP pubblico del terminatore vpn al quale si desidera connettersi. Se anziche' un indirizzo si fosse specificato la keyword anonymous i parametri indicati sarebbero stati utilizzati da qualsiasi peer che non avesse match con altre direttive remote piu' specifiche.    
  
remote 217.39.121.37      
        {    
        exchange_mode main;    
        nat_traversal on;    
        my_identifier fqdn "stargazer.homelinux.org";    
        certificate_type plain_rsa "/etc/racoon/privkey.txt";    
        peers_certfile plain_rsa "/etc/racoon/peers.pub";    
        proposal      
                {    
                encryption_algorithm 3des;    
                hash_algorithm md5;    
                authentication_method rsasig;    
                dh_group 5;    
                }    
        }    
    
All'interno della direttiva remote sono state inserite. le seguenti opzioni:    

exchange_mode: definisce l'exchange mode per la fase 1 della negoziazione    
nat_traversal: abilita l'uso della funzionalita' NAT-Traversal. Essendo la mia macchina linux dietro ad un sistema che effettua un source nat dei pacchetti ho abilitato la direttiva in oggetto. In questo modo in presenza di nat i pacchetti per una data connessione possono essere incapsulati in pacchetti udp utilizzando la porta 4500.      
my_identifier: specifica il vpn identifier da inviare al terminatore remoto durante la fase uno della negoziazione. Possono essere utilizzati diversi identifier come ad esempio un indirizzo IP (ovviamente non nel mio caso avendo un ip dinamico), un fqdn od un indirizzo email. Disponendo di un fqdn registrato tramite un servizio di dns dinamico ho utilizzato quello come id.      
Se avessimo voluto utilizzare un indirizzo email sarebbe stato necessario specificare la linea my_identifier user_fqdn [email protected] .    
Naturalmente all'altro capo della vpn dovra' essere specificato il medesimo identifier per la nostra vpn.    
certificate_type: specifica il tipo di autenticazione se basata su un certificato x509 o una coppia di chiavi RSA. Nell'esempio e' stata utilizata l'autenticazione RSA, senza ricorrere ai certificati.    
La direttiva specifica inoltre il file dove e' presente la mia chiave privata (/etc/racoon/privkey.txt).    
La chiave rsa puo' essere generata con il seguente comando:    

plainrsa-gen -b 2048 > /etc/racoon/privkey.txt    

L'opzione -b specifica la lunghezza della chiave, mentre il redirect e' stato utilizzato per scrivere la chiave all'interno del file anziche' stamparlo a video.    
Ovviamente In caso l'autenticazione sia basata su una preshared key questa parte della configurazione  non dovrebbe essere necessaria.    

peers_certfile: specifica il file contenente la chiave pubblica del terminatore vpn, nel mio caso /etc/racoon/peers.pub, che e' cosi' costituito:    

: PUB 0sAQPXaEfwDo7nYwL7GLsq8EgN0UkhEGsQfGGHFs/DjTUjORFzsbDOJEFAeYu49GTjoslzNgMOq1VOAPEjZJKjrvHAx5M5XRM6N3HWmJhlQ8/FRgi6iwbyt+HrmONitb/CeKCyy7FbtF1pEYey208XZ+L9LgSmKcBl5x4BfIvJMss0yWWVd/9cq8q5I5zmckSsdGZa44oLpCyVoWylf5gCTu7zYUca6K2J2os5D7bnN1kMUAf6TwFt0b3G5KcKSXE2jb4ZCGshbgWT8O39Nfz0Wl7MNDtyoN6y+xuB5+MVOidWYzmK5RNbLM1UWP5nz3NFjJnpE9z6IWytWqJoPO/0rXiv    
    
La parte successiva alla stringa ": PUB" e' appunto la chiave RSA pubblica del terminatore vpn al quale ci si vuole connettere.    

proposal: definisce i parametri da utilizzare nella fase 1 della negoziazione, ovvero algoritmo di cifratura (encryption_algorithm), algoritmo di hashing (hash_algorithm), metodo di autenticazione (authentication_method) e l'IKE Diffie-Hellmann group (dh_group).    
Inoltre, utilizzando le chiavi rsa per l'autenticazione l'opzione authentication_method e' stata impostata come rsasig.    

Una seconda direttiva fondamentale per la configurazione della vpn e' sainfo che specifica invece i parametri per la fase 2 della negoziazione IKE. Anche in questo caso, come per la direttiva remote, e' possibile specificare il valore anonymous opure essere piu' specifici indicando gli indirizzi coinvolti.    
In particolare sono stati indicati i due encryption domain locale (172.16.108.88/32) e remoto (10.0.0.0/8).      
  
sainfo address 172.16.108.88/32 any address 10.0.0.0/8 any    
        {            
        encryption_algorithm 3des;    
        authentication_algorithm hmac_md5;    
        compression_algorithm deflate;    
        }    
    
Come per la parte di configurazione relativa alla fase uno, anche per la fase due sono stati specificati gli stessi algoritmi di cifratura ed autenticazione utilizzati per la fase due dal terminatore vpn.    

Ricapitolando, il file di configurazione /etc/racoon.conf e' il seguente:    
  
path certificate "/etc/racoon";    

listen {    
       isakmp 192.168.1.101 [500];    
       isakmp_natt 192.168.1.101 [4500];    
        }    

remote 217.39.121.37      
        {    
        exchange_mode main;    
        nat_traversal on;    
        my_identifier fqdn "stargazer.homelinux.org";    
        certificate_type plain_rsa "/etc/racoon/privkey.txt";    
        peers_certfile plain_rsa "/etc/racoon/peers.pub";    
        proposal      
                {    
                encryption_algorithm 3des;    
                hash_algorithm md5;    
                authentication_method rsasig;    
                dh_group 5;    
                }    
        }    

sainfo address 172.16.108.88/32 any address 10.0.0.0/8 any    
        {            
        encryption_algorithm 3des;    
        authentication_algorithm hmac_md5;    
        compression_algorithm deflate;    
        }    
    
A questo punto racoon puo' essere avviato con il comando /etc/init.d/racoon start oppure, in caso sia necessario fare un po' di debug con racon -F -f /etc/racoon.conf -dddd.      
L'opzione -f indica il file di configurazione di racoon, -F permette di eseguire il software in foreground, mentre -d definisce il livello di debug. Argomenti -d multipli consentono di incrementare il livello di debug.    
Trattandosi del primo avvio e' preferibile lanciare racoon in foreground poiche' e' molto probabile che si sia commesso qualche errore nei file di configurazione, ed in questo modo sara' possibile identificarlo con maggiore facilita'.    

Una volta avviato racoon, e' necessario caricare le policies relative alla vpn tramite il comando setkey.    
setkey legge i suoi comandi da un file di testo quando invocato con una linea di comando del tipo setkey -f file.conf.In particolare, nella configurazione proposta, le security association sono state definite nel file /etc/setkey.conf:    
  
#!/usr/sbin/setkey -f    
#    
# Flush SAD and SPD    
flush;    
spdflush;    
# Create policies for racoon    

spdadd 172.16.108.88/32 10.0.0.0/8 any -P out ipsec    
           esp/tunnel/192.168.1.101-217.39.121.37/require;    
spdadd 10.0.0.0/8 172.16.108.88/32 any -P in ipsec    
           esp/tunnel/217.39.121.37-192.168.1.101/require;    
    
Per semplificare il caricamento delle policy e' stata inserita la linea #!/usr/sbin/setkey -f in testa al file /etc/racoon/setkey.conf ed assegnato il permesso di esecuzione chmod u+x /etc/racoon/setkey.conf. In questo modo e' possibile effettuare il caricamento delle policy semplicemente dando il comando /etc/racoon/setkey.conf.    
Una volta caricate le policies dovrebbe essere sufficiente pingare un indirizzo IP dell'encryption domain remoto (ad esempio il 10.26.182.2) perche' venga instaurato il tunnel ipsec. Se tutto e' stato configurato correttamente la rete collegata al terminatore vpn remoto dovrebbe ora essere raggiungibile.    
In realta' e' necessaria ancora un'ultima operazione, dovuta al fatto che nella configurazione della vpn l'encryption domain locale corrisponde all'indirizzo IP 172.16.108.88 mentre l'indirizzo della mia macchina e' 192.168.1.101.      
Poiche' e' necessario che i pacchetti inviati dalla macchina abbiano un indirizzo IP sorgente corrispondente all'encryption domain locale deve essere creata una regola tramite iptables per effettuare un source nat dei pacchetti diretti alla rete 10.0.0.0/8 in modo che essi possano apparire come provenienti dal 172.16.108.88:    
  
iptables -t nat -A POSTROUTING -d 10.0.0.0/8 -j SNAT --to-source 172.16.108.88    
    
Una volta testato il tutto e verificato che funzioni correttamente si puo' utilizzare uno shellscript come il seguente che provveda ad avviare racoon, caricare le policies ed effettuare il source nat dei pacchetti:    
  
#!/bin/bash    
/etc/init.d/racoon start    
iptables -t nat -F    
iptables -t nat -A POSTROUTING -d 10.0.0.0/8 -j SNAT --to-source 172.16.108.88    
/etc/racoon/setkey.conf