Ago 24 2009
VPN Site to Site IPSEC con Cisco ASA 5505
Scenario
Si prenda in esame un’azienda con due sedi distinte e ad una certa distanza tra loro.
In questo caso, potrebbe non essere conveniente fare una connessione dedicata tra le due sedi aziendali, per cui, è possibile sfruttare la rete Internet per interconnettere le due sedi tra di loro; in tale situazione, si pongono ovvi problemi di sicurezza, poiché i dati transitano su una rete pubblica, e sono quindi tranquillamente sniffabili da chiunque sia un po’ troppo “curioso”. Per ovviare a questi problemi, è necessario criptare il traffico di rete fra le due sedi aziendali, anche se questo comporta un leggero calo delle prestazioni: tutte queste caratteristiche sono comprese in un tipo di connessione chiamato VPN (Virtual Private Network), che, come dice il nome, stabilisce un canale privato virtuale (tunnel) sulla rete pubblica (Internet).
Una VPN può essere di diversi tipi, in questa situazione, dovendo interconnettere tra loro due intere reti LAN distinte tra di loro, la VPN prende il nome di “site to site”; inoltre, una VPN può essere realizzata con diversi protocolli, in questo caso, utilizzeremo il protocollo IPSEC con due firewall Cisco ASA 5505 in un ambiente di test.
Ambiente di test
Per simulare la situazione prospettata nello scenario, ho creato un piccolo ambiente di test con due firewall Cisco ASA 5505, in cui, nella parte LAN, è collegato un notebook su entrambi i lati per simulare le due reti LAN (rispettivamente, LAN1 – 192.168.1.0/24 e LAN2 – 192.168.2.0/24), mentre la rete Internet è simulata utilizzando uno switch HP 1700-8, a cui sono collegate le due interfacce WAN (WAN1 – 172.16.3.1/24 e WAN2 – 172.16.3.2) del firewall. I due firewall prendono il nome rispettivamente di ASA-1 e ASA-2. Queste connessioni sono mostrate nello schema di rete in Figura 1.
Figura 1 - Ambiente di test per VPN IPSEC con Cisco ASA 5505
Cenni teorici su VPN IPSEC su Cisco ASA5505
Una connessione VPN IPSEC viene instaurata tra due apparati che supportano questo tipo di VPN in cinque passaggi. Il primo passaggio, consiste nel transito di “traffico interessante” tra i due firewall Cisco, dove per traffico interessante si intende quel tipo di traffico che deve essere protetto tramite IPSEC. A questo punto, avviene una negoziazione dei due apparati Cisco, i quali, a negoziazione avvenuta, instaurano una security association (SA) tra i due lati della VPN, utilizzando il protocollo IKE (chiamato anche ISAKMP).
La negoziazione di una SA avviene in due fasi (passaggio due e tre), Phase 1 e Phase 2: la Phase 1 stabilisce un primo tunnel che protegge i successivi messaggi di negoziazione ISAKMP, mentre la Phase 2 stabilisce il secondo tunnel che si occupa della cifratura vera e propria dei dati. Durante la Phase 2 bisogna specificare un transform set, cioè il livello di protezione richiesto per la sessione IPSEC, il quale combina un metodo di protezione ed un metodo di autenticazione; è importante che i parametri impostati con un transform set siano gli stessi su entrambi gli apparati responsabili della comunicazione sicura tra le due reti.
Quando si vuole stabilire una negoziazione ISAKMP tra due firewall, bisogna configurare su ogni dispositivo una policy ISAKMP, cioè un insieme di impostazioni che indicano come instaurare una SA; in particolare, una policy ISAKMP è composta da:
- un metodo di autenticazione, che serve per identificare l’identità dei peer; l’autenticazione può avvenire tramite preshared key (una sorta di password) oppure con l’utilizzo di certificati;
- un metodo di cifratura dei dati, usato per cifrare i dati in transito nel tunnel VPN;
- un algoritmo di hash usato per assicurare l’integrità dei dati;
- un tipo di gruppo Diffie-Hellman, che serve per scambiarsi in sicurezza la chiave segreta condivisa su un canale insicuro;
- un limite di tempo oltre il quale la SA deve essere ristabilita (un timeout, in parole povere), che prende il nome lifetime.
Ogni firewall invia le proprie policy ISAKMP all’altro firewall, e se le policy sono le stesse su entrambi i dispositivi, allora viene stabilita la SA, anche se per avere una connessione VPN funzionante sono necessari altri passaggi, come vedremo tra poco.
Instaurata una SA, su entrambi gli apparati deve essere presente una access list (ACL) che consenta il transito del traffico interessante che dalla rete LAN1 va verso la rete LAN2 e viceversa, sfruttando il canale instaurato tramite la VPN. Definita la ACL, deve essere presente anche una mappa (chiamata crypto map) che assembla i seguenti elementi della SA instaurata con i passaggi precedenti:
- quale traffico deve essere protetto con IPSEC (traffico interessante), definito dalla ACL di cui sopra;
- l’indirizzo IP pubblico dell’altro lato della VPN al quale inviare il traffico tramite IPSEC (peer);
- quale tipo di sicurezza IPSEC è richiesto per questo traffico, definito dal transform set specificato precedentemente;
- a quale interfaccia dell’ASA va applicata la mappa.
Infine va definito un tunnel group su ognuno dei due apparati, dove per una connessione VPN Site to Site può essere sufficiente specificare il tipo di connessione (Lan to Lan) e il metodo di autenticazione.
Definiti questi parametri, e ammesso che tutto funzioni, le due reti sono connesse tra di loro a livello IP, per cui ogni protocollo che si poggia su IP può transitare tramite il tunnel e quindi viaggiare da una rete all’altra, posto che sia configurato il corretto instradamento sugli host di ogni rete.
Configurazione degli apparati
La configurazione dei parametri TCP/IP di base dei due apparati, secondo lo schema di Figura 1, è stata effettuata secondo le indicazioni fornite in un precedente articolo, per cui la diamo per scontata.
Come descritto in precedenza, per configurare la VPN IPSEC su ognuno dei due ASA bisogna impostare una ACL per consentire il traffico tra le due LAN, una policy ISAKMP, un transform set, una mappa crypto map e un tunnel group; la configurazione va effettuata su entrambi gli apparati perché il peer VPN IPSEC è unidirezionale.
Per prima cosa, impostiamo la ACL per il traffico IPSEC, in modo da abilitare il transito dalla rete LAN1 alla rete LAN2, e viceversa:
ASA-1
access-list lantolan extended permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0
ASA-2
access-list lantolan extended permit ip 192.168.2.0 255.255.255.0 192.168.1.0 255.255.255.0
Ora configuriamo il transform set, in cui andremo ad impostare un transform set che avrà come metodo di protezione la crittografia AES 128 bit, e come metodo di autenticazione esp-sha-hmac:
ASA-1
crypto ipsec transform-set VPNTest esp-aes esp-sha-hmac
ASA-2
crypto ipsec transform-set VPNTest esp-aes esp-sha-hmac
dove VPNTest è il nome dato arbitrariamente al transform set, esp-aes è il metodo di protezione e esp-sha-hmac è il metodo di autenticazione.
Adesso bisogna configurare la crypto map, secondo questa sintassi:
ASA-1
1 2 3 4 | crypto map vpnTest 1 match address lantolan crypto map vpnTest 1 set peer 172.16.3.2 crypto map vpnTest 1 set transform-set VPNTest crypto map vpnTest interface outside |
ASA-2
1 2 3 4 | crypto map vpnTest 1 match address lantolan crypto map vpnTest 1 set peer 172.16.3.1 crypto map vpnTest 1 set transform-set VPNTest crypto map vpnTest interface outside |
La configurazione, ovviamente, è praticamente identica in tutti e due i firewall. In questo caso, vpnTest è il nome assegnato alla mappa, identico per tutte e quattro le righe di configurazione della mappa; nella riga 1, indico qual è il traffico interessante per il mio peer IPSEC, identificato dalla ACL chiamata lantolan configurata in precedenza, nella riga 2 indico l’indirizzo del dispositivo col quale voglio instaurare il peer (nel mondo reale, l’IP pubblico del firewall posto sull’altro lato da collegare tramite VPN), nella riga 3 specifico il nome del transform set indicato in precedenza, in modo da specificare le impostazioni di protezione e autenticazione, ed infine nella riga 4 indico a quale interfaccia applicare la mappa.
Nelle righe da 1 a 3, la mappa vpnTest viene identificata col numero 1, che è un numero chiamato sequence number, utilizzato in caso si debbano applicare più mappe alla stessa interfaccia in presenza di più VPN sullo stesso apparato.
Configurata la mappa, bisogna impostare le policy ISAKMP in questo modo:
ASA-1
1 2 3 4 5 6 7 | crypto isakmp enable outside crypto isakmp policy 1 authentication pre-share encryption aes hash sha group 2 lifetime 43200 |
ASA-2
1 2 3 4 5 6 7 | crypto isakmp enable outside crypto isakmp policy 1 authentication pre-share encryption aes hash sha group 2 lifetime 43200 |
Com’è evidente, la configurazione è assolutamente identica su tutti e due i firewall, ed a parte l’impostazione del parametro lifetime, che può essere diverso su ognuno dei firewall, tutto deve essere identico su entrambi gli apparati, pena il mancato funzionamento della VPN.
La riga 1 indica l’abilitazione di isakmp sull’interfaccia outside, la riga 2 indica la configurazione dei parametri che compongono una policy isakmp identificata dal numero 1; indicando questo comando, si aprirà una nuova modalità di configurazione che riguarda l’impostazione della policy isakmp indicata, modalità che comporta anche il cambiamento del prompt, che assume una forma del tipo:
ASA-1(config-isakmp-policy)
La riga 3 indica il tipo di autenticazione (in questo caso preshared key, il tipo più semplice di autenticazione), la riga 4 rappresenta il metodo di protezione (crittografia AES), la riga 5 indica l’algoritmo di hash, la riga 6 indica il tipo di gruppo Diffie-Hellman, mentre la riga 7 indica il timeout della connessione IPSEC, trascorso il quale la SA deve essere rinegoziata.
Infine, rimane da configurare il tunnel group in questo modo:
ASA-1
1 2 3 | tunnel-group 172.16.3.2 type ipsec-l2l tunnel-group 172.16.3.2 ipsec-attributes pre-shared-key ChiaveCondivisa |
ASA-2
1 2 3 | tunnel-group 172.16.3.1 type ipsec-l2l tunnel-group 172.16.3.1 ipsec-attributes pre-shared-key ChiaveCondivisa |
La riga 1 indica a quale indirizzo connettersi per instaurare la connessione VPN e il tipo di connessione IPSEC (nel nostro caso l2l che sta per LAN to LAN), la riga 2 indica il comando per specificare gli attributi della connessione IPSEC, che sono indicati dai comandi successivi (anche in questo caso, cambia il prompt), nel nostro caso, l’unico parametro da digitare riguarda la riga 3 che rappresenta la preshared key che consente di autenticarci sull’altro dispositivo. Penso sia ovvio a questo punto che le preshared key indicate nei due firewall debbano essere identiche.
Aggiornamento 25/08/2009
Ho dimenticato di specificare una cosa. Perché i pacchetti transitino tra una rete e l’altra, se è applicato il natting sul firewall (come accade molto spesso, visto che in genere questi firewall non si occupano solo di fare da endpoint per la VPN), è necessario che il traffico interessante non venga nattato. Per evitare questa cosa, è necessario specificare questo comando su entrambi gli ASA:
nat (inside) 0 access-list lantolan
Se tutto è andato bene, è possibile provare a testare la connettività tra i due portatili con il comando ping. Se la VPN funziona, è possibile che il primo pacchetto vada perso a causa del tempo necessario ad instaurare la SA, ma i pacchetti successivi dovrebbero arrivare correttamente; inoltre, in caso di VPN correttamente funzionante, dovrebbe accendersi il led VPN posto in posizione frontale sull’ASA 5505.
Troubleshooting di base sulle connessioni VPN IPSEC
In caso di mancato funzionamento, è possibile effettuare un po’ di troubleshooting cercando di capire per quale motivo la VPN non funziona; in questi casi, può essere utile digitare i due comandi indicati di seguito:
debug crypto ipsec debug crypto isakmp
Con questi due comandi, in caso di problemi compaiono un sacco di messaggi sullo schermo, sta a noi isolare quei messaggi che possono realmente aiutarci a capire che sta avvenendo. Quando i messaggi diventano troppi (ed in genere succede presto), è possibile interrompere il logging a video coi comandi
no debug crypto ipsec no debug crypto isakmp
oppure, più semplicemente, col comando
no debug all
Tenere presente che, se ci sono dei problemi, spesso accade che le policy isakmp non sono identiche su entrambi i firewall.
Può anche accadere che la configurazione dei due ASA sia corretta ma che il traffico non arrivi a destinazione, in questi casi bisogna verificare che l’instradamento dei pacchetti verso l’altra rete avvenga correttamente, impostando il corretto router negli host della rete locale oppure utilizzando le opportune route statiche.
