====== IPSEC con Debian GNU/Linux ======
===== Configurazione Debian 8 Jessie =====
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 [[#configurazione_firewall_shorewall|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
===== 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 (mettendo ''CONFIG_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 **'':
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 **[[ipsec_draytek|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.