This is an old revision of the document!
Table of Contents
IPSEC con Debian GNU/Linux
Pezzi di IPSEC per Linux
Sull'host che deve negoziare IPSEC bisogna aprire la porta 500 UDP (protocollo isakmp).
IPSec stack kernel native (KAME)
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:
Configurazione | Modulo kernel |
---|---|
CONFIG_NET_KEY | af_key.o |
CONFIG_INET_AH | ah4.o |
CONFIG_INET_ESP | esp4.o |
CONFIG_XFRM | xfrm_* |
CONFIG_XFRM_USER | xfrm_user.o |
IPSec utilities ipsec-tools e racoon
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.
FreeS/WAN kernel code (KLIPS)
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.
FreeS/WAN pluto key management daemon
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).
Backport su Debian Woody
Se si vuole usare la nuova architettura IPSEC fornita dal kernel 2.6.x. Lavorando su Debian Woody si deve tener presente:
- Compilare il kernel 2.4.27 dai sorgenti Debian, in modo da avere le patch IPSEC importate dal ramo 2.6.x.
- Installare i pacchetti ipsec-tools e racoon dai Debian backport: http://www.backports.org/
- 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 (mettendoCONFIG_MODE=“direct”
in/etc/default/racoon
).
Installazione su Debian Sarge
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.
File di configurazione da salvare |
---|
/etc/default/racoon |
/etc/racoon/racoon.conf |
/etc/racoon/psk.txt |
Installazione su Debian Squeeze
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.
File da salvare | |
---|---|
/etc/racoon/racoon.conf | File principale di configurazione. |
/etc/ipsec-tools.conf | Configurazione delle SPD tramite setkey. |
/etc/racoon/psk.txt | Pre Shared Keys. |
/etc/racoon/*.conf | Eventuali file inclusi dal racoon.conf . |
/etc/default/setkey | RUN_SETKEY=yes |
/etc/default/racoon | CONFIG_MODE=“direct” |
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
Debug
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
Debug 2
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
Esempi di configurazione
Client con IP fisso, network remota, PSK
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).
Security Association
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
Security Policy
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 e far ripartire il tunnel
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.
Client con IP dinamico e LAN associata, PSK
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.
Client con IP statico e LAN associata, PSK (es. router DrayTek Vigor 2500/2600)
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/
.
Initiator per server passivo
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.
Indirizzi IP dell'esempio | |
---|---|
192.168.3.0/24 | LAN locale |
10.0.1.0/24 | LAN remota |
82.193.30.18 | IP pubblico locale |
159.213.224.52 | IP pubblico remoto |
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;
Initiator dietro NAT verso server passivo
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;
Configurazione firewall Shorewall
Shorewall ha via via migliorato il supporto ad IPSEC, nella versione 4 è relativamente semplice gestire il traffico IPSEC.
Configurazione legacy
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
Configurazione con Shorewall 4
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
Mascheramento (SNAT)
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
Glossario
Perfect Forward Secrecy (PFS)
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.
IKE pahse 1 and phase 2
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/.
SPD and SAD
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.
Phase 1 exchange mode
main | Lo scambio IKE avviene in 4 passaggi. E' possibile utilizzare anche una preshared key, ma l'identità del remoto deve essere provata dall'IP statico. |
---|---|
aggressive | Lo scambio IKE avviene in soli tre passaggi: proposta, risposta, OK. Più rapido e semplice, ma leggermente meno sicuro. Questo è l'unico modo utile per usare una preshared key senza identificazione certa del remoto. L'identità del remoto viene ricevuta non criptata. |
base | Bho? |
Lifetime
Both IKE-SA and IPsec-SA have a lifetime limit, when expired the key must be renegotiated between the peers.