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.
Link di riferimento
[...] miei test su questa funzionalità dell’ASA, ho ripreso l’ambiente di test descritto nel precedente articolo riguardante la VPN IPSEC tra due ASA [...]
Ottimo e molto chiara. Grazie.
Ciao Marco, grazie a te per il riscontro!
Voglio ringraziarti perché grazie a Te sto imparando qualcosa sull’esoterico mondo Cisco. Finalmente si legge qualcosa di comprensibile anche a quelli che, come me, stanno iniziando. Perché fino ad ora pensavo di non essere in grado di capire come funzionano quelle macchine così lontane dalla mente umana come le apparecchiature Cisco.
Bando alle ciance, grazie alle Tue indicazioni ho installato una VPN per cui il cliente aveva espressamente chiesto Cisco. Ho avuto qualche difficoltà con l’ambiente di test perché ho usato un vecchio OfficeConnect 3Com 3C-860-95 (che è un firewall). Naturalmente ho disabilitato la funzione firewall e ho creato un virtual server lato lan con l’indirizzo dell’ASA-1. Nell’ambiente di test non ha funzionato, ma sul campo ha funzionato al primo colpo.
Come posso crearmi un ambiente di test indubbiamente funzionante e il più possibile vicino alla realtà per i bisogni del futuro?
Grazie ancora.
Guido
Ciao Guido, grazie anche a te per il riscontro positivo, mi fa piacere esserti stato utile.
Riguardo all’ambiente di test, io non ho messo nessun firewall a monte dell’ASA, poiché da test effettuati in passato, ho visto che, anche abilitando la funzionalità virtual server su un eventuale firewall a monte dell’ASA, vi sono dei problemi, poiché, da quanto ho capito, il protocollo IPSEC, con una configurazione di questo tipo, funzionerebbe in modalità NAT Traversal, e non è la cosa più indicata.
Parlando di ambiente di test, come ho scritto nell’articolo, ho messo un semplice switch tra le due interfacce “WAN” (esterne), mettendo queste due interfacce sullo stesso piano di indirizzamento in modo che si “parlino” senza problemi, mentre le due interfacce LAN hanno il loro piano di indirizzamento distinto. Una configurazione di questo tipo serve a replicare quella che secondo me è la miglior configurazione da effettuare nel “mondo reale”, ovvero, ogni ASA col proprio indirizzo IP pubblico dedicato, in modo da:
1) non aggiungere un ulteriore livello di complessità dovuto ad ulteriori firewall
2) una maggior facilità di troubleshooting: in caso di problemi, un ulteriore dispositivo può rendere più difficile capire dove sta l’inghippo
Spero di aver chiarito le tue perplessità, in caso contrario proverò ad essere più chiaro, per quanto è nelle mie possibilità.
Sei stato chiarissimo. E per l’uso accademico, quella che hai preso, è sicuramente la via più semplice.
Personalmente però mi sarebbe piaciuto creare un ambiente il più possibile simile alla realtà, perciò con gli indirizzi pubblici veri che le ASA avranno sul campo.
Il motivo è che una volta finita la programmazione ed accertata la funzionalità vorrei non doverle più modificare per evitare eventuali errori di digitazione.
D’altra parte potrei modificare la sola subnet mask (lato wan) ponendola a 0.0.0.0 nell’ambiente di test. Cosa ne pensi?
Se vuoi un ambiente di test il più possibile aderente alla realtà, tenendo gli IP pubblici su entrambi i firewall, allora, secondo me, ti conviene configurare i firewall così come dovranno essere configurati realmente, mettendo tra i due dispositivi un router (che può essere anche un qualsiasi PC che permetta il transito tra le due interfacce di rete di cui dovrà essere dotato).
Ad esempio, se ASA-1 ha come ip pubblico 11.1.1.2/29, con default gateway 11.1.1.1, mentre ASA-2 ha come ip pubblico 100.1.1.2/29 con default gateway 100.1.1.1, allora il router di test dovrà avere due interfacce di rete, una con indirizzo 11.1.1.1 e l’altra con indirizzo 100.1.1.1.
Se hai qualche dubbio, chiedi pure.
Non hai nssuna voglia di far qualcosa di simile riguardo il “remote access” via Cisco client o Windows client, vero? Finora ho trovato solo la configurazione attraverso l’interfaccia grafica ASDM, ma con l’interfaccia grafica non si capisce bene il flusso come invece utilizzando la CLI. Vabbè io passo e ripasso… chissà…
Buon week end
Guido
Guido, più che altro, non ho mai usato firewall Cisco per le connessioni cosidette “roadwarrior”, le volte che l’ho fatto ho usato ISA Server o OpenVPN (OpenVPN solo una volta, devo dire). Comunque, se vuoi trovare materiale relativamente a tutto ciò che ti interessa conoscere sulla riga di comando degli ASA, Google aiuta
:
http://www.google.it/search?q=cisco+security+appliance+command+line+configuration+guide
Qui puoi trovare la reference completa a seconda della versione di IOS installata sull’ASA.
Ciao a tutti, ho seguito le indicazioni per una connessione vpn site-to-site con due dispositivi ASA 5505, il tunnel viene stabilito ma non riesco in alcun modo a fare ping tra le due lan private che si trovano dietro i rispettivi ASA.
La configurazione è la seguente:
: Saved
:
ASA Version 8.2(1)
!
hostname ciscoasa
domain-name default.domain.invalid
enable password 0R2MX4Kk7jsue7zn encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
names
!
interface Vlan1
nameif inside
security-level 100
ip address 192.168.1.10 255.255.255.0
!
interface Vlan2
nameif outside
security-level 0
ip address 2.1.44.35 255.255.255.248
!
interface Ethernet0/0
switchport access vlan 2
!
interface Ethernet0/1
!
interface Ethernet0/2
!
interface Ethernet0/3
!
interface Ethernet0/4
!
interface Ethernet0/5
!
interface Ethernet0/6
!
interface Ethernet0/7
!
boot system disk0:/asa821-k8.bin
ftp mode passive
dns server-group DefaultDNS
domain-name default.domain.invalid
access-list outside_1_cryptomap extended permit ip 192.168.1.0 255.255.255.0 192.168.0.0 255.255.255.0
access-list inside_nat0_outbound extended permit ip 192.168.1.0 255.255.255.0 192.168.0.0 255.255.255.0
pager lines 24
logging asdm informational
mtu inside 1500
mtu outside 1500
icmp unreachable rate-limit 1 burst-size 1
asdm image disk0:/asdm-621.bin
no asdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list inside_nat0_outbound
nat (inside) 1 0.0.0.0 0.0.0.0
route outside 0.0.0.0 0.0.0.0 2.1.44.38 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
dynamic-access-policy-record DfltAccessPolicy
http server enable
http 192.168.1.0 255.255.255.0 inside
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto map outside_map 1 match address outside_1_cryptomap
crypto map outside_map 1 set pfs group1
crypto map outside_map 1 set peer 1.2.182.42
crypto map outside_map 1 set transform-set ESP-3DES-SHA
crypto map outside_map interface outside
crypto isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
telnet timeout 5
ssh timeout 5
console timeout 0
dhcpd auto_config outside
!
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
webvpn
tunnel-group 1.2.182.42 type ipsec-l2l
tunnel-group 1.2.182.42 ipsec-attributes
pre-shared-key *
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
!
service-policy global_policy global
prompt hostname context
Cryptochecksum:7b17d4ebbb0e9b605d8f97458554eb46
: end
asdm image disk0:/asdm-621.bin
no asdm history enable
mentre sull’altro dispositivo:
: Saved
:
ASA Version 8.2(1)
!
hostname ciscoasa
domain-name default.domain.invalid
enable password yjWoTDJEsBZjH.DV encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
names
!
interface Vlan1
nameif inside
security-level 100
ip address 192.168.0.10 255.255.255.0
!
interface Vlan2
nameif outside
security-level 0
ip address 1.2.182.42 255.255.255.248
!
interface Ethernet0/0
switchport access vlan 2
!
interface Ethernet0/1
!
interface Ethernet0/2
!
interface Ethernet0/3
!
interface Ethernet0/4
!
interface Ethernet0/5
!
interface Ethernet0/6
!
interface Ethernet0/7
!
boot system disk0:/asa821-k8.bin
ftp mode passive
dns server-group DefaultDNS
domain-name default.domain.invalid
access-list outside_1_cryptomap extended permit ip 192.168.0.0 255.255.255.0 192.168.1.0 255.255.255.0
access-list inside_nat0_outbound extended permit ip 192.168.0.0 255.255.255.0 192.168.1.0 255.255.255.0
pager lines 24
logging asdm informational
mtu inside 1500
mtu outside 1500
icmp unreachable rate-limit 1 burst-size 1
asdm image disk0:/asdm-621.bin
no asdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list inside_nat0_outbound
nat (inside) 1 0.0.0.0 0.0.0.0
route outside 0.0.0.0 0.0.0.0 1.2.182.46 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
dynamic-access-policy-record DfltAccessPolicy
http server enable
http 192.168.0.0 255.255.255.0 inside
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto map outside_map 1 match address outside_1_cryptomap
crypto map outside_map 1 set pfs group1
crypto map outside_map 1 set peer 2.1.44.35
crypto map outside_map 1 set transform-set ESP-3DES-SHA
crypto map outside_map interface outside
crypto isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
telnet timeout 5
ssh timeout 5
console timeout 0
dhcpd auto_config outside
!
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
webvpn
tunnel-group 2.1.44.35 type ipsec-l2l
tunnel-group 2.1.44.35 ipsec-attributes
pre-shared-key *
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
!
service-policy global_policy global
prompt hostname context
Cryptochecksum:f9eb6df8a212428a8871873099b98558
: end
asdm image disk0:/asdm-621.bin
no asdm history enable
dai log risulta che:
Teardown ICMP connection for faddr 192.168.0.100/0 gaddr 192.168.1.159/512 laddr 192.168.1.159/512
Built outbound ICMP connection for faddr 192.168.0.100/0 gaddr 192.168.1.159/512 laddr 192.168.1.159/512
dove sbaglio ?
Grazie.
-
Salvatore.
Ciao Salvatore, purtroppo sono decisamente preso e non riesco a dare un’occhiata dettagliata alla configurazione dei due apparati, però chiarire alcuni punti forse può aiutare:
1) è assodato che non transiti il traffico ICMP tra le due LAN, ma il resto del traffico transita?
2) hai provato a fare un po’ di sniffing della rete, con wireshark e sugli stessi apparati? Qui trovi un mio articolo relativo allo sniffing del traffico di rete con ASA: http://www.ricercheit.net/2009/11/03/sniffing-del-traffico-di-rete-con-cisco-asa-5505
3) come hai ottenuto i log che hai allegato alla fine del tuo commento?
Ciao Lorenzo e grazie per la pronta risposta, ho risolto il problema riportando il dispositivo ai valori di default e facendo nuovamente tutta la configurazione, capisco che non è il modo migliore di procedere ma non riuscivo proprio a capire il perchè del fatto che il tunnel veniva stabilito ma il ping non andava a buon fine.
Approfitto per ringraziarti per il materiale che metti a disposizione e volevo dirti, qualora tu ne abbia necessità, che posso mettere a disposizione un po’ del mio tempo (ed un pò della mia esperienza) per far crescere sempre di più questo blog che ripeto mi sembra davvero interessante.
Buon lavoro.
-
Salvatore.