Questo documento descrive le soluzioni più comuni per i problemi della VPN IPsec.
Le soluzioni descritte in questo documento provengono direttamente dalle richieste di assistenza risolte dal team di supporto tecnico Cisco. Molte di queste soluzioni vengono implementate prima della risoluzione approfondita dei problemi di una connessione VPN IPsec. In questo documento viene fornito un riepilogo delle procedure comuni da eseguire prima di iniziare a risolvere i problemi relativi a una connessione.
Gli esempi di configurazione riportati in questo documento sono destinati all'uso su router e appliance di sicurezza e quasi tutti i concetti sono applicabili a VPN 3000. Per una spiegazione dei comandi di debug comuni utilizzati per risolvere i problemi relativi a IPsec su entrambi i software Cisco IOS®, consultare il documento sulla risoluzione dei problemi relativi alla sicurezza IP - Descrizione e uso dei comandi di debug.
Nota: L'associazione di sicurezza non passa il traffico multicast sui tunnel VPN IPSec.
Avviso: Molte delle soluzioni presentate in questo documento possono causare la perdita temporanea di tutta la connettività VPN IPsec su un dispositivo. Si consiglia di implementare queste soluzioni con cautela e in conformità con i criteri di controllo delle modifiche.
Cisco consiglia di conoscere la configurazione della VPN IPsec sui seguenti dispositivi Cisco:
Cisco ASA serie 5500 Security Appliance
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
Cisco ASA serie 5500 Security Appliance
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
In questa sezione vengono illustrate le soluzioni ai problemi più comuni delle VPN IPsec. Anche se non sono elencate in un ordine particolare, queste soluzioni possono essere utilizzate come elenco di controllo per verificare prima di intraprendere un'azione correttiva approfondita. Tutte queste soluzioni provengono direttamente dalle richieste di assistenza TAC e hanno risolto numerosi problemi.
Cancella associazioni di sicurezza precedenti o esistenti (tunnel)
Verificare che gli ACL siano corretti e associati alla mappa crittografica
Verifica dei numeri di sequenza e del nome della mappa crittografica
Nota: Per problemi di spazio, alcuni comandi di queste sezioni vengono spostati in basso su una seconda riga.
NAT-Traversal (o NAT-T) consente al traffico VPN di passare attraverso dispositivi NAT o PAT, ad esempio il router Linksys SOHO. Se NAT-T non è abilitato, gli utenti dei client VPN spesso sembrano connettersi all'appliance ASA senza problemi, ma non possono accedere alla rete interna dietro l'appliance di sicurezza. Se NAT-T nel dispositivo NAT/PAT non è abilitato, è possibile ricevere il messaggio di errore PAT (Translation Create Failed) per il protocollo 50 src inside:10.0.1.26 dst outside:10.9.694 nell'appliance ASA.
Se non è possibile completare gli accessi simultanei dallo stesso indirizzo IP, la connessione VPN protetta verrà terminata localmente dal client. 412: Verrà visualizzato il messaggio di errore Il peer remoto non risponde più. Per risolvere il problema, abilitare NAT-T nel dispositivo VPN headend.
Nota: Con il software Cisco IOS® versione 12.2(13)T e successive, NAT-T è abilitato per impostazione predefinita in Cisco IOS®.
Il comando successivo abilita NAT-T su Cisco Security Appliance. Il valore 20 di questo esempio indica il tempo keepalive (predefinito).
ASA
securityappliance(config)#crypto isakmp nat-traversal 20
Affinché questa operazione funzioni correttamente, è necessario modificare i client. In Cisco VPN Client, passare a Voci di connessione e fare clic su Modifica. Verrà aperta una nuova finestra e sarà necessario scegliere la scheda Trasporto. In questa scheda, fare clic su Enable Transparent Tunneling e sul pulsante di opzione IPSec over UDP ( NAT/PAT ). Quindi fate clic su Salva (Save) e verificate la connessione.
È importante consentire la configurazione di UDP 4500 per le porte NAT-T, UDP 500 ed ESP tramite la configurazione di un ACL, in quanto l'ASA funziona come dispositivo NAT. Per ulteriori informazioni sulla configurazione degli ACL nell'appliance ASA, consultare il documento sulla configurazione di un tunnel IPsec attraverso un firewall con NAT.
La connettività VPN viene testata dai dispositivi dietro l'endpoint di crittografia. Molti utenti testano la connettività VPN eseguendo il comando ping dall'endpoint di crittografia. Anche se il comando ping in genere funziona a questo scopo, è importante originare il ping dall'interfaccia corretta. Se l'origine del ping non è corretta, è possibile che la connessione VPN non sia riuscita quando funziona correttamente. Questo è un esempio:
ACL crittografico del router A
access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255
ACL crittografico del router B
access-list 110 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255
Nell'esempio, il ping deve essere originato dalla rete dietro uno dei router. Gli ACL crittografici sono configurati solo per crittografare il traffico con questi indirizzi di origine. Le assegnazioni originate dalle interfacce esterne di uno dei router non sono crittografate. Per originare un ping dall'interfaccia interna di un router, usare le opzioni estese del comando ping in modalità di esecuzione privilegiata:
routerA#ping Protocol [ip]: Target IP address: 192.168.200.10 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 192.168.100.1 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.200.1, timeout is 2 seconds: Packet sent with a source address of 192.168.100.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = ½/4 ms
Immaginate che i router illustrati nel diagramma siano sostituiti da appliance di sicurezza ASA. I concetti utilizzati per testare la connettività possono anche essere originati dall'interfaccia interna con la parola chiave insidekeyword:
securityappliance#ping inside 192.168.200.10 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.200.10, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Si consiglia di non utilizzare il comando ping sull'interfaccia interna di un accessorio di sicurezza. Se l'interfaccia interna deve essere indirizzata con il comando ping, attivare l'accesso management all'interfaccia oppure l'accessorio non risponde"
securityappliance(config)#management-access inside
Quando si verifica un problema di connettività, anche la fase 1 della VPN non funziona. Sull'appliance ASA, se la connettività non riesce, l'output dell'associazione di sicurezza è simile a questo esempio, il che indica una possibile configurazione peer crittografica non corretta o una configurazione della proposta ISAKMP non corretta:
Router#show crypto isakmp sa
1 IKE Peer: XX.XX.XX.XX
Type : L2L Role : initiator
Rekey : no State : MM_WAIT_MSG2
Lo stato può essere compreso tra MM_WAIT_MSG2 e MM_WAIT_MSG5, che indica un errore dello scambio di stato interessato in modalità principale (MM). Crypto SA output quando la fase 1 è attiva; come nell'esempio seguente:
Router#show crypto isakmp sa
1 IKE Peer: XX.XX.XX.XX
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
Se non vi è alcuna indicazione che un tunnel VPN IPsec funzioni come previsto, è possibile che ISAKMP non sia abilitato. Accertarsi di aver abilitato ISAKMP sui dispositivi. Utilizzare uno dei seguenti comandi per abilitare ISAKMP:
Cisco IOS®
router(config)#crypto isakmp enable
Cisco ASA (sostituire all'esterno dell'interfaccia desiderata):
securityappliance(config)#crypto isakmp enable outside
È possibile ricevere questo errore anche quando si abilita ISAKMP sull'interfaccia esterna:
UDP: ERROR - socket <unknown> 62465 in used ERROR: IkeReceiverInit, unable to bind to port
La causa dell'errore può essere collegata al client dietro alle appliance ASA che riceve il PAT sulla porta UDP 500 prima che sia possibile abilitare ISAKMP sull'interfaccia. Una volta rimossa la traduzione PAT (clear xlate), è possibile abilitare ISAKMP. Verificare che i numeri di porta UDP 500 e 4500 siano riservati per la negoziazione delle connessioni ISAKMP con il peer. Quando ISAKMP non è abilitato sull'interfaccia, il client VPN visualizza un messaggio di errore simile al seguente:
Secure VPN connection terminated locally by client. Reason 412: The remote peer is no longer responding
Per risolvere questo errore, abilitare il protocollo ISAKMP sull'interfaccia crittografica del gateway VPN.
Nelle negoziazioni IPSec, PFS (Perfect Forward Secrecy) garantisce che ogni nuova chiave di crittografia non sia correlata a nessuna chiave precedente. Abilitare o disabilitare PFS su entrambi i peer del tunnel; in caso contrario, il tunnel IPsec LAN-to-LAN (L2L) non viene stabilito nel router ASA/Cisco IOS®. Perfect Forward Secrecy (PFS) è proprietario di Cisco e non è supportato sui dispositivi di terze parti.
ASA:
PFS è disattivato per impostazione predefinita e, per attivarlo, eseguire il comando pfscon la parola chiave enable nella modalità di configurazione dei criteri di gruppo. Per disabilitare PFS, immettere la parola chiave disable.
hostname(config-group-policy)#pfs {enable | disable}
Per rimuovere l'attributo PFS dalla configurazione, eseguire il comando no. Un criterio di gruppo può ereditare un valore per PFS da un altro criterio. Eseguire la forma no di questo comando per impedire il trasferimento di un valore.
hostname(config-group-policy)#no pfs
Router Cisco IOS®
set pfs [group1 | group2] no set pfs
Per il comando set pfs:
group1: specifica che IPsec deve utilizzare il gruppo di moduli primari Diffie-Hellman a 768 bit quando viene eseguito il nuovo scambio Diffie-Hellman.
group2: specifica che IPsec deve utilizzare il gruppo di moduli primari Diffie-Hellman a 1024 bit quando viene eseguito il nuovo scambio Diffie-Hellman.
Esempio:
Router(config)#crypto map map 10 ipsec-isakmp Router(config-crypto-map)#set pfs group2
Se viene visualizzato questo messaggio di errore sul router Cisco IOS®, l'appliance ASA è scaduta o è stata cancellata. Il dispositivo terminale del tunnel remoto non è a conoscenza del fatto che utilizza l'associazione di protezione scaduta per inviare un pacchetto (non un pacchetto di istituzione dell'associazione di protezione). Quando viene stabilita una nuova associazione di sicurezza, la comunicazione riprende, quindi inizia il traffico attraverso il tunnel per creare una nuova associazione di sicurezza e ristabilire il tunnel.
%CRYPTO-4-IKMP_NO_SA: IKE message from x.x.x.x has no SA
Se si cancellano le associazioni di sicurezza ISAKMP (fase 1) e IPsec (fase 2), spesso è la soluzione migliore per risolvere i problemi delle VPN IPsec. Se si cancellano le associazioni di protezione, è possibile risolvere un'ampia varietà di messaggi di errore e di comportamenti senza dover eseguire una risoluzione approfondita dei problemi. Sebbene questa tecnica possa essere facilmente utilizzata in qualsiasi situazione, è consigliabile cancellare le associazioni di protezione dopo aver modificato o aggiunto una configurazione VPN IPsec corrente. Inoltre, mentre è possibile cancellare solo specifiche associazioni di protezione, è possibile ottenere dei vantaggi se si cancellano le associazioni di protezione a livello globale sul dispositivo. Dopo aver cancellato le associazioni di sicurezza, può essere necessario inviare il traffico attraverso il tunnel per ristabilirle.
Avviso: A meno che non si specifichino le associazioni di protezione da cancellare, i comandi elencati possono cancellare tutte le associazioni di protezione presenti nel dispositivo. Procedere con cautela se sono in uso altri tunnel VPN IPsec.
Visualizzare le associazioni di sicurezza prima di cancellarle
Cisco Cisco IOS®
router#show crypto isakmp sa router#show crypto ipsec sa
Appliance di sicurezza Cisco ASA
securityappliance#show crypto isakmp sa securityappliance#show crypto ipsec sa
Cancella le associazioni di protezione. Ogni comando può essere immesso come indicato in grassetto o con le opzioni visualizzate.
Cisco IOS®
ISAKMP (fase I)
router#clear crypto isakmp ? <0 - 32766> connection id of SA <cr>
IPsec (fase II)
router#clear crypto sa ? counters Reset the SA counters map Clear all SAs for a given crypto map peer Clear all SAs for a given crypto peer spi Clear SA by SPI <cr>
Appliance di sicurezza Cisco ASA
ISAKMP (fase I)
securityappliance#clear crypto isakmp sa
IPsec (fase II)
security appliance#clear crypto ipsec sa ? counters Clear IPsec SA counters entry Clear IPsec SAs by entry map Clear IPsec SAs by map peer Clear IPsec SA by peer <cr>
Se gli utenti vengono disconnessi di frequente attraverso il tunnel L2L, il problema può essere configurato nella SA ISAKMP per tutta la durata. Se si verifica una discrepanza durante la durata di ISAKMP, è possibile ricevere il messaggio di errore %ASA-5-713092: Gruppo = x.x.x.x, IP = x.x.x.x, errore durante il tentativo di reimpostazione della chiave di fase 1 a causa di un messaggio di errore di collisione in /ASA. L'impostazione predefinita è 86.400 secondi o 24 ore. In generale, una durata più breve garantisce negoziazioni ISAKMP più sicure (fino a un certo punto). Tuttavia, con durate più brevi, l'appliance di sicurezza configura più rapidamente le future associazioni di protezione IPSec.
Una corrispondenza viene creata quando entrambi i criteri di due peer contengono gli stessi valori di crittografia, hash, autenticazione e parametro Diffie-Hellman e quando il criterio del peer remoto specifica una durata inferiore o uguale alla durata del criterio confrontato. Se le durate non sono identiche, viene utilizzata la durata più breve, derivata dalla regola del peer remoto, e non viene trovata alcuna corrispondenza accettabile, l'IKE rifiuta la negoziazione e l'associazione di protezione IKE non viene stabilita.
ASA:
hostname(config)#isakmp policy 2 lifetime 14400
Router Cisco IOS®:
R2(config)#crypto isakmp policy 10 R2(config-isakmp)#lifetime 86400
Se viene superata la durata massima configurata, viene visualizzato questo messaggio di errore quando la connessione VPN viene terminata:
Connessione VPN sicura terminata localmente dal client. 426: Durata massima configurata superata.
Per risolvere l'errore, impostare elifetimevalue su zero (0). Per impostare la durata di un'associazione di sicurezza IKE su infinito, la VPN deve essere sempre connessa e non terminare:
hostname(config)#isakmp policy 2 lifetime 0
È inoltre possibile disattivare re-xauth nei Criteri di gruppo per risolvere il problema.
Se si configurano i pacchetti keepalive ISAKMP, questi impediscono la perdita sporadica di connessioni LAN a LAN o VPN ad accesso remoto. Ciò include i client VPN, i tunnel e i tunnel scartati dopo un periodo di inattività. Questa funzionalità consente agli endpoint del tunnel di monitorare la presenza continua di un peer remoto e di segnalare la propria presenza a tale peer. Se il peer non risponde, l'endpoint rimuove la connessione. Affinché i pacchetti keepalive ISAKMP funzionino, entrambi gli endpoint VPN devono supportarli.
Configurare i pacchetti keepalive ISAKMP in Cisco IOS® eseguendo questo comando:
router(config)#crypto isakmp keepalive 15
Eseguire questi comandi per configurare i pacchetti keepalive ISAKMP su appliance di sicurezza ASA:
Cisco ASA per il gruppo di tunnel con nome 10.165.205.222:
securityappliance(config)#tunnel-group 10.165.205.222 ipsec-attributes securityappliance(config-tunnel-ipsec)#isakmp keepalive threshold 15 retry 10
In alcune situazioni, è necessario disattivare questa funzione per risolvere il problema. Ad esempio, se il client VPN è protetto da un firewall che impedisce l'invio di pacchetti DPD. Con Cisco ASA, per il gruppo di tunnel con nome 10.165.205.222 - Disabilitare l'elaborazione keepalive IKE, abilitata per impostazione predefinita:
securityappliance(config)#tunnel-group 10.165.205.222 ipsec-attributes securityappliance(config-tunnel-ipsec)#isakmp keepalive disable
Disabilitare Keepalive per Cisco VPN Client 4.x
In molti casi, quando un tunnel VPN IPsec non funziona, è possibile che sia presente un semplice errore tipografico. Ad esempio, sull'appliance di sicurezza, le chiavi già condivise diventano nascoste una volta immesse. Questo tipo di offuscamento rende impossibile determinare se una chiave non è corretta. Accertarsi di aver immesso correttamente eventuali chiavi già condivise su ciascun endpoint VPN.
In VPN ad accesso remoto, verificare che il nome del gruppo valido e le chiavi già condivise siano stati immessi nel client VPN di Cisco. È possibile che questo errore si verifichi se il nome del gruppo o le chiavi già condivise non corrispondono tra il client VPN e il dispositivo headend.
1 12:41:51.900 02/18/06 Sev=Warning/3 IKE/0xE3000056 The received HASH payload cannot be verified 2 12:41:51.900 02/18/06 Sev=Warning/2 IKE/0xE300007D Hash verification failed 3 14:37:50.562 10/05/06 Sev=Warning/2 IKE/0xE3000099 Failed to authenticate peer (Navigator:904) 4 14:37:50.593 10/05/06 Sev=Warning/2 IKE/0xE30000A5 Unexpected SW error occurred while processing Aggressive Mode negotiator:(Navigator:2202) 5 14:44:15.937 10/05/06 Sev=Warning/2 IKE/0xA3000067 Received Unexpected InitialContact Notify (PLMgrNotify:888) 6 14:44:36.578 10/05/06 Sev=Warning/3 IKE/0xE3000056 The received HASH payload cannot be verified 7 14:44:36.593 10/05/06 Sev=Warning/2 IKE/0xE300007D Hash verification failed... possibly be configured with invalid group password. 8 14:44:36.609 10/05/06 Sev=Warning/2 IKE/0xE3000099 Failed to authenticate peer (Navigator:904) 9 14:44:36.640 10/05/06 Sev=Warning/2 IKE/0xE30000A5 Unexpected SW error occurred while processing Aggressive Mode negotiator:(Navigator:2202)
Avviso: Se si rimuovono i comandi relativi alla crittografia, è possibile disattivare uno o tutti i tunnel VPN. Utilizzare questi comandi con cautela e consultare i criteri di controllo delle modifiche dell'organizzazione prima di rimuovere i comandi relativi alla crittografia.
Eseguire questi comandi per rimuovere e immettere nuovamente il keysecretkeyprecondiviso per il peer10.0.0.1 o il groupvpngroupin Cisco IOS®:
Cisco LAN-to-LAN VPN:
router(config)#no crypto isakmp key secretkey address 10.0.0.1 router(config)#crypto isakmp key secretkey address 10.0.0.1
Cisco Remote Access VPN:
router(config)#crypto isakmp client configuration group vpngroup router(config-isakmp-group)#no key secretkey router(config-isakmp-group)#key secretkey
Eseguire questi comandi per rimuovere e immettere nuovamente il keysecretkeypre-condiviso per peer10.0.0.1su appliance di sicurezza /ASA:
Cisco 6.x:
(config)#no isakmp key secretkey address 10.0.0.1 (config)#isakmp key secretkey address 10.0.0.1
Cisco /ASA 7.x e versioni successive:
securityappliance(config)#tunnel-group 10.0.0.1 ipsec-attributes securityappliance(config-tunnel-ipsec)#no ikev1 pre-shared-key securityappliance(config-tunnel-ipsec)# ikev1 pre-shared-key secretkey
L'avvio del tunnel VPN è disconnesso. Questo problema si verifica a causa di una mancata corrispondenza di una chiave già condivisa durante le negoziazioni della fase I. Il messaggio MM_WAIT_MSG_6 nel comando show crypto isakmp indica una chiave già condivisa non corrispondente, come mostrato nell'esempio:
ASA#show crypto isakmp sa
Active SA: 1
Rekey SA: 0 (A tunnel reports 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1
1 IKE Peer: 10.7.13.20
Type : L2L Role : initiator
Rekey : no State : MM_WAIT_MSG_6
Per risolvere il problema, immettere nuovamente la chiave già condivisa in entrambi gli accessori. la chiave già condivisa deve essere univoca e corrispondente. Per ulteriori informazioni, vedere Reimmettere o recuperare le chiavi già condivise.
Se si cancellano le associazioni di sicurezza e il problema della VPN IPsec non viene risolto, rimuovere e riapplicare la mappa crittografica appropriata per risolvere una vasta gamma di problemi, tra cui perdite intermittenti del tunnel VPN e errori di alcuni siti VPN.
Avviso: Se si rimuove una mappa crittografica da un'interfaccia, vengono rimossi tutti i tunnel IPsec associati a tale mappa crittografica. Procedere con cautela, fare riferimento a questi passaggi e considerare i criteri di controllo delle modifiche dell'organizzazione prima di procedere.
Eseguire questi comandi per rimuovere e sostituire una mappa crittografica in Cisco IOS®:
Iniziare con la rimozione della mappa crittografica dall'interfaccia. Eseguire la forma no del comando crypto map:
router(config-if)#no crypto map mymap
Continuare a eseguire la piattaforma per rimuovere un'intera mappa crittografica:
router(config)#no crypto map mymap 10
Sostituire la mappa crittografica sull'interfaccia Ethernet0/0 per il peer10.0.0.1. Questo esempio mostra la configurazione minima richiesta della mappa crittografica:
router(config)#crypto map mymap 10 ipsec-isakmp router(config-crypto-map)#match address 101 router(config-crypto-map)#set transform-set mySET router(config-crypto-map)#set peer 10.0.0.1 router(config-crypto-map)#exit router(config)#interface ethernet0/0 router(config-if)#crypto map mymap
Eseguire questi comandi per rimuovere e sostituire una mappa crittografica sull'appliance ASA. Iniziare con la rimozione della mappa crittografica dall'interfaccia. Eseguire la forma no del comando crypto map:
securityappliance(config)#no crypto map mymap interface outside
Continuare a eseguire la maschera per rimuovere gli altri comandi della mappa crittografica:
securityappliance(config)#no crypto map mymap 10 match address 101 securityappliance(config)#no crypto map mymap set transform-set mySET securityappliance(config)#no crypto map mymap set peer 10.0.0.1
Sostituire la mappa crittografica per peer10.0.0.1. In questo esempio viene mostrata la configurazione minima richiesta per la mappa crittografica:
securityappliance(config)#crypto map mymap 10 ipsec-isakmp securityappliance(config)#crypto map mymap 10 match address 101 securityappliance(config)#crypto map mymap 10 set transform-set mySET securityappliance(config)#crypto map mymap 10 set peer 10.0.0.1 securityappliance(config)#crypto map mymap interface outside
Se si rimuove e si applica nuovamente la mappa crittografica, il problema di connettività viene risolto anche se l'indirizzo IP dell'headend è stato modificato.
Il comando commandssyspot connection allow-ipsecandsysopt connection allow-vpnallow permette ai pacchetti provenienti da un tunnel IPsec e dai relativi payload di ignorare gli ACL di interfaccia sull'appliance di sicurezza. I tunnel IPsec terminati sull'appliance di sicurezza potrebbero non riuscire se uno di questi comandi non è abilitato.
Cisco ASA:
securityappliance# show running-config all sysopt no sysopt connection timewait sysopt connection tcpmss 1380 sysopt connection tcpmss minimum 0 no sysopt nodnsalias inbound no sysopt nodnsalias outbound no sysopt radius ignore-secret sysopt connection permit-vpn !--- sysopt connection permit-vpn is enabled !--- This device is running 7.2(2)
Eseguire questo comando per abilitare il comando correctsysoptper il dispositivo:
Cisco ASA:
securityappliance(config)#sysopt connection permit-vpn
Se non si desidera eseguire il comando sysost connection, autorizzare in modo esplicito il traffico necessario dall'origine alla destinazione. Ad esempio, dalla LAN remota a locale del dispositivo remoto e dalla "porta UDP 500" per l'interfaccia esterna del dispositivo remoto all'interfaccia esterna del dispositivo locale, nell'ACL esterno.
Gli errori di negoziazione IKE nelle VPN IPSec spesso derivano dal mancato riconoscimento dell'identità del partner da parte di un peer. Quando due peer utilizzano IKE per stabilire associazioni di sicurezza IPSec, ogni peer invia la propria identità ISAKMP al peer remoto. e invia il proprio indirizzo IP o nome host a seconda di come è stata impostata l'identità ISAKMP di ciascuno di essi. Per impostazione predefinita, l'identità ISAKMP dell'unità firewall è impostata sull'indirizzo IP.
Come regola generale, impostare l'appliance di sicurezza e le identità dei peer nello stesso modo per evitare un errore di negoziazione IKE. Per impostare l'ID fase 2 da inviare al peer, eseguire il comando isakmp identity in modalità di configurazione globale:
crypto isakmp identity address !--- If the RA or L2L (site-to-site) VPN tunnels connect !--- with pre-shared key as authentication type
O:
crypto isakmp identity auto !--- If the RA or L2L (site-to-site) VPN tunnels connect !--- with ISAKMP negotiation by connection type; IP address for !--- preshared key or cert DN for certificate authentication.
O:
crypto isakmp identity hostname !--- Uses the fully-qualified domain name of !--- the host exchange ISAKMP identity information (default). !--- This name comprises the hostname and the domain name.
Se il tunnel VPN non si avvia dopo uno spostamento della configurazione dall'ASA con lo strumento di migrazione della configurazione ASA; questi messaggi vengono visualizzati nel registro:
[IKEv1]: Gruppo = x.x.x.x, IP = x.x.x, PeerTblEntry non aggiornata trovata, rimozione in corso.
[IKEv1]: Gruppo = x.x.x.x, IP = x.x.x, Rimozione del peer dalla tabella dei correlatori non riuscita. Nessuna corrispondenza.
[IKEv1]: Gruppo = x.x.x.x, IP = x.x.x, construtto_ipsec_delete(): Nessun SPI per identificare l'associazione di protezione della fase 2.
[IKEv1]: Gruppo = x.x.x.x, IP = x.x.x, Rimozione del peer dalla tabella dei correlatori non riuscita. Nessuna corrispondenza.
Se il timeout di inattività è impostato su 30 minuti (impostazione predefinita), il tunnel viene scartato dopo 30 minuti se non passa alcun traffico. Il client VPN viene disconnesso dopo 30 minuti indipendentemente dal parametro del timeout di inattività e riceve l'errore PEER_DELETE-IKE_DELETE_UNSPECIFIED.
Configurare timeout di inattività e timeout di sessione su none per impostare il tunnel sempre in modo che non venga mai scartato anche quando si usano dispositivi di terze parti.
ASA
Eseguire il comando pn-idle-timeout in modalità di configurazione di Criteri di gruppo o in modalità di configurazione nome utente per configurare il periodo di timeout dell'utente:
hostname(config)#group-policy DfltGrpPolicy attributes hostname(config-group-policy)#vpn-idle-timeout none
Configurare un periodo di tempo massimo per le connessioni VPN con il comando vpn-session-timeout in modalità di configurazione criteri di gruppo o in modalità di configurazione nome utente:
hostname(config)#group-policy DfltGrpPolicy attributes hostname(config-group-policy)#vpn-session-timeout none
Dopo aver configurato tunnel-all, non è necessario configurare idle-timeout perché, anche se si configura VPN-idle timeout, non funziona come tutti i processi di traffico attraverso il tunnel (poiché tunnel-all è configurato).
Pertanto, il traffico (o anche il traffico generato dal PC) non consente il timeout di inattività.
Router Cisco IOS®
Eseguire il comando crypto ipsec security-association idle-timein modalità di configurazione globale o in modalità di configurazione mappa crittografica per configurare il timer di inattività della SA IPsec. Per impostazione predefinita, i timer di inattività SA IPsec sono disabilitati:
crypto ipsec security-association idle-time seconds
Il tempo viene misurato in secondi, in cui il timer di inattività consente a un peer inattivo di mantenere un'associazione di protezione. I valori validi per l'argomento secondi sono compresi tra 60 e 86400.
In una configurazione VPN IPsec tipica vengono utilizzati due elenchi degli accessi. Un elenco degli accessi viene usato per esentare il traffico destinato al tunnel VPN dal processo NAT. L'altro elenco degli accessi definisce il traffico da crittografare; ciò include un ACL crittografico in una configurazione LAN-to-LAN o un ACL con tunnel separato in una configurazione di accesso remoto. Quando gli ACL non sono configurati correttamente o sono mancati, il traffico scorre in una direzione attraverso il tunnel VPN o non viene inviato affatto attraverso il tunnel.
Verificare di aver associato l'ACL crittografico alla mappa crittografica eseguendo il comando crypto map match address in modalità di configurazione globale. Verificare di aver configurato tutti gli elenchi degli accessi per completare le configurazioni della VPN IPsec e che tali elenchi degli accessi definiscano il traffico corretto. Questo elenco contiene elementi da convalidare quando si sospetta che un ACL sia la causa dei problemi con la VPN IPsec.
Confermare l'esenzione NAT e gli ACL di crittografia specificare il traffico corretto. Se si hanno più tunnel VPN e più ACL crittografici, verificare che tali ACL non si sovrappongano. Verificare inoltre che il dispositivo sia configurato per l'utilizzo dell'ACL di esenzione NAT. Su un router, ciò significa che si sta eseguendo therroute-mapcommand. Sull'appliance ASA, si sta eseguendo il comando at (0). Per le configurazioni LAN-to-LAN e di accesso remoto è necessario un ACL di esenzione NAT.
Nell'esempio successivo, un router Cisco IOS® è configurato per esentare il traffico inviato tra le versioni 192.168.100.0 /24e 192.168.200.0 /24o192.168.1.0 /24da NAT. Il traffico destinato a qualsiasi altro luogo è soggetto a sovraccarico NAT:
access-list 110 deny ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255 access-list 110 deny ip 192.168.100.0 0.0.0.255 192.168.1.0 0.0.0.255 access-list 110 permit ip 192.168.100.0 0.0.0.255 any route-map nonat permit 10 match ip address 110 ip nat inside source route-map nonat interface FastEthernet0/0 overload
Gli ACL di esenzione NAT funzionano solo con l'indirizzo IP o le reti IP, come negli esempi citati (access-list noNAT), e devono essere identici agli ACL delle mappe crittografiche. Gli ACL di esenzione NAT non funzionano con i numeri di porta (ad esempio, 23, 25 e così via). In un ambiente VOIP, in cui le chiamate vocali tra le reti vengono comunicate tramite VPN, le chiamate vocali non funzionano se gli ACL NAT 0 non sono configurati correttamente. Prima di risolvere il problema, si consiglia di controllare lo stato della connettività VPN, in quanto il problema potrebbe essere causato da una configurazione errata degli ACL con esenzione NAT.
È possibile ricevere il messaggio di errore come mostrato in caso di configurazione errata negli ACL di esenzione NAT (nat 0).
%ASA-3-305005: No translation group found for udp src Outside:x.x.x.x/p dst Inside:y.y.y.y/p
Esempio non corretto:
access-list noNAT extended permit ip 192.168.100.0 255.255.255.0 192.168.200.0 255.255.255.0 eq 25
Se l'esenzione NAT (nat 0) non funziona correttamente, provare a rimuoverla ed eseguire il comando NAT 0. Accertarsi che gli ACL non siano arretrati e che siano del tipo corretto. Gli ACL di esenzione Crypto e NAT per le configurazioni da LAN a LAN devono essere scritti dal punto di vista del dispositivo su cui è configurato l'ACL. Pertanto, gli ACL devono specchiarsi tra loro. Nell'esempio, viene impostato un tunnel da LAN a LAN tra le versioni 192.168.100.0 /24e 192.168.200.0 /24.
ACL crittografico del router A:
access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255
ACL crittografico del router B:
access-list 110 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255
Anche se non illustrato, lo stesso concetto si applica alle appliance di sicurezza ASA. Nell'ASA, gli ACL con tunnel suddivisi per le configurazioni di accesso remoto devono fornire elenchi degli accessi standard che autorizzano il traffico sulla rete a cui devono accedere i client VPN. I router Cisco IOS® possono usare ACL estesi per i tunnel suddivisi. Nell'elenco degli accessi estesi, usare 'any' all'origine nell'ACL del tunnel suddiviso equivale a disabilitare lo split tunnel. Usare solo le reti di origine nell'ACL esteso per il tunnel suddiviso.
Esempio corretto:
access-list 140 permit ip 10.1.0.0 0.0.255.255 10.18.0.0 0.0.255.255
Esempio non corretto:
access-list 140 permit ip any 10.18.0.0 0.0.255.255
Cisco IOS®
router(config)#access-list 10 permit ip 192.168.100.0 router(config)#crypto isakmp client configuration group MYGROUP router(config-isakmp-group)#acl 10
Cisco ASA
securityappliance(config)#access-list 10 standard permit 192.168.100.0 255.255.255.0 securityappliance(config)#group-policy MYPOLICY internal securityappliance(config)#group-policy MYPOLICY attributes securityappliance(config-group-policy)#split-tunnel-policy tunnelspecified securityappliance(config-group-policy)#split-tunnel-network-list value 10
Configurazione dell'esenzione NAT in ASA versione 8.3 per il tunnel VPN da sito a sito:
È necessario stabilire una VPN da sito a sito tra HOASA e BOASA con entrambe le ASA versione 8.3. La configurazione di esenzione NAT su HOASA è simile a questa:
object network obj-local subnet 192.168.100.0 255.255.255.0 object network obj-remote subnet 192.168.200.0 255.255.255.0 nat (inside,outside) 1 source static obj-local obj-local destination static obj-remote objremote
Se il tunnel IPsec non è attivo, verificare che i criteri ISAKMP corrispondano ai peer remoti. Questo criterio ISAKMP è applicabile sia alla VPN IPsec da sito a sito (L2L) che alla VPN IPsec di accesso remoto. Se i client VPN Cisco o la VPN da sito a sito non sono in grado di stabilire il tunnel con il dispositivo remoto, verificare che i due peer contengano gli stessi valori di crittografia, hash, autenticazione e parametro Diffie-Hellman. Verificare quando il criterio peer remoto specifica una durata inferiore o uguale alla durata del criterio inviato dall'iniziatore. Se le durate non sono identiche, l'appliance di sicurezza utilizza la durata più breve. Se non esiste una corrispondenza accettabile, ISAKMP rifiuta la negoziazione e l'associazione di protezione non viene stabilita.
"Error: Unable to remove Peer TblEntry, Removing peer from peer table failed, no match!"
Questo è un esempio del messaggio di log dettagliato:
4|Mar 24 2010 10:21:50|713903: IP = X.X.X.X, Error: Unable to remove PeerTblEntry 3|Mar 24 2010 10:21:50|713902: IP = X.X.X.X, Removing peer from peer table failed, no match! 3|Mar 24 2010 10:21:50|713048: IP = X.X.X.X, Error processing payload: Payload ID: 1 4|Mar 24 2010 10:21:49|713903: IP = X.X.X.X, Information Exchange processing failed 5|Mar 24 2010 10:21:49|713904: IP = X.X.X.X, Received an un-encrypted NO_PROPOSAL_CHOSEN notify message, drop
Questo messaggio viene in genere visualizzato a causa di una mancata corrispondenza delle policy ISAKMP o di un'istruzione NAT 0 mancante. Viene inoltre visualizzato il messaggio seguente:
Error Message %ASA-6-713219: Queueing KEY-ACQUIRE messages to be processed when P1 SA is complete.
Questo messaggio indica che i messaggi della fase 2 sono in coda dopo il completamento della fase 1. Questo messaggio di errore è dovuto a uno dei motivi seguenti:
Mancata corrispondenza nella fase su uno dei peer
ACL blocca i peer dal completamento della fase 1
Questo messaggio viene in genere visualizzato dopo che la rimozione del peer dalla tabella peer non è riuscita. Messaggio di errore no match!. Se il client VPN Cisco non riesce a connettere il dispositivo headend, il problema può essere la mancata corrispondenza della policy ISAKMP. Il dispositivo headend deve corrispondere a una delle proposte IKE del client VPN Cisco. Per il criterio ISAKMP e il set di trasformazioni IPsec usati sull'appliance ASA, il client VPN Cisco non può usare un criterio con una combinazione di DES e SHA. Se si utilizza DES, è necessario utilizzare MD5 per l'algoritmo hash oppure è possibile utilizzare altre combinazioni quali 3DES con SHA e 3DES con MD5.
Verificare che i dispositivi di crittografia, quali router e appliance di sicurezza ASA, dispongano delle informazioni di routing corrette per inviare il traffico sul tunnel VPN. Se dietro il dispositivo gateway sono presenti altri router, verificare che possano raggiungere il tunnel e quali reti si trovano dall'altro lato. Un componente chiave del routing in una distribuzione VPN è l'Reverse Route Injection (RRI). RRI posiziona le voci dinamiche per le reti remote o i client VPN nella tabella di routing di un gateway VPN. Queste route sono utili al dispositivo su cui sono installate e ad altri dispositivi nella rete, in quanto le route installate da RRI possono essere ridistribuite tramite protocolli di routing quali EIGRP o OSPF.
In una configurazione da LAN a LAN, è importante che ciascun endpoint disponga di una o più route alle reti in cui deve crittografare il traffico. Nell'esempio, il router A deve avere i percorsi alle reti dietro il router B fino alle porte10.89.129.2. Il router B deve avere un percorso simile alle porte 192.168.100.0 /24. Il primo modo per accertarsi che ciascun router sia a conoscenza dei percorsi appropriati è configurare i percorsi statici per ciascuna rete di destinazione. Ad esempio, per il router A è possibile configurare le seguenti istruzioni di routing:
ip route 0.0.0.0 0.0.0.0 172.22.1.1 ip route 192.168.200.0 255.255.255.0 10.89.129.2 ip route 192.168.210.0 255.255.255.0 10.89.129.2 ip route 192.168.220.0 255.255.255.0 10.89.129.2 ip route 192.168.230.0 255.255.255.0 10.89.129.2
Se il router A è stato sostituito con un'ASA, la configurazione può essere simile alla seguente:
route outside 0.0.0.0 0.0.0.0 172.22.1.1 route outside 192.168.200.0 255.255.255.0 10.89.129.2 route outside 192.168.200.0 255.255.255.0 10.89.129.2 route outside 192.168.200.0 255.255.255.0 10.89.129.2 route outside 192.168.200.0 255.255.255.0 10.89.129.2
Se dietro a ciascun endpoint è presente un numero elevato di reti, la configurazione delle route statiche diventa difficile da gestire. È invece consigliabile utilizzare Reverse Route Injection. RRI posiziona le route della tabella di routing per tutte le reti remote elencate nell'ACL crittografico. Ad esempio, l'ACL crittografico e la mappa crittografica del router A possono avere questo aspetto:
access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255 access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.210.0 0.0.0.255 access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.220.0 0.0.0.255 access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.230.0 0.0.0.255 crypto map myMAP 10 ipsec-isakmp set peer 10.89.129.2 reverse-route set transform-set mySET match address 110
Se il router A è stato sostituito da ASA, la configurazione può avere questo aspetto:
access-list cryptoACL extended permit ip 192.168.100.0 255.255.255.0 192.168.200.0 255.255.255.0 access-list cryptoACL extended permit ip 192.168.100.0 255.255.255.0 192.168.210.0 255.255.255.0 access-list cryptoACL extended permit ip 192.168.100.0 255.255.255.0 192.168.220.0 255.255.255.0 access-list cryptoACL extended permit ip 192.168.100.0 255.255.255.0 192.168.230.0 255.255.255.0 crypto map myMAP 10 match address cryptoACL crypto map myMAP 10 set peer 10.89.129.2 crypto map myMAP 10 set transform-set mySET crypto map mymap 10 set reverse-route
In una configurazione di Accesso remoto, le modifiche di routing non sono sempre necessarie. Tuttavia, se dietro il router gateway VPN o l'appliance di sicurezza sono presenti altri router, questi devono imparare il percorso ai client VPN. In questo esempio, si immagini che ai client VPN vengano assegnati indirizzi compresi nell'intervallo 10.0.0.0 /24quando si connettono.
Se tra il gateway e gli altri router non è in uso alcun protocollo di routing, è possibile usare le route statiche sui router come il router 2:
ip route 10.0.0.0 255.255.255.0 192.168.100.1
Se tra il gateway e altri router è in uso un protocollo di routing, ad esempio EIGRP o OSPF, si consiglia di utilizzare il comando Reverse Route Injection come descritto. RRI aggiunge automaticamente le route per il client VPN alla tabella di routing del gateway. Queste route possono quindi essere distribuite agli altri router della rete.
Router Cisco IOS®:
crypto dynamic-map dynMAP 10 set transform-set mySET reverse-route crypto map myMAP 60000 ipsec-isakmp dynamic dynMAP
Cisco ASA Security Appliance:
crypto dynamic-map dynMAP 10 set transform-set mySET crypto dynamic-map dynMAP 10 set reverse-route crypto map myMAP 60000 ipsec-isakmp dynamic dynMAP
Il problema di routing si verifica se il pool di indirizzi IP assegnati ai client VPN si sovrappone alle reti interne del dispositivo headend. Per ulteriori informazioni, fare riferimento alla sezione Sovrapposizione di reti private .
Assicurarsi che gli algoritmi di crittografia IPsec e hash utilizzati dal set di trasformazioni su entrambe le estremità siano gli stessi. Per ulteriori informazioni, consultare la sezione Command Reference della guida alla configurazione di Cisco Security Appliance. Per il criterio ISAKMP e il set di trasformazioni IPsec usati sull'appliance ASA, il client VPN Cisco non può usare un criterio con una combinazione di DES e SHA. Se si utilizza DES, è necessario utilizzare MD5 per l'algoritmo hash oppure le altre combinazioni, 3DES con SHA e 3DES con MD5.
Se i peer statici e dinamici sono configurati sulla stessa mappa crittografica, l'ordine delle voci della mappa crittografica è critico. Il numero di sequenza della voce della mappa crittografica dinamica deve essere maggiore di tutte le altre voci della mappa crittografica statica. Se le voci statiche sono numerate più in alto rispetto alle voci dinamiche, le connessioni con questi peer hanno esito negativo e i debug vengono visualizzati come mostrato di seguito:
IKEv1]: Group = x.x.x.x, IP = x.x.x.x, QM FSM error (P2 struct &0x49ba5a0, mess id 0xcd600011)! [IKEv1]: Group = x.x.x.x, IP = x.x.x.x, Removing peer from correlator table failed, no match!
È consentita una sola mappa crittografica dinamica per ciascuna interfaccia nell'appliance di sicurezza. Questo è un esempio di mappa crittografica con numerazione corretta che contiene una voce statica e una voce dinamica. La voce dinamica ha il numero di sequenza più alto e è stata lasciata spazio sufficiente per aggiungere altre voci statiche:
crypto dynamic-map cisco 20 set transform-set myset crypto map mymap 10 match address 100 crypto map mymap 10 set peer 172.16.77.10 crypto map mymap 10 set transform-set myset crypto map mymap interface outside crypto map mymap 60000 ipsec-isakmp dynamic ciscothe
I nomi delle mappe crittografiche distinguono tra maiuscole e minuscole. Questo messaggio di errore può essere visualizzato anche quando la sequenza della mappa crittografica dinamica non è corretta, il che provoca l'accesso del peer alla mappa crittografica errata. Anche l'elenco degli accessi crittografati che definisce il traffico non corrisponde:%ASA-3-713042: Iniziatore IKE: impossibile trovare il criterio:
In uno scenario in cui più tunnel VPN vengono terminati nella stessa interfaccia, creare una mappa crittografica con lo stesso nome (è consentita una sola mappa crittografica per interfaccia), ma con un numero di sequenza diverso. Ciò vale sia per il router sia per l'ASA. Per ulteriori informazioni, fare riferimento al documento ASA: Aggiungere un nuovo tunnel o un accesso remoto a una VPN L2L esistente - Cisco per ulteriori informazioni sulla configurazione della mappa crittografica per gli scenari L2L e VPN ad accesso remoto.
Creare e gestire il database dei record specifici della connessione per IPSec. Per una configurazione VPN IPsec da LAN a LAN (L2L) di un'appliance di sicurezza ASA, specificare <name>del gruppo di tunnel come indirizzo IP peer remoto (estremità tunnel remota) nel comando tunnel-group <name> digitare ipsec-l2l. L'indirizzo IP del peer deve corrispondere al nome del gruppo di tunnel e ai comandi set address della mappa crittografica. Quando si configura la VPN con ASDM, il nome del gruppo di tunnel viene generato automaticamente con l'indirizzo IP peer corretto. Se l'indirizzo IP del peer non è configurato correttamente, i registri possono contenere questo messaggio, che può essere risolto configurando correttamente l'indirizzo IP del peer:
[IKEv1]: Group = DefaultL2LGroup, IP = x.x.x.x, ERROR, had problems decrypting packet, probably due to mismatched pre-shared key. Aborting
Quando l'indirizzo IP del peer non è stato configurato correttamente sulla configurazione crittografica ASA, l'ASA non può stabilire il tunnel VPN e si blocca solo nella fase MM_WAIT_MSG4. Per risolvere il problema, correggere l'indirizzo IP del peer nella configurazione. Di seguito viene riportato l'output del comando show crypto isakmp sacommand quando il tunnel VPN si blocca in stato MM_WAIT_MSG4:
hostname#show crypto isakmp sa
1 IKE Peer: XX.XX.XX.XX
Type : L2L Role : initiator
Rekey : no State : MM_WAIT_MSG4
%ASA-3-713206: Tunnel Rejected: Conflicting protocols specified by tunnel-group and group-policy
Questo messaggio viene visualizzato quando un tunnel viene eliminato perché il tunnel consentito specificato in Criteri di gruppo è diverso da quello consentito nella configurazione del gruppo di tunnel.
group-policy hf_group_policy attributes vpn-tunnel-protocol l2tp-ipsec username hfremote attributes vpn-tunnel-protocol l2tp-ipsec Both lines read: vpn-tunnel-protocol ipsec l2tp-ipsec
Attivare IPSec Nei Criteri di gruppo predefiniti selezionare i protocolli esistenti nei Criteri di gruppo predefiniti.
group-policy DfltGrpPolicy attributes vpn-tunnel-protocol L2TP-IPSec IPSec webvpn
Se un tunnel LAN-LAN e un tunnel VPN ad accesso remoto sono configurati sulla stessa mappa crittografica, al peer LAN-LAN vengono richieste informazioni XAUTH e il tunnel LAN-LAN non riesce con CONF_XAUTH nell'output del comando show crypto isakmp. Questo è un esempio dell'output dell'associazione di protezione:
Router#show crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id slot status X.X.X.X Y.Y.Y.Y CONF_XAUTH 10223 0 ACTIVE X.X.X.X Z.Z.Z.Z CONF_XAUTH 10197 0 ACTIVE
Questo problema si verifica solo con Cisco IOS®, dove l'appliance ASA non è interessata dal problema, in quanto usa gruppi di tunnel. Eseguire theno-xauthkeyword quando si immette la chiave ISAKMP, in modo che il dispositivo non richieda al peer informazioni XAUTH (nome utente e password). Questa parola chiave disabilita XAUTH per i peer IPsec statici. Eseguire un comando simile a questo sul dispositivo in cui la VPN L2L e la VPN per l'Autorità di registrazione sono configurate sulla stessa mappa crittografica:
router(config)#crypto isakmp key cisco123 address 172.22.1.164 no-xauth
Nello scenario in cui l'ASA agisce come server Easy VPN, il client Easy VPN non può connettersi all'headend a causa di un problema di Xauth. Per risolvere il problema, disabilitare l'autenticazione dell'utente nell'appliance ASA:
ASA(config)#tunnel-group example-group type ipsec-ra ASA(config)#tunnel-group example-group ipsec-attributes ASA(config-tunnel-ipsec)#isakmp ikev1-user-authentication none
Per ulteriori informazioni sul comando isakmp ikev1-user-authentication, consultare la sezione Varie di questo documento.
Quando l'intervallo di indirizzi IP assegnato al pool VPN non è sufficiente, è possibile estendere la disponibilità degli indirizzi IP in due modi:
Rimuovere l'intervallo esistente e definire il nuovo intervallo:
CiscoASA(config)#no ip local pool testvpnpool 10.76.41.1-10.76.41.254 CiscoASA(config)#ip local pool testvpnpool 10.76.41.1-10.76.42.254
Quando è necessario aggiungere subnet non contigue al pool VPN, è possibile definire due pool VPN separati e quindi specificarli negli "attributi del gruppo di tunnel ". Ecco un esempio:
CiscoASA(config)#ip local pool testvpnpoolAB 10.76.41.1-10.76.42.254 CiscoASA(config)#ip local pool testvpnpoolCD 10.76.45.1-10.76.45.254 CiscoASA(config)#tunnel-group test type remote-access CiscoASA(config)#tunnel-group test general-attributes CiscoASA(config-tunnel-general)#address-pool (inside) testvpnpoolAB testvpnpoolCD CiscoASA(config-tunnel-general)#exit
L'ordine in cui vengono specificati i pool è importante perché l'ASA alloca gli indirizzi da questi pool nell'ordine in cui i pool vengono visualizzati in questo comando. Le impostazioni dei pool di indirizzi nel comando pool di indirizzi di Criteri di gruppo sostituiscono sempre le impostazioni del pool locale nel comando tunnel-group address-pool.
In caso di problemi di latenza su una connessione VPN, verificare le seguenti condizioni per risolvere il problema:
Verificare se il valore MSS del pacchetto può essere ulteriormente ridotto.
Se si utilizza IPsec/tcp anziché IPsec/udp, configurare preserve-vpn-flow.
Ricaricare Cisco ASA.
I client VPN Cisco non possono eseguire l'autenticazione quando Xauth viene utilizzato con il server Radius.
In alcuni casi, quando Xauth scade, è possibile aumentare il valore di timeout per il server AAA per risolvere il problema. Ad esempio:
Hostname(config)#aaa-server test protocol radius hostname(config-aaa-server-group)#aaa-server test host 10.2.3.4 hostname(config-aaa-server-host)#timeout 10
I client VPN Cisco non sono in grado di eseguire l'autenticazione quando X-auth viene utilizzato con il server Radius.
Inizialmente, verificare che l'autenticazione funzioni correttamente. Per risolvere il problema, verificare prima l'autenticazione con il database locale sull'appliance ASA.
tunnel-group tggroup general-attributes
authentication-server-group none
authentication-server-group LOCAL
exit
Se questa operazione funziona, il problema è relativo alla configurazione del server Radius. Verificare la connettività del server Radius dall'appliance ASA. Se il ping viene eseguito senza alcun problema, controllare la configurazione relativa a Radius sull'appliance ASA e la configurazione del database sul server Radius. È possibile eseguire il comando debug radius per risolvere i problemi relativi al raggio. Per l'output del comando sampledebug radiusoutput, consultare questo output di esempio. Prima di usare il comando debugsull'appliance ASA, consultare la documentazioneMessaggio di avviso.
Gli utenti di client VPN Cisco ricevono questo errore quando tentano la connessione con il dispositivo VPN headend.
Questo problema può essere correlato all'assegnazione del pool IP tramite ASA, server Radius, server DHCP o tramite il server Radius che funge da server DHCP. Eseguire il comando debug crypto per verificare che la netmask e gli indirizzi IP siano corretti. Verificare inoltre che il pool non includa l'indirizzo di rete e l'indirizzo di broadcast. I server Radius devono assegnare gli indirizzi IP corretti ai client.
Questo problema si verifica anche a causa di un errore di autenticazione estesa. Per risolvere il problema, controllare il server AAA. Controllare la password di autenticazione del server e del client. Per risolvere il problema, ricaricare il server AAA.
Per risolvere questo problema, è inoltre possibile disabilitare la funzione di rilevamento delle minacce. In caso di ritrasmissioni multiple per associazioni di sicurezza (SA) diverse e incomplete, l'ASA con la funzione di rilevamento delle minacce abilitata ritiene che si sia verificato un attacco di scansione e le porte VPN sono contrassegnate come il principale responsabile del danno. Disabilitare la funzione di rilevamento delle minacce in quanto potrebbe causare problemi di sovraccarico sull'elaborazione dell'ASA. Per disabilitare il rilevamento delle minacce, eseguire i comandi seguenti:
no threat-detection basic-threat no threat-detection scanning-threat shun no threat-detection statistics no threat-detection rate
Questa opzione può essere utilizzata come soluzione per verificare se il problema viene risolto. Accertarsi di disabilitare il rilevamento delle minacce sull'appliance Cisco ASA in quanto compromette diverse funzionalità di sicurezza, ad esempio la riduzione dei tentativi di scansione, le licenze DoS con SPI non valido, i pacchetti che non superano il controllo delle applicazioni e le sessioni incomplete.
Questo problema si verifica anche quando un set di trasformazioni non è configurato correttamente e una corretta configurazione del set di trasformazioni risolve il problema.
Per risolvere il problema, provare le soluzioni seguenti:
Dopo aver stabilito il client VPN, il tunnel IPsec con il dispositivo headend VPN (ASA/Cisco IOS® Router), gli utenti del client VPN possono tuttavia accedere alle risorse della rete INTERNA (10.10.10.0/24). non possono accedere alla rete DMZ (10.1.1.0/24).
Diagramma
Verificare il tunnel suddiviso. Nessuna configurazione NAT aggiunta al dispositivo headend per accedere alle risorse nella rete DMZ.
Configurazione ASA
Questa configurazione mostra come configurare l'esenzione NAT per la rete DMZ per consentire agli utenti VPN di accedere alla rete DMZ:
object network obj-dmz subnet 10.1.1.0 255.255.255.0 object network obj-vpnpool subnet 192.168.1.0 255.255.255.0 nat (inside,dmz) 1 source static obj-dmz obj-dmz destination static obj-vpnpool obj-vpnpool
Dopo aver aggiunto una nuova voce per la configurazione NAT, cancellare la traduzione NAT.
Clear xlate Clear local
Se il tunnel è stato stabilito, andare sul client VPN Cisco e scegliere Stato > Dettagli route per verificare che i percorsi protetti siano visualizzati sia per la rete DMZ che per la rete INSIDE.
Per ulteriori informazioni, fare riferimento al documento ASA: Aggiungere un nuovo tunnel o un nuovo accesso remoto a una VPN L2L esistente - Cisco per i passaggi necessari per aggiungere un nuovo tunnel VPN o una VPN di accesso remoto a una configurazione VPN L2L già esistente. Per ulteriori informazioni, fare riferimento al documento ASA: Consentire il tunneling ripartito per i client VPN sull'esempio di configurazione ASA per istruzioni dettagliate su come consentire ai client VPN di accedere a Internet e contemporaneamente eseguire il tunneling in una appliance Cisco Adaptive Security (ASA) serie 5500.
Dopo aver stabilito il tunnel, se i client VPN non sono in grado di risolvere il DNS, il problema può essere correlato alla configurazione del server DNS nel dispositivo headend (ASA). Verificare la connettività tra i client VPN e il server DNS. Le configurazioni del server DNS devono essere configurate in Criteri di gruppo e applicate in Criteri di gruppo negli attributi generali del gruppo di tunnel:
!--- Create the group policy named vpn3000 and !--- specify the DNS server IP address(172.16.1.1) !--- and the domain name(cisco.com) in the group policy. group-policy vpn3000 internal group-policy vpn3000 attributes dns-server value 172.16.1.1 default-domain value cisco.com !--- Associate the group policy(vpn3000) to the tunnel group !--- with the default-group-policy. tunnel-group vpn3000 general-attributes default-group-policy vpn3000
Il client VPN non può eseguire il ping degli host o dei server della rete remota o dell'headend interno per nome. Per risolvere il problema, è necessario abilitare la configurazione split-dns sull'appliance ASA.
Il tunnel split permette ai client IPsec di accedere in remoto di indirizzare condizionalmente i pacchetti sul tunnel IPsec in forma crittografata o a un'interfaccia di rete in forma decrittografata e non crittografata, dove vengono indirizzati alla destinazione finale.
Per impostazione predefinita, il tunnel diviso è disabilitato. È possibile visualizzare il comando commandtunnelalltraffic in esecuzione.
split-tunnel-policy {tunnelall | tunnelspecified | excludespecified}
L'opzione excludespecified è supportata solo per i client VPN Cisco, non per i client EZVPN.
ciscoasa(config-group-policy)#split-tunnel-policy excludespecified
Per esempi dettagliati di configurazione dello split-tunnel, consultare i seguenti documenti:
Questa funzionalità è utile per il traffico VPN che entra in un'interfaccia, ma che viene quindi instradato all'esterno della stessa interfaccia. Ad esempio, in una rete VPN hub e spoke in cui l'appliance di sicurezza è l'hub e le reti VPN remote sono spoke. Il traffico di comunicazione Spoke-to-Spoke deve passare all'appliance di sicurezza e poi di nuovo all'altro spoke. Eseguire la stessa configurazione di traffico di sicurezza per consentire al traffico di entrare e uscire dalla stessa interfaccia:
securityappliance(config)#same-security-traffic permit intra-interface
Gli utenti di Accesso remoto si connettono alla VPN e possono connettersi solo alle reti locali. Per un esempio di configurazione più dettagliata, fare riferimento a ASA: Consente l'accesso LAN locale per i client VPN.
Problema
Se non è possibile accedere alla rete interna dopo aver stabilito il tunnel, controllare l'indirizzo IP assegnato al client VPN che si sovrappone alla rete interna dietro il dispositivo headend.
Soluzione
Verificare che gli indirizzi IP del pool assegnati ai client VPN, la rete interna del dispositivo headend e la rete interna del client VPN si trovino in reti diverse. È possibile assegnare la stessa rete principale con subnet diverse, tuttavia, talvolta possono verificarsi problemi di routing. Per ulteriori esempi, vedere il diagramma e l'esempio della sezione Impossibile accedere ai server nella DMZ.
Solo tre client VPN possono connettersi ad ASA/VPN e la connessione del quarto client non riesce. In caso di errore, viene visualizzato il seguente messaggio di errore:
Secure VPN Connection terminated locally by the client. Reason 413: User Authentication failed.
tunnel rejected; the maximum tunnel count has been reached
Nella maggior parte dei casi, questo problema è correlato a un'impostazione di accesso simultaneo nei Criteri di gruppo e al limite massimo di sessione. Per risolvere il problema, provare le soluzioni seguenti:
Se la casella di controllo Eredita in ASDM è selezionata, è consentito solo il numero predefinito di accessi simultanei per l'utente. Il valore predefinito per gli accessi simultanei è 3. Per risolvere il problema, aumentare il valore per gli accessi simultanei.
Avviare ASDM, quindi selezionare Configurazione > VPN > Criteri di gruppo.
Scegliere il raggruppamento appropriato e fare clic sul pulsante Modifica.
Nella scheda Generale, annullare la casella di controllo Eredita per Login simultanei in Impostazioni connessione. Scegliere un valore appropriato nel campo.
Il valore minimo per questo campo è 0, che disabilita gli accessi e impedisce l'accesso degli utenti. Quando si accede con lo stesso account utente da un PC diverso, la sessione corrente (la connessione stabilita da un altro PC con lo stesso account utente) viene terminata e viene stabilita la nuova sessione. Si tratta del comportamento predefinito ed è indipendente dagli accessi simultanei VPN.
Completare la procedura seguente per configurare il numero desiderato di accessi simultanei. Nell'esempio, è stato scelto il valore 20 come valore desiderato:
ciscoasa(config)#group-policy Bryan attributes ciscoasa(config-group-policy)#vpn-simultaneous-logins 20
Per ulteriori informazioni sul comando, consultare la guida di riferimento dei comandi di Cisco Security Appliance. Eseguire il comando vpn-sessiondb max-session-limiter nella modalità di configurazione globale per limitare le sessioni VPN a un valore inferiore a quello consentito dall'appliance di sicurezza. Eseguire la versione di questo comando per rimuovere il limite di sessione ed eseguire di nuovo il comando per sovrascrivere l'impostazione corrente:
vpn-sessiondb max-session-limit {session-limit}
Nell'esempio viene mostrato come impostare un limite massimo di sessioni VPN di 450:
hostname#vpn-sessiondb max-session-limit 450
Messaggio di errore:
20932 10/26/2007 14:37:45.430 SEV=3 AUTH/5 RPT=1863 10.19.187.229 Authentication rejected: Reason = Simultaneous logins exceeded for user handle = 623, server = (none), user = 10.19.187.229, domain = <not specified>
Completare la procedura seguente per configurare il numero desiderato di accessi simultanei. È inoltre possibile impostare gli accessi simultanei su 5 per questa associazione di protezione. Scegliere Configurazione > Gestione utente > Gruppi > Modifica 10.19.187.229 > Generale > Accessi simultanei e modificare il numero di accessi in 5.
Dopo aver stabilito il tunnel IPsec, l'applicazione o la sessione non viene avviata attraverso il tunnel.
Eseguire il comando ping per controllare la rete o verificare se il server applicazioni è raggiungibile dalla rete. Può trattarsi di un problema con le dimensioni massime del segmento (MSS) per i pacchetti temporanei che attraversano un router o un dispositivo /ASA, in particolare i segmenti TCP con bit SYN impostato.
Eseguire questi comandi per modificare il valore MSS nell'interfaccia esterna (interfaccia terminale del tunnel) del router:
Router>enable Router#configure terminal Router(config)#interface ethernet0/1 Router(config-if)#ip tcp adjust-mss 1300 Router(config-if)#end
Questi messaggi visualizzano l'output del comando debug per TCP MSS:
Router#debug ip tcp transactions Sep 5 18:42:46.247: TCP0: state was LISTEN -> SYNRCVD [23 -> 10.0.1.1(38437)] Sep 5 18:42:46.247: TCP: tcb 32290C0 connection to 10.0.1.1:38437, peer MSS 1300, MSS is 1300 Sep 5 18:42:46.247: TCP: sending SYN, seq 580539401, ack 6015751 Sep 5 18:42:46.247: TCP0: Connection to 10.0.1.1:38437, advertising MSS 1300 Sep 5 18:42:46.251: TCP0: state was SYNRCVD -> ESTAB [23 -> 10.0.1.1(38437)]
Il valore MSS viene impostato su 1300 sul router come configurato. Per ulteriori informazioni, fare riferimento a ASA e Cisco IOS®: Frammentazione VPN.
Non è possibile accedere a Internet correttamente o il trasferimento viene rallentato tramite il tunnel perché visualizza un messaggio di errore relativo alle dimensioni MTU e i problemi di valore MSS. Per risolvere il problema, consultare il documento:
Non è possibile avviare il tunnel VPN dall'interfaccia ASA e dopo aver stabilito il tunnel. Il client VPN o remoto non può eseguire il ping dell'interfaccia interna dell'ASA sul tunnel VPN. Ad esempio, il client VPN non può avviare una connessione SSH o HTTP alle appliance ASA all'interno dell'interfaccia su un tunnel VPN.
Non è possibile eseguire il ping dell'interfaccia interna dall'altra estremità del tunnel a meno che il comando management-access non sia configurato in modalità di configurazione globale.
ASA-02(config)#management-access inside ASA-02(config)#show management-access management-access inside
Questo comando assiste anche nell'inizializzazione ssh o nella connessione http per l'interfaccia interna dell'ASA tramite un tunnel VPN. Le informazioni sono valide anche per le interfacce DMZ. Ad esempio, se si desidera eseguire il ping dell'interfaccia DMZ di /ASA o avviare un tunnel dall'interfaccia DMZ, è necessario eseguire il comando DMZ management-access.
ASA-02(config)#management-access DMZ
Se il client VPN non è in grado di connettersi, verificare che le porte ESP e UDP siano aperte. Tuttavia, se tali porte non sono aperte, provare a connettersi al protocollo TCP 10000 selezionando questa porta nella voce VPN client connection. Fare clic con il pulsante destro del mouse su Elabora > scheda Trasporto > IPsec su TCP.
Non è possibile passare il traffico attraverso un tunnel VPN.
Questo problema può verificarsi anche quando i pacchetti ESP sono bloccati. Per risolvere il problema, riconfigurare il tunnel VPN. Questa condizione si può anche verificare quando i dati non sono crittografati, ma solo decrittografati sul tunnel VPN, come mostrato in questo output:
ASA# sh crypto ipsec sa peer x.x.x.x
peer address: y.y.y.y
Crypto map tag: IPSec_map, seq num: 37, local addr: x.x.x.x
access-list test permit ip host xx.xx.xx.xx host yy.yy.yy.yy
local ident (addr/mask/prot/port): (xx.xx.xx.xx/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (yy.yy.yy.yy/255.255.255.255/0/0)
current_peer: y.y.y.y
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 393, #pkts decrypt: 393, #pkts verify: 393
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0
Per risolvere il problema, verificare le seguenti condizioni:
Se gli elenchi degli accessi crittografici corrispondono al sito remoto e gli elenchi degli accessi NAT 0 sono corretti.
Se il routing è corretto e il traffico raggiunge l'esterno dell'interfaccia, che passa all'interno, l'output di esempio mostra che la decrittografia è completa, ma la crittografia non si verifica.
Se il comando show enable connection-vpn è configurato sull'appliance ASA. Se non è configurato, configurare questo comando perché esclude il traffico VPN/crittografato all'ASA dal controllo ACL dell'interfaccia.
Si desidera utilizzare più peer di backup per un singolo tunnel VPN.
La configurazione di più peer equivale al provisioning di un elenco di fallback. Per ogni tunnel, l'appliance di sicurezza tenta di negoziare con il primo peer dell'elenco. Se il peer non risponde, l'appliance di sicurezza scorre verso il basso fino a quando un peer non risponde o non ci sono altri peer nell'elenco. L'ASA ha una mappa crittografica già configurata come peer primario. Il peer secondario può essere aggiunto dopo quello primario. In questa configurazione di esempio il peer primario viene indicato come X.X.X.X e il peer di backup come Y.Y.Y.Y:
ASA(config)#crypto map mymap 10 set peer X.X.X.X Y.Y.Y.Y
Per disabilitare temporaneamente il tunnel VPN e riavviare il servizio, completare la procedura descritta in questa sezione.
Eseguire il comando crypto map interface in modalità di configurazione globale per rimuovere una mappa crittografica precedentemente definita impostata su un'interfaccia. Eseguire la forma di questo comando per rimuovere il set di mappe crittografiche dall'interfaccia.
hostname(config)#no crypto map map-name interface interface-name
Con questo comando viene rimossa una mappa crittografica impostata su un'interfaccia dell'appliance di sicurezza attiva e il tunnel VPN IPsec viene impostato su inattivo nell'interfaccia. Per riavviare il tunnel IPsec su un'interfaccia, è necessario assegnare una mappa crittografica impostata a un'interfaccia prima che quest'ultima possa fornire i servizi IPsec.
hostname(config)#crypto map map-name interface interface-name
Quando sul gateway VPN è configurato un numero elevato di tunnel, alcuni tunnel non passano il traffico. L'ASA non riceve pacchetti crittografati per questi tunnel.
Questo problema si verifica perché l'ASA non riesce a passare i pacchetti crittografati attraverso i tunnel. Nella tabella ASP vengono create regole di crittografia duplicate.
L'%ASA-5-713904: Group = DefaultRAGroup, IP = 192.0.2.0,... non supportato Modalità di transazione v2 versione. Viene visualizzato il messaggio di errore Terminator del tunnel.
Il motivo del messaggio di errore v2 relativo alla modalità di transazione è che ASA supporta solo la versione v6 della configurazione in modalità IKE e non la versione precedente in modalità v2. Utilizzare la configurazione della modalità IKE v6 per risolvere l'errore.
L'%ASA-6-722036: Group < client-group > User < xxxx > IP < x.x.x.x> Transmitting large packet 1220 (soglia 1206): nei log dell'ASA viene visualizzato il messaggio di errore. Che cosa significa questo registro e come è possibile risolverlo?
Questo messaggio di registro indica che è stato inviato un pacchetto di grandi dimensioni al client. L'origine del pacchetto non è a conoscenza dell'MTU del client. Ciò può essere dovuto alla compressione di dati non comprimibili. È possibile disattivare la compressione SVC con il comando vc compression none, che risolve il problema.
Se si è abilitato QoS su un'estremità del tunnel VPN, è possibile ricevere questo messaggio di errore:
IPSEC: Received an ESP packet (SPI= 0xDB6E5A60, sequence number= 0x7F9F) from 10.18.7.11 (user= ghufhi) to 172.16.29.23 that failed anti-replay check
Questo messaggio viene in genere generato quando un'estremità del tunnel esegue la funzionalità QoS. Questo si verifica quando viene rilevato un pacchetto non in ordine. È possibile disabilitare QoS per arrestare questa operazione, ma può essere ignorato finché il traffico può attraversare il tunnel.
Quando si esegue il comando crypto map mymap 20 ipsec-isakmpè possibile ricevere questo errore: AVVISO: voce mappa crittografica incompleta
Ad esempio:
ciscoasa(config)#crypto map mymap 20 ipsec-isakmp WARNING: crypto map entry incomplete
Questo è un avviso normale quando si definisce una nuova mappa crittografica; un promemoria che indica che è necessario configurare parametri quali access-list (indirizzo corrispondente), transform set e peer address prima che possano funzionare correttamente. Inoltre, è normale vedere la prima riga che si digita per definire la mappa crittografica e non viene visualizzata nella configurazione.
Impossibile passare un pacchetto ping di grandi dimensioni attraverso il tunnel VPN. Quando si tenta di passare pacchetti ping di grandi dimensioni, viene visualizzato l'errore%ASA-4-40024: IDS:2151 Grande pacchetto ICMP da a su interfaccia esterna.
Disabilitare le firme 2150 e 2151 per risolvere il problema. Dopo aver disattivato le firme, il comando ping funziona correttamente. Per disattivare le firme, eseguire i comandi seguenti:
Nei messaggi di log dell'appliance ASA è stato visualizzato questo messaggio:
Errore:- %|ASA-4-402119: IPSEC: È stato ricevuto un pacchetto di protocollo (SPI=spi, numero di sequenza= num_seq) da remote_IP (nome utente) a local_IP che non ha superato il controllo anti-replay.
Per risolvere l'errore, eseguire il comando crypto ipsec security-association replay window-size per modificare le dimensioni della finestra.
hostname(config)#crypto ipsec security-association replay window-size 1024
Cisco consiglia di utilizzare la finestra full 1024 per eliminare eventuali problemi di anti-replay.
Pochi host non sono in grado di connettersi a Internet. questo messaggio di errore viene visualizzato nel syslog: Messaggio di errore - %ASA-4-407001: Nega traffico per nome_interfaccia:indirizzo_interno dell'host locale. È stato superato il limite di licenze per numero
Questo messaggio di errore viene visualizzato quando il numero di utenti supera il limite di utenti per la licenza utilizzata. Per risolvere il problema, aggiornare la licenza a un numero maggiore di utenti. La licenza utente può includere 50, 100 o un numero illimitato di utenti, in base alle esigenze.
Il messaggio di errore - %VPN_HW-4-PACKET_ERROR: indica che il pacchetto ESP con HMAC ricevuto dal router non corrisponde. Questo errore può essere causato dai problemi seguenti:
Modulo hardware VPN difettoso
Pacchetto ESP danneggiato
Per risolvere questo messaggio di errore:
Ignorare i messaggi di errore a meno che non vi siano interruzioni del traffico.
In caso di interruzione del traffico, sostituire il modulo.
Questo messaggio di errore viene visualizzato quando si cerca di aggiungere una VLAN consentita sulla porta trunk di uno switch: Comando rifiutato: prima di tutto, eliminare la connessione crittografica tra la VLAN XXXX e la VLAN XXXX. Il edge trunk della WAN non può essere modificato per consentire altre VLAN. Se non è possibile aggiungere VLAN nel trunk della VPN IPSEC, il comando verrà rifiutato in quanto darà luogo a una VLAN di interfaccia connessa tramite crittografia appartenente all'elenco di VLAN consentite e ciò rappresenterà una potenziale violazione della sicurezza IPSec.
Nota: Questo comportamento si applica a tutte le porte trunk.
Anziché usare il comando no switchport trunk allowed vlan (vlan list), usare il comando switchport trunk allowed vlan o il comando "switchport trunk allowed vlan remove (vlan list)".
Questo errore si verifica quando si tenta di eseguire il telnet da un dispositivo all'estremità remota di un tunnel VPN o quando si tenta di eseguire il telnet dal router stesso: Messaggio di errore - % FW-3-RESPONDER_WND_SCALE_INI+NO_SCALE: Pacchetto ignorato - Opzione di scala della finestra non valida per la sessione da x.x.x.x:27331 a x.x.x:23 pediaK[Initiator(flag 0,factor 0) Responder (flag 1, factor2)]
La licenza utente può includere 50, 100 o un numero illimitato di utenti, in base alle esigenze. È stata aggiunta la funzione di ridimensionamento della finestra per consentire la trasmissione rapida di dati su reti LFN (Long FAT networks). Si tratta in genere di connessioni con un'elevata larghezza di banda e un'alta latenza. Le reti con connessioni satellitari sono un esempio di rete LFN, dal momento che i collegamenti satellitari hanno sempre alti ritardi di propagazione con in genere un'elevata larghezza di banda. Per abilitare la funzione di ridimensionamento della finestra per il supporto dei numeri LFN, la dimensione della finestra TCP deve essere maggiore di 65.535. Questo messaggio di errore può essere risolto aumentando la dimensione della finestra TCP a più di 65.535.
Questo messaggio di errore viene visualizzato quando viene visualizzato il tunnel VPN: %ASA-5-305013: Le regole NAT asimmetriche corrispondono per forward e reverse. Aggiornare i flussi di problemi.
Per risolvere il problema quando non si trova sulla stessa interfaccia dell'host con NAT, utilizzare l'indirizzo mappato anziché l'indirizzo effettivo per la connessione all'host. Inoltre, abilitare il comando inspectse l'applicazione incorpora l'indirizzo IP.
Questo messaggio di errore viene visualizzato se il tunnel VPN non si attiva: %ASA-5-713068: Messaggio di notifica non di routine ricevuto: tipo_notifica
Questo messaggio viene generato a causa di una configurazione errata (quando i criteri o gli ACL non sono configurati allo stesso modo sui peer). Una volta trovata una corrispondenza tra i criteri e gli ACL, il tunnel viene attivato senza alcun problema.
Quando si cerca di aggiornare Cisco Adaptive Security Appliance (ASA), viene visualizzato uno dei seguenti messaggi di errore:
Questi messaggi di errore sono puramente informativi e non influiscono sulla funzionalità dell'ASA o della VPN. Vengono visualizzati quando il sottosistema di failover VPN non è in grado di aggiornare i dati di runtime relativi a IPSec perché il tunnel IPSec correlato è stato eliminato dall'unità di standby. Per risolvere questi problemi, eseguire il comando wr standby sull'unità attiva.
Il messaggio di errore %ASA-3-713063: Viene visualizzato il messaggio di errore IKE Peer address not configure for destination 0.0.0.0 e il tunnel non viene visualizzato.
Questo messaggio viene visualizzato quando l'indirizzo peer IKE non è configurato per un tunnel L2L. Per risolvere l'errore, è possibile modificare il numero di sequenza della mappa crittografica, quindi rimuovere e riapplicare la mappa crittografica.
Il messaggio di errore %ASA-3-752006: Tunnel Manager: impossibile inviare un messaggio KEY_ACQUIRE. Probabile configurazione errata della mappa crittografica o del gruppo di tunnel. messaggio di errore registrato sull'appliance Cisco ASA.
Questo messaggio di errore può essere causato da una configurazione errata della mappa crittografica o del gruppo di tunnel. Accertarsi che entrambi siano configurati correttamente. Per ulteriori informazioni su questo messaggio di errore, fare riferimento all'errore 752006.
Di seguito sono elencate alcune delle azioni correttive:
Rimuovere l'ACL crittografico associato alla mappa dinamica.
Rimuovere la configurazione IKEv2 non utilizzata, se presente.
Verificare che l'ACL di crittografia corrisponda correttamente.
Rimuovere le voci duplicate dall'elenco degli accessi.
In una configurazione del tunnel VPN da LAN a LAN, questo errore viene ricevuto su un'estremità dell'appliance ASA:
Il pacchetto interno decapsulato non corrisponde ai criteri negoziati nell'associazione di protezione.
Il pacchetto specifica la sua destinazione come 10.32.77.67, l'origine come 10.105.30.1 e il suo protocollo come icmp.
L'associazione di protezione specifica il proxy locale come 10.32.77.67/255.255.255.255/ip/0 e il relativo remote_proxy come 10.105.42.192/255.255.255.224/ip/0.
È necessario verificare gli elenchi degli accessi al traffico univoci definiti su entrambe le estremità del tunnel VPN. Entrambi devono corrispondere esattamente come immagini speculari.
Impossibile avviare il programma di installazione VA a 64 bit per abilitare la scheda virtuale a causa dell'errore 0xffffff. Quando AnyConnect non riesce a connettersi, viene ricevuto un messaggio di registro.
Per risolvere il problema, completare i seguenti passaggi:
Selezionare Sistema > Gestione delle comunicazioni Internet > Impostazioni di comunicazione Internet e assicurarsi che Disattiva aggiornamento automatico certificati radice sia disattivato.
Se è disattivato, disabilitare l'intera parte del modello amministrativo dell'oggetto Criteri di gruppo assegnata al computer interessato e ripetere il test. Per ulteriori informazioni, fare riferimento a Disattivazione dell'aggiornamento automatico dei certificati radice.
Cisco VPN Client non funziona con la scheda dati in Windows 7.
Il client VPN Cisco installato in Windows 7 non funziona con le connessioni 3G in quanto le schede dati non sono supportate nei client VPN installati nei computer Windows 7.
Durante i tentativi di abilitazione di ISAKMP sull'interfaccia esterna dell'ASA, viene ricevuto questo messaggio di avviso:
ASA(config)# crypto isakmp enable outside WARNING, system is running low on memory. Performance may start to degrade. VPN functionality may not work at all.
L'accesso all'ASA tramite SSH e HTTPS è stato arrestato e il problema riguarda anche altri client SSL.
Questo problema è dovuto ai requisiti di memoria di diversi moduli, ad esempio logger e crypto. Accertarsi di non disporre del comando 0della coda di registrazione. La dimensione della coda viene impostata su 8192 e l'allocazione della memoria aumenta. Nelle piattaforme come ASA5505 e ASA5510, questa allocazione di memoria tende a ridurre la memoria di altri moduli.
Viene ricevuto questo messaggio di errore:
%ASA-3-402130: CRYPTO: Received an ESP packet (SPI = 0xXXXXXXX, sequence number= 0xXXXX) from x.x.x.x (user= user) to y.y.y.y with incorrect IPsec padding
Il problema si verifica perché la VPN IPSec esegue la negoziazione senza un algoritmo hash. L'hash del pacchetto garantisce il controllo dell'integrità per il canale ESP. Pertanto, senza hash, i pacchetti in formato errato vengono accettati come non rilevati da Cisco ASA e tentano di decrittografarli. Tuttavia, poiché i pacchetti sono in formato non corretto, l'ASA rileva dei problemi durante la decrittografia. In questo modo vengono visualizzati i messaggi di errore relativi alla spaziatura interna. Si consiglia di includere un algoritmo hash nel set di trasformazioni per la VPN e di garantire che il collegamento tra i peer includa un numero minimo di malformazioni del pacchetto.
Il tunnel VPN viene disconnesso dopo ogni 18 ore, anche se la durata è impostata su 24 ore.
La durata è il tempo massimo per cui l'associazione di protezione può essere utilizzata per una reimpostazione della chiave. Il valore immesso nella configurazione come durata è diverso dal tempo di rigenerazione della chiave dell'associazione di protezione. È necessario negoziare una nuova associazione di protezione (o una coppia di associazioni di protezione nel caso di IPSec) prima della scadenza di quella corrente. Il tempo di reimpostazione della chiave deve essere inferiore alla durata consentita per consentire più tentativi in caso di esito negativo del primo tentativo di reimpostazione della chiave.
Nelle RFC non viene specificato come calcolare il tempo di reimpostazione della chiave. Questo è lasciato alla vostra discrezione, quindi, il tempo varia con la piattaforma. Alcune implementazioni possono utilizzare un fattore casuale per calcolare il timer di reimpostazione chiavi. Ad esempio, se l'ASA avvia il tunnel, è normale che reimposti le chiavi a 64800 secondi = 75% di 86400. Se il router viene avviato, l'ASA può attendere più tempo per concedere al peer un tempo maggiore per avviare la reimpostazione delle chiavi. Pertanto, è normale che la sessione VPN venga disconnessa ogni 18 ore per utilizzare un'altra chiave per la negoziazione VPN.
Il flusso del traffico non viene mantenuto dopo la rinegoziazione del tunnel LAN-LAN.
L'ASA controlla tutte le connessioni che passano attraverso e mantiene una voce nella relativa tabella di stato in conformità alla funzione di ispezione dell'applicazione. I dettagli del traffico crittografato che passano attraverso la VPN vengono gestiti sotto forma di database delle associazioni di sicurezza (SA). Per le connessioni VPN da LAN a LAN, mantiene due flussi di traffico diversi. La prima è il traffico crittografato tra i gateway VPN. L'altro è il flusso di traffico tra la risorsa di rete dietro il gateway VPN e l'utente finale dietro l'altra estremità.
Quando la VPN viene terminata, i dettagli del flusso per questa particolare associazione di protezione vengono eliminati. Tuttavia, la voce della tabella di stato gestita dall'ASA per questa connessione TCP non è più aggiornata a causa dell'assenza di attività che impedisce il download. In questo modo, l'ASA mantiene la connessione TCP per quel particolare flusso mentre l'applicazione utente termina. Le connessioni TCP diventano isolate e alla fine si interrompe dopo la scadenza del timer di inattività TCP. Per risolvere il problema, è stata introdotta una funzionalità denominata Flussi di tunneling IPSec permanenti. Un nuovo comando, syspot connection preserve-vpn-flows è stato integrato in Cisco ASA per conservare le informazioni della tabella dello stato alla rinegoziazione del tunnel VPN.
Per impostazione predefinita, questo comando è disattivato. Per abilitare questa funzione, quando la VPN L2L si riattiva e ristabilisce il tunnel, Cisco ASA conserva le informazioni della tabella di stato TCP.
Questo messaggio di errore viene ricevuto sul router serie 2900:
Errore: 20 mar 10:51:29: %CERM-4-TX_BW_LIMIT: Raggiunto il limite massimo di larghezza di banda Tx di 8500 Kbps per la funzionalità di crittografia con licenza del pacchetto con tecnologia SecurityKey9.
Si tratta di una questione nota che si verifica a causa delle rigide linee guida emesse dal governo degli Stati Uniti. In conformità con la licenza securityk9, può consentire una crittografia del payload solo fino a velocità vicine a 90 Mbps e limita il numero di tunnel crittografati/sessioni TLS al dispositivo. Per ulteriori informazioni sulle restrizioni all'esportazione delle funzionalità di crittografia, fare riferimento alle licenze Cisco ISR G2 SEC e HSEC.
Per i dispositivi Cisco, si calcola che il traffico unidirezionale in entrata e in uscita dal router ISR G2 sia inferiore a 85 Mbps con un totale bidirezionale di 170 Mbps. Questo requisito è valido per le piattaforme Cisco 1900, 2900 e 3900 ISR G2. Questo comando consente di visualizzare le seguenti limitazioni:
Router#show platform cerm-information Crypto Export Restrictions Manager(CERM) Information: CERM functionality: ENABLED ---------------------------------------------------------------- Resource Maximum Limit Available ---------------------------------------------------------------- Tx Bandwidth(in kbps) 85000 85000 Rx Bandwidth(in kbps) 85000 85000 Number of tunnels 225 225 Number of TLS sessions 1000 1000 ---Output truncated----
Per evitare questo problema, acquistare una licenza HSECK9. Una licenza con funzione "hseck9" offre funzionalità avanzate di crittografia del payload con un numero maggiore di tunnel VPN e sessioni vocali sicure. Per ulteriori informazioni sulle licenze dei router Cisco ISR, consultare il documento sull'attivazione del software.
Questo problema è stato osservato su una connessione IPsec dopo più richiavi, tuttavia la condizione di attivazione non è chiara. Per verificare la presenza di questo problema, controllare l'output del comando show asp drop e verificare che il contatore di contesto VPN scaduto aumenti per ciascun pacchetto in uscita inviato.
Se il tunnel non viene avviato, il messaggio AG_INIT_EXCH viene visualizzato nell'output del comando show crypto isakmp e anche nell'output del debug. Il motivo può essere dovuto a una mancata corrispondenza dei criteri ISAKMP o al blocco della porta UDP 500.
Questo messaggio è informativo e non ha nulla a che fare con la disconnessione del tunnel VPN.
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
2.0 |
22-Jul-2026
|
Controllo ortografico e grammaticale aggiornato, inserimento di righe orizzontali per separare le sezioni ai fini della leggibilità, avvisi CCW fissi. |
1.0 |
31-Mar-2014
|
Versione iniziale |