IPSEC con Debian GNU/Linux

IPSEC - su una distribuzione Debian moderna - si basa sui servizi Setkey e Racoon, questi servizi si avviano con systemd.

Configuriamo ad esempio una VPN con nome static-psk-test, con indirizzi IP statici e pre-shared key. Gli indirizzi IP privati e pubblici in questione sono:

(LAN 192.168.10.0/24) → (Firewall 5.10.168.170) ↔ (Firewall 5.20.195.220) ← (LAN 192.168.20.0/24)

In generale i file di configurazione sono questi (si esamina il firewall 5.10.168.170):

/etc/ipsec-tools.d/static-psk-test.conf

spdadd 192.168.10.0/24  192.168.20.0/24  any -P out ipsec esp/tunnel/5.10.168.170-5.20.195.220/unique;
spdadd 192.168.20.0/24  192.168.10.0/24  any -P in  ipsec esp/tunnel/5.20.195.220-5.10.168.170/unique;

/etc/racoon/racoon.conf

include "/etc/racoon/static-psk-test.conf";

/etc/racoon/static-psk-test.conf

remote 5.20.195.220 {
    exchange_mode main;
    proposal {
        encryption_algorithm 3des;
        hash_algorithm md5;
        authentication_method pre_shared_key;
        dh_group modp1024;
    }
    # Verifica l'identita' del peer su psk.txt con l'indirizzo IP.
    peers_identifier address "5.20.195.220";
    verify_identifier on;
    initial_contact on;
    lifetime time 86400 seconds;
    #proposal_check obey;
    #nat_traversal on;
}

sainfo address 192.168.10.0/24 any address 192.168.20.0/24 any {
    encryption_algorithm 3des;
    authentication_algorithm hmac_md5,hmac_sha1;
    compression_algorithm deflate;
    lifetime time 43200 seconds;
}

NOTA: Se non si usa l'opzione proposal_check obey è necessario impostare le stesse identiche opzioni tra le due parti, compresi i lifetime time, ecc., altrimenti la connessione fallisce. Per effettuare il debug dei parametri non corrispondenti è necessario impostare almeno log debug in /etc/racoon/racoon.conf.

/etc/racoon/psk.txt

5.20.195.220    nai5Ohmo

Per fermare e riavviare il servizio:

systemctl stop racoon
systemctl stop setkey

systemctl start setkey
systemctl start racoon

Il traffico IPSEC va ovviamente gestito in maniera opportuna poiché non corrisponde al criterio standard MASQUERADE di iptables. Ad esempio Shorewall ha delle direttive apposite per gestire IPSEC.

In generale si potrà testare la VPN con un ping, a patto di usare gli indirizzi IP sul lato LAN:

ping -I 192.168.10.254 192.168.20.1

Sull'host che deve negoziare IPSEC bisogna aprire la porta 500 UDP (protocollo isakmp).

Disponibile nel kernel 2.6.x e backported nei sorgenti kernel di Debian dalla versione 2.4.21. Dovrebbe essere il default di Debian, più giovane ma di qualità. Per usare questa API con FreeS/WAN bisogna usare una versione 2.01 o successiva di FreeS/WAN, ed applicarci delle patch.

Se nei sorgenti del kernel erano state applicate le kernel-patch-freeswan, reinstallare i sorgenti. Per compilare KAME si devono attivare le opzioni:

Componente user-space di IPSEC che utilizza la nuova API del kernel (KAME). E' alternativo a Pluto di FreS/WAN e per fortuna esiste nei backports per Debian Woody: pacchetti ipsec-tools e racoon.

Implementazione originale di IPSec per Linux, adesso è un'alternativa allo stack IPSec nativo del kernel. Ci sono due modi per averlo: installare il pacchetto freeswan-modules-source (poi con make-kpkg si ottiene un pacchetto di moduli), oppure si installa kernel-patch-freeswan e quindi il supporto IPSec è monolitico. Il vantaggio di quest'ultimo modo è quello di supportare il NAT Traversal. Entrambi i pacchetti sono disponibili nei backports.

Contenuto nel pacchetto backports per Debian Woody freeswan_2.04-6. Pare che possa usare indistintamente il il supporto modulare di freeswan-modules-source, il supporto alternativo di kernel-patch-freeswan oppure il supporto nativo del kernel (ma bisogna applicare le patch).

Se si vuole usare la nuova architettura IPSEC fornita dal kernel 2.6.x. Lavorando su Debian Woody si deve tener presente:

1. Compilare il kernel 2.4.27 dai sorgenti Debian, in modo da avere le patch IPSEC importate dal ramo 2.6.x.
2. Installare i pacchetti ipsec-tools e racoon dai Debian backport: http://www.backports.org/
3. In Debian si può scegliere tra due modi diversi di configurare racoon: direct e racoon-tool. Nel primo caso si edita direttamente il file /etc/racoon/racoon.conf, nel secondo si edita /etc/racoon/racoon-tool.conf. In teoria il secondo modo dovrebbe essere più user-friendly, ma ovviamente si sceglie il primo (mettendo CONFIG_MODE=“direct” in /etc/default/racoon).

Installare i pacchetti ipsec-tools e racoon. Si sceglie il modo di configurazione tradizionale (direct) che prevede di editare direttamente /etc/racoon/racoon.conf, queste sono le caratteristiche:

The traditional one (direct), which is for direct editing of /etc/racoon/racoon.conf
and setup of the SPD using setkey via a shell script written by the systems administrator.
You will have to make sure that the kernel has all required modules loaded or the
racoon daemon can exit with a 'failed to parse configuration file' error.

Installare i pacchetti ipsec-tools e racoon. Si sceglie il modo di configurazione direct che prevede di editare direttamente /etc/racoon/racoon.conf e /etc/ipsec-tools.conf.

Il metodo con racoon-tool è deprecato.

Esempio di /etc/ipsec-tools.conf:

spdadd -4n 10.0.0.0/24[any]     192.168.21.0/24[any] any -P out ipsec esp/tunnel/178.236.171.186-95.241.47.37/require;
spdadd -4n 192.168.21.0/24[any] 10.0.0.0/24[any]     any -P in  ipsec esp/tunnel/95.241.47.37-178.236.171.186/require;

Il senso dei parametri è il seguente:

spdadd -4n _local_net_ _remote_net_ any -P out ipsec esp/tunnel/_local_ip_-_remote_ip_/require

Per debuggare la fase iniziale tcpdump può dare diverse informazioni:

tcpdump -s0 -vvvv -ni eth0 'port 500'

In /etc/racoon/racoon.conf (per chi usa il metodo direct) è possibile mettere:

#log notify;
log debug;

che corrisponde a mettere in /etc/racoon/racoon-tool.conf (per chi usa il deprecato metodo racoon-tool) :

global:
    log: notify
    #log: debug

Un ping dal firewall IPSEC verso un host remoto (10.51.49.130) funziona solo se si imposta come origine l'indirizzo IP sulla LAN (192.168.100.1):

# ping -I 192.168.100.1 10.51.49.130
PING 10.51.49.130 (10.51.49.130) from 192.168.100.1 : 56(84) bytes of data.
64 bytes from 10.51.49.130: icmp_req=1 ttl=127 time=58.7 ms
64 bytes from 10.51.49.130: icmp_req=2 ttl=127 time=59.4 ms

Con tcpdump sull'interfaccia locale (eth1) è possibile vedere un ping che parte da un client locale (192.168.100.46) e la risposta che arriva dal client remoto (10.51.49.130):

# tcpdump -i eth1 -n 'icmp and host 192.168.100.46'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
17:52:49.931173 IP 192.168.100.46 > 10.51.49.130: ICMP echo request, id 5236, seq 1, length 64
17:52:50.259728 IP 10.51.49.130 > 192.168.100.46: ICMP echo reply, id 5236, seq 1, length 64
17:52:50.931684 IP 192.168.100.46 > 10.51.49.130: ICMP echo request, id 5236, seq 2, length 64
17:52:51.261197 IP 10.51.49.130 > 192.168.100.46: ICMP echo reply, id 5236, seq 2, length 64

Sull'interfaccia pubblica (eth0) invece si vede solo il pacchetto di ritorno:

# tcpdump -i eth0 -n 'icmp and host 192.168.100.46'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:53:42.153700 IP 10.51.49.130 > 192.168.100.46: ICMP echo reply, id 5237, seq 1, length 64
17:53:43.153685 IP 10.51.49.130 > 192.168.100.46: ICMP echo reply, id 5237, seq 2, length 64

Tipica configurazione per un router DrayTek Vigor. Avendo l'IP fisso si può usare il main mode che consente complete security during the establishment of an IPSec connection. Invece di scrivere direttamente in /etc/racoon/racoon.conf conviene utilizzare la direttiva include e creare un file di configurazione a parte, ad esempio /etc/racoon/static-ip_lan_psk.conf:

#-------------------------------------------------------------------------
# Remote host with static IP, identified by IP and PSK.
# Routing between local and remote LAN.
#-------------------------------------------------------------------------
remote 217.19.150.87 {
    exchange_mode main;
    proposal {
        encryption_algorithm 3des;
        hash_algorithm md5;
        authentication_method pre_shared_key;
        dh_group modp768;
    }

    # Verifica l'identita' del peer su /etc/racoon/psk.txt con l'indirizzo IP.
    peers_identifier address "217.19.150.87";
    verify_identifier on;

    # Aspetta il remoto, aggiungi la policy appena si presenta.
    passive on;
    generate_policy on;
}

sainfo address 10.0.1.0/24 any address 192.168.21.0/24 any {
    encryption_algorithm 3des;
    authentication_algorithm hmac_md5;
    compression_algorithm deflate;
}

La rete 10.0.1.0/24 è quella locale rispetto all'host GNU/Linux, la 192.168.21.0/24 è la LAN dal lato DrayTek.

Verificare i parametri (soprattutto hash_algorithm e dh_group usati nel proposal), devono coincidere con quelli dell'host remoto.

La sintassi del file è spiegata nel man racoon.conf. Poi si fa un restart (reload?) del servizio racoon e nel syslog si dovrebbe vedere qualcosa del genere:

racoon: INFO: respond new phase 1 negotiation: 217.19.150.8[500]<=>217.19.150.87[500]
racoon: INFO: begin Identity Protection mode.
racoon: INFO: ISAKMP-SA established 217.19.150.8[500]-217.19.150.87[500] spi:aad56ab55aadd66b:c4b16f7ca6fd2a17
racoon: INFO: respond new phase 2 negotiation: 217.19.150.8[500]<=>217.19.150.87[500]
racoon: INFO: no policy found, try to generate the policy : 192.168.21.0/24[0] 10.0.1.0/24[0] proto=any dir=in
racoon: INFO: IPsec-SA established: ESP/Tunnel 217.19.150.87[500]->217.19.150.8[500] spi=55797743(0x35367ef)
racoon: INFO: IPsec-SA established: ESP/Tunnel 217.19.150.8[500]->217.19.150.87[500] spi=3128290263(0xba75ebd7)
racoon: ERROR: such policy does not already exist: 192.168.21.0/24[0] 10.0.1.0/24[0] proto=any dir=in
racoon: ERROR: such policy does not already exist: 192.168.21.0/24[0] 10.0.1.0/24[0] proto=any dir=fwd
racoon: ERROR: such policy does not already exist: 10.0.1.0/24[0] 192.168.21.0/24[0] proto=any dir=out

Per vedere che il tunnel è venuto su si verifica che esistano due Security Association (per criptare i pacchetti in arrivo e in uscita) e le tre Security Policy (per instradare i pacchetti IN, OUT e FWD).

Quando la connessione viene stabilita vengono create due Security Association, queste servono per decidere come trattare i pacchetti IPSec in ingresso e in uscita (chiavi, algoritmi, policy, …). La SA da usare viene scelta in base a tre parametri:

• Partner IP address
• IPSec Protocol (ESP or AH)
• Security Parameters Index

Le Security Association vengono negoziate con il protocollo ISAKMP dal demone racoon. In teoria si potrebbero creare manualmente con setkey. Per vedere il database delle SA esistenti (il SAD):

# setkey -D
217.19.150.87 217.19.150.8
        esp mode=tunnel spi=55797743(0x035367ef) reqid=0(0x00000000)
        E: 3des-cbc  ea33d53c c62508f2 a06dfa27 e05af959 bda2be7f 7a0535be
        A: hmac-md5  164c15f9 c53d8bb6 32bbcfa2 d0ed9850
        seq=0x00000000 replay=4 flags=0x00000000 state=mature
        created: Aug 26 11:39:45 2005   current: Aug 26 11:54:57 2005
        diff: 912(s)    hard: 3600(s)   soft: 2880(s)
        last: Aug 26 11:39:50 2005      hard: 0(s)      soft: 0(s)
        current: 72902(bytes)   hard: 0(bytes)  soft: 0(bytes)
        allocated: 171  hard: 0 soft: 0
        sadb_seq=1 pid=1014 refcnt=0
217.19.150.8 217.19.150.87
        esp mode=tunnel spi=3128290263(0xba75ebd7) reqid=0(0x00000000)
        E: 3des-cbc  d1c79db5 79ac8223 a87e75b1 4c87b163 e236a976 70b45956
        A: hmac-md5  daeab81b 5462c2e9 1d9615f9 0442ed16
        seq=0x00000000 replay=4 flags=0x00000000 state=mature
        created: Aug 26 11:39:45 2005   current: Aug 26 11:54:57 2005
        diff: 912(s)    hard: 3600(s)   soft: 2880(s)
        last:                           hard: 0(s)      soft: 0(s)
        current: 0(bytes)       hard: 0(bytes)  soft: 0(bytes)
        allocated: 0    hard: 0 soft: 0
        sadb_seq=0 pid=1014 refcnt=0

Quando la connessione viene stabilita vengono create tre Security Policy: in, out e fwd. Queste regole indicano quali pacchetti devono essere elaborati con IPSEC. Per vedere il database delle SP (il SPD):

# setkey -D -P
192.168.21.0/24[any] 10.0.1.0/24[any] any
        in ipsec
        esp/tunnel/217.19.150.87-217.19.150.8/require
        created: Sep  8 10:33:10 2005  lastused:
        lifetime: 3600(s) validtime: 0(s)
        spid=11168 seq=72 pid=2621
        refcnt=2
10.0.1.0/24[any] 192.168.21.0/24[any] any
        out ipsec
        esp/tunnel/217.19.150.8-217.19.150.87/require
        created: Sep  8 10:33:10 2005  lastused: Sep  8 10:41:01 2005
        lifetime: 3600(s) validtime: 0(s)
        spid=11185 seq=71 pid=2621
        refcnt=4
192.168.21.0/24[any] 10.0.1.0/24[any] any
        fwd ipsec
        esp/tunnel/217.19.150.87-217.19.150.8/require
        created: Sep  8 10:33:10 2005  lastused: Sep  8 10:41:01 2005
        lifetime: 3600(s) validtime: 0(s)
        spid=11178 seq=70 pid=2621
        refcnt=4
...

In questo caso le policy vengono aggiunte automaticamente per via della direttiva generate_policy on;, hanno una lifetime automatica e dovrebbero essere rigenerate via via che arriva traffico sul tunnel. Altrimenti le policy si installano a mano, il modo più semplice è creare un file con le azioni e darlo in pasto a setkey -f <nomefile>:

spdadd -4n 192.168.15.0/24[any] 10.0.1.0/24[any] any -P in ipsec esp/tunnel/217.19.150.165-217.19.150.8/require;
spdadd -4n 10.0.1.0/24[any] 192.168.15.0/24[any] any -P out ipsec esp/tunnel/217.19.150.8-217.19.150.165/require;

La policy per il fwd viene aggiunta automaticamente. In analogia, per la rimozione:

spddelete -4n 192.168.15.0/24[any] 10.0.1.0/24[any]     any -P in;
spddelete -4n 10.0.1.0/24[any]     192.168.15.0/24[any] any -P out;

Fermare il demone racoon (che gestisce lo scambio delle chiavi) non è sufficiente a fermare il tunnel; le SA continuano ad esistere e il tunnel a funzionare. Per fermare tutto si devono usare i seguenti comandi:

/etc/init.d/racoon stop
setkey -F
setkey -F -P

In alternativa si potrebbe usare racoon-tool stop che provvede anche a scaricare i moduli kernel relativi all'IPSec (criptografia, ecc.), ma questa strategia andrebbe abbinata alla configurazione racoon-tool di Debian (vedi sopra), non alla configurazione direct (manuale).

Dopo aver distrutto le SA con setkey -F non basta riavviare racoon perché il tunnel riparta; la fase 1 non viene ripetuta finché il remoto non si accorge.

Usando un IP dinamico e la PSK è obbligatorio usare l'aggressive mode. Nel file /etc/racoon/psk.txt il client con IP dinamico viene identificato con un nome FQDN.

Il file di configurazione /etc/racoon/racoon.conf è il seguente:

#
# Global items
#
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";
log notify;
listen {
        isakmp 88.57.50.90;
        strict_address;
}

#
# Anonymous connection section
#
remote anonymous {
        proposal {
                encryption_algorithm 3des;
                hash_algorithm md5;
                authentication_method pre_shared_key;
                dh_group modp768;
        }

        passive on;
        verify_identifier on;
        proposal_check obey;
        verify_cert on;
        lifetime time 28800 seconds;
        peers_identifier fqdn "vigor.domain.net";
        generate_policy on;
        exchange_mode aggressive;
}

sainfo anonymous {
        encryption_algorithm 3des;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate;
}

La configurazione è stata provata con un router DrayTek Vigor 2700, le opzioni IPSEC necessarie sono:

• IPSec Security Method: High(ESP) 3DES with Authentication
• IKE Advanced Settings:
  • IKE phase 1 mode: Aggressive mode
  • IKE phase 1 proposal: 3DES_MD5_G1
  • IKE phase 2 proposal: 3DES_SHA1
  • Perfect Forward Secret: Enabled
  • Local ID: vigor.domain.net

ATTENZIONE: L'opzione generate_policy on implica che le policy di instradamento su IPSEC vengono generate automaticamente quando il client si connette, accettando per buone le configurazioni passate dal client. Questo è accettabile solo se il client è fidato. In particolar modo si deve fare attenzione che la network privata del client non crei conflitti con il routing locale.

ATTENZIONE: Si è riscontrato un problema con i router DrayTek.

Il file di configurazione è:

#
# Global items
#
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";
log notify;
listen {
        isakmp 217.19.150.8;
        strict_address;
}

remote 217.19.150.165 {
        proposal {
                encryption_algorithm 3des;
                hash_algorithm md5;
                authentication_method pre_shared_key;
                dh_group modp768;
        }

        passive on;
        verify_identifier on;
        proposal_check obey;
        verify_cert on;
        lifetime time 28800 seconds;
        peers_identifier address 217.19.150.165;
        exchange_mode main;
}

sainfo address 10.0.1.0/24[any] any address 192.168.15.0/24[any] any {
        encryption_algorithm 3des;
        authentication_algorithm hmac_md5;
        compression_algorithm deflate;
}

Le SPD (Security Policy Database) devono essere generate da opportune righe di configurazione in un file salvato in /etc/ipsec-tools.d/.

Con la seguente configurazione Racoon inizia la connessione verso un server remoto, ma solo quando viene rilevato del traffico destinato alla VPN. In pratica la fase 1 di isakmp non avviene immediatamente e le Security Association vengono stabilite solo quando è necessario.

Ecco cosa aggiungere (o includere) in /etc/racoon/racoon.conf:

remote 159.213.224.52 {
    exchange_mode main;
    lifetime time 21600 sec;
    proposal_check strict;
    proposal {
        encryption_algorithm 3des;
        #hash_algorithm md5;
        hash_algorithm sha1;
        authentication_method pre_shared_key;
        # For aggressive mode, it must be the same on both ends.
        dh_group 2;
    }
    # Verifica l'identita' del peer su /etc/racoon/psk.txt con l'indirizzo IP.
    peers_identifier address "159.213.224.52";
}

sainfo address 192.168.3.0/24 any address 10.0.1.0/24 any {
    lifetime time 3600 sec;
    encryption_algorithm 3des, aes 128;
    authentication_algorithm hmac_sha1, hmac_md5;
    compression_algorithm deflate;
}

In questo caso bisogna configurare esplicitamente le Security Policy (aggiungendole con il comando spdadd di setkey(8)) che verranno usate per instradare il traffico VPN. È anche necessario indicare nelle SP il tunnel da attivare, identificandolo con gli indirizzi IP delle due estremità. In questo modo - appena viene rilevato un pacchetto che combacia con una SP - è possibile risalire all'host remoto con cui iniziare la fase 1.

In Debian lo script /etc/init.d/setkey provvede a caricare le Security Policy, dopo che si è impostato in /etc/default/setkey la variabile RUN_SETKEY=yes.

Si crea la directory /etc/ipsec-tools.d/ e vi si mette un file per ogni VPN, ad esempio vpn_example.conf. Per ogni rete remota raggiungibile tramite tale VPN occorrono due SP:

spdadd 192.168.3.0/24 10.0.1.0/24    any -P out ipsec esp/tunnel/82.193.30.18-159.213.224.52/unique;
spdadd 10.0.1.0/24    192.168.3.0/24 any -P in  ipsec esp/tunnel/159.213.224.52-82.193.30.18/unique;

Se il cliente/initiator non ha un IP pubblico, ma sta dietro il NAT di un router, occorrono alcuni aggiustamenti alla configurazione.

L'indirizzo del client è 10.0.1.2 (IP privato, dietro NAT), il server ha indirizzo 82.63.172.2, la PSK è associata a tale IP in /etc/racoon/psk.txt, la rete privata da raggiungere presso il server è 192.168.100.0/24.

listen {
        isakmp 10.0.1.2;
        isakmp_natt 10.0.1.2 [4500];
        strict_address;
}

remote 82.63.172.2 {
        nat_traversal on;
        exchange_mode aggressive;
        my_identifier fqdn "vpn.nat-client.net";
        # Verifica l'identita' del peer su /etc/racoon/psk.txt con l'indirizzo IP.
        peers_identifier address "82.63.172.2";
        lifetime time 21600 sec;
        proposal_check strict;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm md5;
                authentication_method pre_shared_key;
                # For aggressive mode, it must be the same on both ends.
                dh_group modp1024;
        }
}

sainfo address 10.0.1.0/24 any address 192.168.100.0/24 any {
        pfs_group modp1024;
        lifetime time 12 hour;
        encryption_algorithm 3des, blowfish, des, rijndael;
        authentication_algorithm hmac_sha1, hmac_md5;
        compression_algorithm deflate;
}

Nel file /etc/ipsec-tools.d/82.63.172.2.conf si mette:

spdadd 10.0.1.0/24       192.168.100.0/24  any -P out ipsec esp/tunnel/10.0.1.2-82.63.172.2/unique;
spdadd 192.168.100.0/24  10.0.1.0/24       any -P in  ipsec esp/tunnel/82.63.172.2-10.0.1.2/unique;

Shorewall ha via via migliorato il supporto ad IPSEC, nella versione 4 è relativamente semplice gestire il traffico IPSEC.

Senza supporto IPSEC da parte di Shorewall i pacchetti della VPN vengono bloccati. Ad esempio se eth2 è l'interfaccia NET e eth0 quella LAN, i pacchetti in arrivo sono filtrati:

Shorewall:rfc1918:DROP:IN=eth2 OUT=eth0 SRC=192.168.21.10 DST=10.0.1.113 ...

Un fix orribile potrebbe essere questo (da aggiungere ad esempio in /etc/shorewall/start):

iptables -I FORWARD -s 192.168.21.10 -d 10.0.1.113 -j ACCEPT

Si deve accettare il traffico IKE (porta 500 UDP) e il protocollo ESP (scambio dati). In /etc/shorewall/rules:

ACCEPT    all    fw    udp    isakmp    # IPSEC, key negotiation.
ACCEPT    all    fw    esp              # IPSEC, ESP protocol.

Nel file /etc/shorewall/tunnels si dichiara che esiste un tunnel IPSEC, raggiungibile tramite la zona internet e l'indirizzo IP remoto indicato:

ipsec    net    213.225.215.114    # Tunnel sede remota.

Se l'indirizo remoto non è conosciuto oppure è dinamico:

ipsec    net    0.0.0.0/0          # Tunnel con road warrior (IP dinamico).

Infine nel file /etc/shorewall/hosts si dichiara una zona (di nome sec in questo esempio) che comprende le reti remote raggiungibili tramite IPSEC. È necessario indicare l'interfaccia di uscita e l'indirizzo IP pubblico remoto (se conosciuto e statico):

sec     eth2:192.168.10.0/24,213.225.215.114  ipsec   # LAN sede remota, via tunnel IPSEC.

La zona deve ovviamente essere dichiarata in /etc/shorewall/zones:

sec     ipv4

A qeusto punto la zona sec e gli host contenuti in essa possono essere gestiti normalmente in /etc/shorewall/policy e /etc/shorewall/rules, ecco due policy particolarmente permissive (dove loc è la zona associata alla LAN):

loc     sec     ACCEPT
sec     loc     ACCEPT

Si può utilizzare l'indirizzo IP locale del firewall IPSEC (192.168.100.1) per mascherare tutta la rete locale (192.168.100.0/24) che esce verso la rete privata remota (10.51.49.128/26) via IPSEC, basta aggiungere la seguente regola in /etc/shorewall/masq:

eth0                  192.168.100.0/24                            # LAN to internet.
eth0:10.51.49.128/26  192.168.100.0/24  192.168.100.1  -  -  yes  # LAN to IPSEC gateway.

Questo si traduce nelle seguenti regole iptables:

MASQUERADE  all  --  192.168.100.0/24  0.0.0.0/0        policy match dir out pol none
SNAT        all  --  192.168.100.0/24  10.51.49.128/26  policy match dir out pol ipsec to:192.168.100.1

With Perfect Forward Secrecy the exposure of one key permits access only to data protected by that key. HP-UX IPSec supports PFS for keys and identities (the IKE daemon can be configured to create a new ISAKMP/MM SA for each IPSec/QM negotiation). HP-UX IPSec does not support PFS for keys only (the ISAKMP/MM SA is re-used for multiple IPSec/QM negotiations, with a new Diffie-Hellman key exchange for each IPSec/QM negotiation).
From http://docs.hp.com/en/J4256-90005/go01.html.

Before using an IPSEC connection we must estabilish a Security Association (IPsec-SA) between the peers. The IPsec-SA is automatically estabilished by the racoon daemon using the IKE protocol. During phase 1 of IKE, some IKE-SA are estabilished first, then using that SA, the final IPsec-SA is estabilished.

Into racoon.conf configuration file, the remote directive controls phase 1, where sainfo directive controls phase 2.
See http://www.kame.net/newsletter/20001119/.

Kernel refers to Security Policy Database (SPD) in order to decide whether to apply IPsec to a packet or not. Also SPD entries specify which/how IPsec-SA is applied. Security Association Database (SAD) entries contain Key of each IPsec-SA. Kernel can ask racoon to negotiate a new key if the one in the SAD is expired or does not yet exists.

Both IKE-SA and IPsec-SA have a lifetime limit, when expired the key must be renegotiated between the peers.