Beheben von häufigen Problemen bei L2L und RAS-IPsec-VPN
Einleitung
In diesem Dokument werden die häufigsten Lösungen für IPsec-VPN-Probleme beschrieben.
Hintergrundinformationen
Die in diesem Dokument beschriebenen Lösungen stammen direkt aus Serviceanfragen, die vom technischen Support-Team von Cisco bearbeitet wurden. Viele dieser Lösungen werden vor der detaillierten Fehlerbehebung einer IPsec-VPN-Verbindung implementiert. In diesem Dokument finden Sie eine Zusammenfassung der gängigen Verfahren, die Sie vor Beginn der Fehlerbehebung bei einer Verbindung ausprobieren müssen.
Die Konfigurationsbeispiele in diesem Dokument sind für den Einsatz auf Routern und Security Appliances vorgesehen. Fast alle Konzepte gelten für VPN 3000. Eine Erläuterung der gängigen Debug-Befehle zur Behebung von IPsec-Problemen mit der Cisco IOS®-Software finden Sie unter IP Security Troubleshooting - Understanding and Using debug Commands.
Anmerkung: SA leitet Multicast-Datenverkehr nicht über IPsec-VPN-Tunnel weiter.
Warnung: Viele der in diesem Dokument vorgestellten Lösungen können zu einem vorübergehenden Verlust aller IPsec-VPN-Verbindungen auf einem Gerät führen. Es wird empfohlen, diese Lösungen mit Vorsicht und gemäß Ihrer Änderungskontrollrichtlinie zu implementieren.
Voraussetzungen
Anforderungen
Cisco empfiehlt die Kenntnis der IPsec-VPN-Konfiguration auf folgenden Cisco Geräten:
- Cisco IOS® Router
-
Cisco Adaptive Security Appliance der ASA 5500-Serie
Verwendete Komponenten
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
- Cisco IOS®
-
Cisco Adaptive Security Appliance der ASA 5500-Serie
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Konventionen
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).
IPsec-VPN-Konfiguration funktioniert nicht
Problem
- Eine kürzlich konfigurierte oder geänderte IPsec-VPN-Lösung funktioniert nicht.
- Eine aktuelle IPsec-VPN-Konfiguration funktioniert nicht mehr.
Lösungen
Dieser Abschnitt enthält Lösungen für die häufigsten IPsec-VPN-Probleme. Diese Lösungen sind zwar nicht in einer bestimmten Reihenfolge aufgeführt, können jedoch als Checkliste verwendet werden, um sie vor einer gründlichen Sanierung zu überprüfen. Alle diese Lösungen stammen direkt aus TAC-Serviceanfragen und haben eine Reihe von Problemen gelöst.
-
Löschen alter oder vorhandener Sicherheitszuordnungen (Tunnel)
-
Überprüfen, ob die ACLs korrekt sind und an die Crypto Map gebunden sind
-
Überprüfen Sie die Sequenznummern und den Namen der Krypto-Zuordnung
Anmerkung: Einige Befehle in diesen Abschnitten werden aus räumlichen Gründen in eine zweite Zeile nach unten verschoben.
NAT-Traversal aktivieren (RA-VPN-Problem Nr. 1)
NAT-Traversal (oder NAT-T) ermöglicht die Weiterleitung von VPN-Datenverkehr über NAT- oder PAT-Geräte, wie den Linksys SOHO-Router. Wenn NAT-T nicht aktiviert ist, scheinen sich Benutzer des VPN-Clients häufig problemlos mit der ASA zu verbinden, können jedoch nicht auf ein internes Netzwerk hinter der Sicherheits-Appliance zugreifen. Wenn NAT-T im NAT/PAT-Gerät nicht aktiviert ist, können Sie die Fehlermeldung für die Erstellung der regulären Übersetzung für das Protokoll 50 src inside:10.0.1.26 dst outside:10.9.694 in der ASA erhalten.
Wenn Sie sich nicht gleichzeitig über dieselbe IP-Adresse anmelden können, wurde die sichere VPN-Verbindung lokal vom Client beendet. Reason 412: Die Fehlermeldung "Der Remote-Peer reagiert nicht mehr" wird angezeigt. Aktivieren Sie NAT-T im VPN-Headend, um diesen Fehler zu beheben.
Anmerkung: Ab Version 12.2(13)T der Cisco IOS® Software ist NAT-T in Cisco IOS® standardmäßig aktiviert.
Der nächste Befehl aktiviert NAT-T auf der Cisco Security Appliance. Die 20 in diesem Beispiel ist die Keepalive-Zeit (Standard).
ASA
securityappliance(config)#crypto isakmp nat-traversal 20
Clients müssen geändert werden, damit sie ordnungsgemäß funktionieren. Navigieren Sie im Cisco VPN Client zuVerbindungseinträge, und klicken Sie auf Ändern. Daraufhin wird ein neues Fenster geöffnet, und Sie müssen die Registerkarte "Transport" auswählen. Klicken Sie auf dieser Registerkarte auf Transparentes Tunneling aktivieren und das Optionsfeld IPSec over UDP (NAT/PAT). Klicken Sie dann auf Save, und testen Sie die Verbindung.
Es ist wichtig, UDP 4500 für NAT-T-, UDP 500- und ESP-Ports durch die Konfiguration einer ACL zuzulassen, da die ASA als NAT-Gerät fungiert. Weitere Informationen zur ACL-Konfiguration in ASA finden Sie unter Konfigurieren eines IPsec-Tunnels über eine Firewall mit NAT.
Ordnungsgemäßer Verbindungstest
Die VPN-Verbindungen werden von Geräten getestet, die sich hinter dem Verschlüsselungsendpunkt befinden. Viele Benutzer testen die VPN-Verbindung, indem sie den Befehl ping vom Verschlüsselungsendpunkt aus ausführen. Obwohl dieser Befehl im Allgemeinen für diesen Zweck funktioniert, ist es wichtig, den Ping von der richtigen Schnittstelle zu beziehen. Wenn die Quelle falsch ist, kann es so aussehen, als ob die VPN-Verbindung ausgefallen ist, wenn sie richtig funktioniert. Dies ist ein Beispiel:
Krypto-ACL von Router A
access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255
Krypto-ACL von Router B
access-list 110 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255
In diesem Beispiel muss das Ping-Signal vom Netzwerk hinter einem der beiden Router bezogen werden. Die Krypto-ACLs sind nur für die Verschlüsselung des Datenverkehrs mit diesen Quelladressen konfiguriert. Die von den externen Schnittstellen der beiden Router eingehenden Anrufe werden nicht verschlüsselt. Verwenden Sie die erweiterten Optionen des Befehls pingim privilegierten EXEC-Modus, um einen Ping von der internen Schnittstelle eines Routers zu beziehen:
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
Stellen Sie sich vor, die Router in diesem Diagramm werden durch ASA Security Appliances ersetzt. Der zum Testen der Konnektivität verwendeteInput kann auch von der internen Schnittstelle mit demInsideSchlüsselwort bezogen werden:
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
Es wird nicht empfohlen, die interne Schnittstelle einer Sicherheits-Appliance mit Ihrem Ping anzuvisieren. Wenn Sie die interne Schnittstelle mithilfe des Befehls theping als Ziel festlegen müssen, müssen Sie den Verwaltungszugriff auf dieser Schnittstelle aktivieren, sonst antwortet die Appliance nicht."
securityappliance(config)#management-access inside
Wenn ein Problem mit der Verbindung besteht, funktioniert auch Phase 1 des VPN nicht. Wenn die Verbindung auf der ASA fehlschlägt, ist die SA-Ausgabe ähnlich wie in diesem Beispiel, das auf eine mögliche falsche Krypto-Peer-Konfiguration oder eine falsche ISAKMP-Vorschlagskonfiguration hinweist:
Router#show crypto isakmp sa
1 IKE Peer: XX.XX.XX.XX
Type : L2L Role : initiator
Rekey : no State : MM_WAIT_MSG2
Der Status kann zwischen MM_WAIT_MSG2 und MM_WAIT_MSG5 liegen, was bedeutet, dass der betreffende Statusaustausch im Hauptmodus (MM) fehlgeschlagen ist. Crypto SA-Ausgabe, wenn Phase 1 aktiv ist. wie in diesem Beispiel:
Router#show crypto isakmp sa
1 IKE Peer: XX.XX.XX.XX
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
Aktivieren von ISAKMP
Wenn es keinen Hinweis darauf gibt, dass ein IPsec-VPN-Tunnel wie erwartet funktioniert, ist es möglich, dass ISAKMP nicht aktiviert ist. Stellen Sie sicher, dass Sie ISAKMP auf Ihren Geräten aktiviert haben. Verwenden Sie einen der folgenden Befehle, um ISAKMP zu aktivieren:
Cisco IOS®
router(config)#crypto isakmp enable
Cisco ASA (ersetzt durch die gewünschte Benutzeroberfläche):
securityappliance(config)#crypto isakmp enable outside
Sie können diese Fehlermeldung auch erhalten, wenn Sie ISAKMP auf der externen Schnittstelle aktivieren:
UDP: ERROR - socket <unknown> 62465 in used ERROR: IkeReceiverInit, unable to bind to port
Die Ursache des Fehlers kann sich auf den Client beziehen, hinter dem ASA PAT an UDP-Port 500 empfängt, bevor ISAKMP auf der Schnittstelle aktiviert werden kann. Sobald die PAT-Übersetzung entfernt wurde (Klartext), kann ISAKMP aktiviert werden. Überprüfen Sie, ob die UDP 500- und die 4500-Portnummern für die Aushandlung von ISAKMP-Verbindungen mit dem Peer reserviert sind. Wenn ISAKMP auf der Schnittstelle nicht aktiviert ist, zeigt der VPN-Client eine Fehlermeldung ähnlich der folgenden an:
Secure VPN connection terminated locally by client. Reason 412: The remote peer is no longer responding
Um diesen Fehler zu beheben, aktivieren Sie ISAKMP an der Kryptografieschnittstelle des VPN-Gateways.
Aktivieren/Deaktivieren von PFS
Bei den IPsec-Verhandlungen stellt Perfect Forward Secrecy (PFS) sicher, dass jeder neue kryptografische Schlüssel keinen Bezug zu einem vorherigen Schlüssel hat. Aktivieren oder deaktivieren Sie PFS auf beiden Tunnel-Peers. Andernfalls ist der LAN-to-LAN (L2L) IPsec-Tunnel nicht im ASA-/Cisco IOS®-Router eingerichtet. Perfect Forward Secrecy (PFS) ist von Cisco proprietär und wird auf Drittanbietergeräten nicht unterstützt.
ASA:
PFS ist standardmäßig deaktiviert. Um PFS zu aktivieren, führen Sie den Befehl epfsmit dem Schlüsselwort enable im Konfigurationsmodus für Gruppenrichtlinien aus. Um PFS zu deaktivieren, geben Sie das disable-Schlüsselwort ein.
hostname(config-group-policy)#pfs {enable | disable}
Um das PFS-Attribut aus der Konfiguration zu entfernen, führen Sie no Form dieses Befehls aus. Eine Gruppenrichtlinie kann einen Wert für PFS von einer anderen Gruppenrichtlinie erben. Führen Sie die Form no dieses Befehls aus, um die Übertragung eines Werts zu verhindern.
hostname(config-group-policy)#no pfs
Cisco IOS® Router
- Um anzugeben, dass IPsec PFS anfordern muss, wenn neue Sicherheitszuordnungen für den Crypto Map-Eintrag angefordert werden, führen Sie den Befehl set pfsim Konfigurationsmodus crypto map aus.
- Um anzugeben, dass IPsec PFS benötigen muss, wenn es Anforderungen für neue Sicherheitszuordnungen empfängt, führen Sie den Befehl set pfsim Konfigurationsmodus crypto map aus.
- Um anzugeben, dass IPsec kein PFS anfordern darf, führen Sie das Formular no dieses Befehls aus. PFS wird standardmäßig nicht angefordert, wenn mit diesem Befehl keine Gruppe angegeben wird und group1 als Standard verwendet wird.
set pfs [group1 | group2] no set pfs
Für den Befehl set pfs:
-
group1: Gibt an, dass IPsec die Diffie-Hellman-Primzahlmodulgruppe mit 768 Bit verwenden muss, wenn der neue Diffie-Hellman-Austausch durchgeführt wird.
-
group2: Gibt an, dass IPsec die Diffie-Hellman-Primzahlmodulgruppe mit 1024 Bit verwenden muss, wenn der neue Diffie-Hellman-Austausch durchgeführt wird.
Beispiel:
Router(config)#crypto map map 10 ipsec-isakmp Router(config-crypto-map)#set pfs group2
Alte oder aktuelle Sicherheitszuordnungen (Tunnel) löschen
Wenn diese Fehlermeldung auf dem Cisco IOS®®-Router auftritt, ist die SA entweder abgelaufen oder wurde gelöscht. Das entfernte Tunnelendgerät weiß nicht, dass es die abgelaufene SA verwendet, um ein Paket (kein SA-Einrichtungspaket) zu senden. Wenn eine neue SA erstellt wurde, wird die Kommunikation fortgesetzt. Initiieren Sie daher den Datenverkehr über den Tunnel, um eine neue SA zu erstellen und den Tunnel neu einzurichten.
%CRYPTO-4-IKMP_NO_SA: IKE message from x.x.x.x has no SA
Wenn Sie ISAKMP (Phase 1) und IPsec (Phase 2) Sicherheitszuordnungen (SAs) löschen, ist dies häufig die beste Lösung zur Behebung von IPsec-VPN-Problemen. Wenn Sie Sicherheitszuordnungen löschen, können Sie eine Vielzahl von Fehlermeldungen und Verhaltensweisen ohne detaillierte Fehlerbehebung beheben. Diese Methode kann zwar in jeder Situation problemlos verwendet werden, es wird jedoch empfohlen, SAs zunächst zu löschen, nachdem Sie eine aktuelle IPsec-VPN-Konfiguration geändert oder hinzugefügt haben. Darüber hinaus ist es zwar möglich, nur bestimmte Sicherheitszuordnungen zu löschen. Es bietet sich jedoch an, Sicherheitszuordnungen global auf dem Gerät zu löschen. Sobald die Sicherheitszuordnungen gelöscht wurden, kann es erforderlich sein, Datenverkehr über den Tunnel zu senden, um diese wiederherzustellen.
Warnung: Wenn Sie nicht angeben, welche Sicherheitszuordnungen gelöscht werden sollen, können mit den hier aufgeführten Befehlen alle Sicherheitszuordnungen auf dem Gerät gelöscht werden. Gehen Sie vorsichtig vor, wenn andere IPsec-VPN-Tunnel verwendet werden.
-
Sehen Sie sich die Sicherheitszuordnungen an, bevor Sie sie löschen
-
Cisco IOS®
router#show crypto isakmp sa router#show crypto ipsec sa
-
Cisco ASA Security Appliances
securityappliance#show crypto isakmp sa securityappliance#show crypto ipsec sa
-
-
Löschen Sie die Sicherheitszuordnungen, da jeder Befehl entweder fett oder mit den zugehörigen Optionen eingegeben werden kann.
-
Cisco IOS®
-
ISAKMP (Phase I)
router#clear crypto isakmp ? <0 - 32766> connection id of SA <cr>
IPsec (Phase 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>
-
Cisco ASA Security Appliances
-
ISAKMP (Phase I)
securityappliance#clear crypto isakmp sa
-
IPsec (Phase 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>
-
-
-
Überprüfen der ISAKMP-Lebensdauer
Wenn die Verbindung von Benutzern häufig über den L2L-Tunnel getrennt wird, kann dieses Problem über die Lebenszeitgarantie von ISAKMP SA konfiguriert werden. Wenn während der ISAKMP-Lebensdauer eine Diskrepanz auftritt, können Sie die folgende Meldung erhalten:%ASA-5-713092: Group = x.x.x.x, IP = x.x.x.x, Fehler beim erneuten Versuch der Phase 1 aufgrund einer Kollisionsfehlermeldung in /ASA. Der Standardwert ist 86400 Sekunden (24 Stunden). In der Regel sorgt eine kürzere Lebensdauer für sicherere ISAKMP-Verhandlungen (bis zu einem gewissen Punkt). Mit kürzeren Lebenszeiten richtet die Sicherheits-Appliance jedoch zukünftige IPsec-SAs schneller ein.
Eine Übereinstimmung wird erzielt, wenn beide Richtlinien von zwei Peers die gleichen Werte für Verschlüsselung, Hash, Authentifizierung und Diffie-Hellman-Parameter enthalten und wenn die Richtlinie des Remote-Peers eine Lebensdauer angibt, die kleiner oder gleich der Lebensdauer in der verglichen Richtlinie ist. Wenn die Lebensdauer nicht identisch ist, wird die kürzere Lebensdauer - gemäß der Richtlinie des Remote-Peers - verwendet, und es wird keine akzeptable Übereinstimmung gefunden, die IKE lehnt die Aushandlung ab, und die IKE SA wird nicht eingerichtet.
- Geben Sie die Lebensdauer der Sicherheitszuordnung an: In diesem Beispiel wird eine Lebensdauer von 4 Stunden (14400 Sekunden) festgelegt. Der Standardwert ist 86400 Sekunden (24 Stunden).
ASA:
hostname(config)#isakmp policy 2 lifetime 14400
Cisco IOS® Router:
R2(config)#crypto isakmp policy 10 R2(config-isakmp)#lifetime 86400
Wenn die maximale konfigurierte Lebensdauer überschritten wird, wird beim Beenden der VPN-Verbindung folgende Fehlermeldung angezeigt:
Secure VPN Connection terminated locally by the Client. Reason 426: Maximale konfigurierte Lebensdauer überschritten.
Um diesen Fehler zu beheben, setzen Sie den LIFEtimewert auf Null (0). Um die Lebensdauer einer IKE-Sicherheitszuordnung auf "unendlich" festzulegen, muss das VPN immer verbunden sein und wird nicht beendet:
hostname(config)#isakmp policy 2 lifetime 0
Sie können auch die erneute Auslieferung in der Gruppenrichtlinie deaktivieren, um das Problem zu beheben.
Aktivieren oder Deaktivieren von ISAKMP Keepalives
Wenn Sie ISAKMP-Keepalives konfigurieren, hilft dies, sporadische Unterbrechungen von LAN-zu-LAN- oder Remote Access-VPNs zu verhindern. Dazu gehören VPN-Clients, Tunnel und Tunnel, die nach einer Zeit der Inaktivität gelöscht wurden. Mit dieser Funktion können Tunnelendpunkte die weitere Anwesenheit eines Remote-Peers überwachen und seine eigene Anwesenheit an diesen Peer melden. Wenn der Peer nicht mehr reagiert, trennt der Endpunkt die Verbindung. Damit ISAKMP-Keepalives funktionieren, müssen beide VPN-Endpunkte diese unterstützen.
Konfigurieren Sie ISAKMP-Keepalives in Cisco IOS®, indem Sie den folgenden Befehl ausführen:
router(config)#crypto isakmp keepalive 15
Führen Sie die folgenden Befehle aus, um ISAKMP-Keepalives auf ASA Security Appliances zu konfigurieren:
Cisco ASA für die Tunnelgruppe mit der Bezeichnung10.165.205.222:
securityappliance(config)#tunnel-group 10.165.205.222 ipsec-attributes securityappliance(config-tunnel-ipsec)#isakmp keepalive threshold 15 retry 10
In einigen Situationen muss diese Funktion deaktiviert werden, um das Problem zu beheben. Wenn sich beispielsweise der VPN-Client hinter einer Firewall befindet, die DPD-Pakete verhindert. Mit Cisco ASA deaktivieren Sie für die Tunnelgruppe 10.165.205.222 die IKE-Keepalive-Verarbeitung. Diese ist standardmäßig aktiviert:
securityappliance(config)#tunnel-group 10.165.205.222 ipsec-attributes securityappliance(config-tunnel-ipsec)#isakmp keepalive disable
Deaktivieren Sie Keepalive für Cisco VPN Client 4.x
- Navigieren Sie zu %System Root% > Program Files > Cisco Systems > VPN Client > Profilesauf dem Client-PC, auf dem das Problem auftritt, IKE Keepalive zu deaktivieren, und bearbeiten Sie gegebenenfalls die PCF-Datei für die Verbindung.
- Ändern Sie theForceKeepAlives=0(default) in ForceKeepAlives=1. Keepalives sind von Cisco herstellerspezifisch und werden von Drittanbietergeräten nicht unterstützt.
Erneute Eingabe oder Wiederherstellung von Pre-Shared-Keys
In vielen Fällen kann ein einfacher Tippfehler schuld sein, wenn ein IPsec VPN-Tunnel nicht funktioniert. Auf der Security-Appliance werden beispielsweise Pre-Shared Keys verborgen, sobald sie eingegeben wurden. Diese Verschleierung macht es unmöglich zu erkennen, ob eine Taste falsch ist. Stellen Sie sicher, dass Sie alle Pre-Shared Keys korrekt auf jedem VPN-Endpunkt eingegeben haben.
Überprüfen Sie in Remote Access VPN, ob der gültige Gruppenname und der bzw. die vorinstallierten Schlüssel im Cisco VPN Client eingegeben wurden. Dieser Fehler tritt auf, wenn der Gruppenname oder der bzw. die vorinstallierten Schlüssel zwischen dem VPN-Client und dem Headend-Gerät nicht übereinstimmen.
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)
Warnung: Wenn Sie kryptographiebezogene Befehle entfernen, können Sie einen oder alle VPN-Tunnel deaktivieren. Verwenden Sie diese Befehle mit Vorsicht, und lesen Sie die Änderungskontrollrichtlinie Ihres Unternehmens, bevor Sie kryptographische Befehle entfernen.
Führen Sie die folgenden Befehle aus, um den vorinstallierten Schlüsselsekretärschlüssel für den Peer10.0.0.1oder die GruppeVPNgroupin Cisco IOS® zu entfernen und erneut einzugeben:
Cisco LAN-zu-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
Führen Sie die folgenden Befehle aus, um den pre-shared-keysecretkey für den Peer10.0.0.1auf /ASA Security Appliances zu entfernen und erneut einzugeben:
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 und höher:
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
Nicht übereinstimmender Pre-Shared Key
Die Verbindung zum VPN-Tunnel wird getrennt. Dieses Problem tritt auf, weil der vorinstallierte Schlüssel während der Phase-I-Verhandlungen nicht übereinstimmt. Die Nachricht MM_WAIT_MSG_6in der Anweisung crypto isakmp sacommand gibt einen nicht übereinstimmenden Pre-Shared Key an, wie in diesem Beispiel gezeigt:
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
Um dieses Problem zu beheben, geben Sie den vorinstallierten Schlüssel auf beiden Appliances erneut ein. Der Pre-Shared Key muss eindeutig und übereinstimmend sein. Weitere Informationen finden Sie unter Vorinstallierte Schlüssel erneut eingeben oder wiederherstellen.
Entfernen und erneutes Anwenden von Krypto-Zuordnungen
Wenn Sie Sicherheitszuordnungen löschen und das IPsec-VPN-Problem nicht lösen, entfernen Sie die entsprechende Crypto Map, und wenden Sie sie erneut an, um eine Vielzahl von Problemen zu beheben, zu denen das zeitweilige Verwerfen des VPN-Tunnels und Fehler einiger VPN-Standorte gehören.
Warnung: Wenn Sie eine Crypto Map von einer Schnittstelle entfernen, werden alle IPsec-Tunnel entfernt, die dieser Crypto Map zugeordnet sind. Gehen Sie mit Vorsicht vor, befolgen Sie diese Schritte, und berücksichtigen Sie die Änderungskontrollrichtlinie Ihres Unternehmens, bevor Sie fortfahren.
Führen Sie die folgenden Befehle aus, um eine Crypto Map in Cisco IOS® zu entfernen und zu ersetzen:
Beginnen Sie mit dem Entfernen der Krypto-Zuordnung von der Schnittstelle. Führen Sie die no-Form des Befehls crypto mapaus:
router(config-if)#no crypto map mymap
Fahren Sie mit dem Ausführen des Formulars fort, um eine vollständige Crypto Map zu entfernen:
router(config)#no crypto map mymap 10
Ersetzen Sie die Crypto Map an der Schnittstelle Ethernet0/0 für den Peer10.0.0.1. Dieses Beispiel zeigt die mindestens erforderliche Crypto Map-Konfiguration:
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
Führen Sie diese Befehle aus, um eine Crypto Map auf der ASA zu entfernen und zu ersetzen. Beginnen Sie mit dem Entfernen der Krypto-Zuordnung von der Schnittstelle. Führen Sie die no-Form des Befehls crypto mapaus:
securityappliance(config)#no crypto map mymap interface outside
Fahren Sie mit dem Ausführen des Formulars fort, um die anderen Crypto Map-Befehle zu entfernen:
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
Ersetzen Sie die Crypto Map für Peer10.0.0.1. In diesem Beispiel wird die erforderliche Mindestkonfiguration für die Crypto Map angezeigt:
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
Wenn Sie die Crypto Map entfernen und erneut anwenden, wird auch das Verbindungsproblem behoben, wenn die IP-Adresse des Headends geändert wurde.
Überprüfen Sie, ob Sysopt-Befehle vorhanden sind (nur ASA).
Der Befehl sysopt connection permit-ipsecandsysopt connection permit-vpnallow-Pakete aus einem IPsec-Tunnel und deren Payloads, um die Schnittstellen-ACLs auf der Sicherheits-Appliance zu umgehen. IPsec-Tunnel, die auf der Security-Appliance terminiert sind, fallen wahrscheinlich aus, wenn einer dieser Befehle nicht aktiviert ist.
- In Security Appliance Software Version 7.0 und früher lautet der entsprechende Befehl sysopt für diese Situation issysopt connection permit-ipsec.
- In Security Appliance Software Version 7.1(1) und höher lautet der entsprechende Befehl sysopt für diese Situation issysopt connection permit-vpn.
- In 6.x ist diese Funktion standardmäßig deaktiviert. Bei /ASA 7.0(1) und höheren Versionen ist diese Funktion standardmäßig aktiviert. Führen Sie die folgenden show-Befehle aus, um festzustellen, ob der entsprechendeSysoptbefehl auf Ihrem Gerät aktiviert ist:
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)
Führen Sie diesen Befehl aus, um den Befehl Correctsysoptfür Ihr Gerät zu aktivieren:
Cisco ASA:
securityappliance(config)#sysopt connection permit-vpn
Wenn Sie den Befehl sysopt connection nicht ausführen möchten, lassen Sie den erforderlichen Datenverkehr von der Quelle zum Ziel explizit zu. Beispiel: Von Remote zu lokalem LAN des Remote-Geräts und "UDP-Port 500" für die externe Schnittstelle des Remote-Geräts zu externer Schnittstelle des lokalen Geräts in der externen ACL.
Überprüfen der ISAKMP-Identität
IKE-Aushandlungsfehler in IPsec-VPNs resultieren häufig daraus, dass ein Peer die Identität seines Partners nicht erkennt. Dies ist die Methode. Wenn zwei Peers IKE zum Einrichten von IPsec-Sicherheitszuordnungen verwenden, sendet jeder Peer seine ISAKMP-Identität an den Remote-Peer. Er sendet entweder seine IP-Adresse oder seinen Hostnamen, je nachdem, wie jede ISAKMP-Identität festgelegt ist. Standardmäßig ist die ISAKMP-Identität der Firewall-Einheit auf die IP-Adresse festgelegt.
Legen Sie in der Regel die Sicherheits-Appliance und die Identitäten der Peers auf die gleiche Weise fest, um einen Fehler bei der IKE-Aushandlung zu vermeiden. Führen Sie den Befehl eisakmp identity im globalen Konfigurationsmodus aus, um die an den Peer gesendete Phase-2-ID festzulegen:
crypto isakmp identity address !--- If the RA or L2L (site-to-site) VPN tunnels connect !--- with pre-shared key as authentication type
ODER:
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.
ODER:
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.
Wenn der VPN-Tunnel nach einer Verschiebung der Konfiguration von der ASA mithilfe des ASA-Konfigurations-Migrations-Tools nicht gestartet werden kann Im Protokoll werden folgende Meldungen angezeigt:
[IKEv1]: Group = x.x.x.x, IP = x.x.x.x, Stale PeerTblEntry found, removing!
[IKEv1]: Group = x.x.x.x, IP = x.x.x.x, Removing peer from correlator table failed, no match!
[IKEv1]: Group = x.x.x.x, IP = x.x.x.x, construct_ipsec_delete(): No SPI to identify Phase 2 SA!
[IKEv1]: Group = x.x.x.x, IP = x.x.x.x, Removing peer from correlator table failed, no match!
Überprüfen des Leerlauf-/Sitzungs-Timeouts
Wenn die Zeitüberschreitung bei Inaktivität auf 30 Minuten (Standard) festgelegt ist, wird der Tunnel nach 30 Minuten verworfen, wenn kein Datenverkehr durchgeleitet wird. Der VPN-Client wird nach 30 Minuten unabhängig vom Timeout-Parameter für Leerlaufzeiten getrennt und erhält den Fehler PEER_DELETE-IKE_DELETE_UNSPECIFIED.
Konfigurieren Sie die Zeitüberschreitung für die Sitzung so, dass der Tunnel immer unterstützt wird, sodass der Tunnel selbst bei Verwendung von Drittanbietergeräten nicht verworfen wird.
ASA
Führen Sie den Befehl vpn-idle-timeout im Konfigurationsmodus für Gruppenrichtlinien oder im Konfigurationsmodus für den Benutzernamen aus, um die Zeitüberschreitung für den Benutzer zu konfigurieren:
hostname(config)#group-policy DfltGrpPolicy attributes hostname(config-group-policy)#vpn-idle-timeout none
Konfigurieren Sie mit dem Befehl vpn-session-timeout im Konfigurationsmodus für Gruppenrichtlinien oder im Konfigurationsmodus für Benutzernamen die maximale Dauer für VPN-Verbindungen:
hostname(config)#group-policy DfltGrpPolicy attributes hostname(config-group-policy)#vpn-session-timeout none
Wenn Sie unnel-all konfiguriert haben, müssen Sie timeout nicht konfigurieren, da selbst wenn Sie VPN-idle timeout konfigurieren, es nicht wie alle Datenverkehrsprozesse durch den Tunnel funktioniert (da tunnel-all konfiguriert ist).
Daher lässt der Datenverkehr (oder sogar der vom PC generierte Datenverkehr) keine Leerlaufzeitüberschreitung zu.
Cisco IOS® Router
Führen Sie den Befehl rypto ipsec security-association idle-timecim globalen Konfigurationsmodus oder im Konfigurationsmodus crypto map aus, um den IPsec-SA-Idle-Timer zu konfigurieren. IPsec-Leerlaufzeitgeber für Sicherheitszuordnungen sind standardmäßig deaktiviert:
crypto ipsec security-association idle-time seconds
Die Zeit wird in Sekunden gemessen, nach deren Ablauf der Inaktivitäts-Timer einem inaktiven Peer die Aufrechterhaltung einer Sicherheitszuordnung ermöglicht. Gültige Werte für das Sekunden-Argument liegen zwischen 60 und 86400.
Überprüfen, ob die ACLs korrekt und an die Crypto Map gebunden sind
In einer typischen IPsec-VPN-Konfiguration werden zwei Zugriffslisten verwendet. Eine Zugriffsliste wird verwendet, um Datenverkehr, der für den VPN-Tunnel bestimmt ist, vom NAT-Prozess auszuschließen. Die andere Zugriffsliste definiert, welcher Datenverkehr verschlüsselt werden soll. Dies umfasst eine Krypto-ACL in einer LAN-zu-LAN-Konfiguration oder eine Split-Tunnel-ACL in einer RAS-Konfiguration. Wenn diese ACLs nicht richtig konfiguriert sind oder verpasst werden, fließt der Datenverkehr in eine Richtung durch den VPN-Tunnel oder wird überhaupt nicht über den Tunnel gesendet.
Stellen Sie sicher, dass Sie die Krypto-ACL an die Crypto Map binden, indem Sie im globalen Konfigurationsmodus den Befehl crypto map match address ausführen. Überprüfen Sie, ob Sie alle Zugriffslisten konfiguriert haben, um Ihre IPsec-VPN-Konfigurationen abzuschließen, und ob diese Zugriffslisten den richtigen Datenverkehr definieren. Diese Liste enthält Elemente, die überprüft werden müssen, wenn Sie vermuten, dass eine ACL die Ursache für Probleme mit Ihrem IPsec-VPN ist.
Bestätigen Sie die NAT-Ausnahme, und geben Sie in den Krypto-ACLs den richtigen Datenverkehr an. Wenn Sie über mehrere VPN-Tunnel und mehrere Krypto-ACLs verfügen, stellen Sie sicher, dass sich diese ACLs nicht überschneiden. Überprüfen Sie außerdem, ob Ihr Gerät für die Verwendung der NAT-Freistellungs-ACL konfiguriert ist. Auf einem Router heißt das, dass Sie den Befehl route-map ausführen. Auf der ASA führen Sie den Befehl enat (0) aus. Eine NAT-Ausnahme-ACL ist für LAN-zu-LAN- und RAS-Konfigurationen erforderlich.
Im nächsten Beispiel wird ein Cisco IOS®-Router so konfiguriert, dass er Datenverkehr ausnimmt, der zwischen 192.168.100.0 /24 und 192.168.200.0 gesendet wird. /24oder192.168.1.0 /24 von NAT. Datenverkehr, der für einen anderen Standort bestimmt ist, unterliegt NAT-Overload:
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
NAT-Befreiungszugriffskontrolllisten funktionieren nur mit der IP-Adresse oder den IP-Netzwerken, wie z. B. den genannten Beispielen (Zugriffsliste noNAT), und müssen mit den Crypto Map-Zugriffskontrolllisten identisch sein. Die Zugriffskontrolllisten für die NAT-Ausnahme funktionieren nicht mit Portnummern (z. B. 23, 25 usw.). In einer VoIP-Umgebung, in der Sprachanrufe zwischen Netzwerken über das VPN übertragen werden, funktionieren Sprachanrufe nicht, wenn NAT 0-ACLs nicht richtig konfiguriert sind. Vor der Fehlerbehebung wird empfohlen, den VPN-Verbindungsstatus zu überprüfen, da das Problem durch eine falsche Konfiguration von NAT-ausgenommenen ACLs verursacht werden kann.
Die Fehlermeldung wird angezeigt, wenn bei den Zugriffskontrolllisten für die NAT-Ausnahme (NAT 0) eine Fehlkonfiguration vorliegt.
%ASA-3-305005: No translation group found for udp src Outside:x.x.x.x/p dst Inside:y.y.y.y/p
Falsches Beispiel:
access-list noNAT extended permit ip 192.168.100.0 255.255.255.0 192.168.200.0 255.255.255.0 eq 25
Wenn die NAT-Ausnahme (NAT 0) nicht ordnungsgemäß funktioniert, versuchen Sie, sie zu entfernen, und führen Sie denNAT 0-Befehl aus. Vergewissern Sie sich, dass die ACLs nicht rückwärts ausgerichtet sind und den richtigen Typ aufweisen. Zugriffskontrolllisten mit Verschlüsselungs- und NAT-Ausnahme für LAN-zu-LAN-Konfigurationen müssen aus der Perspektive des Geräts geschrieben werden, auf dem die Zugriffskontrollliste konfiguriert ist. Aus diesem Grund müssen die ACLs sich gegenseitig zuordnen. In diesem Beispiel wird ein LAN-zu-LAN-Tunnel zwischen 192.168.100.0 /24 und 192.168.200.0 /24 eingerichtet.
Krypto-ACL von Router A:
access-list 110 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255
Krypto-ACL von Router B:
access-list 110 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255
Obwohl nicht dargestellt, gilt das gleiche Konzept für die ASA Security Appliances. Bei ASA-Konfigurationen mit Split-Tunnel-ACLs für den Remote-Zugriff muss es sich um Standard-Zugriffslisten handeln, die den Datenverkehr zum Netzwerk zulassen, auf das VPN-Clients zugreifen müssen. Cisco IOS® Router können erweiterte ACLs für Split-Tunnels verwenden. In der erweiterten Zugriffsliste ist die Verwendung von 'any'an der Quelle in der Split-Tunnel-ACL ähnlich wie die Deaktivierung des Split-Tunnels. Verwenden Sie für Split-Tunnel nur Quellnetzwerke in der erweiterten ACL.
Richtiges Beispiel:
access-list 140 permit ip 10.1.0.0 0.0.255.255 10.18.0.0 0.0.255.255
Falsches Beispiel:
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
NAT-Ausnahme-Konfiguration in ASA-Version 8.3 für Site-to-Site-VPN-Tunnel:
Zwischen HOASA und BOASA muss ein Site-to-Site-VPN mit beiden ASAs mit Version 8.3 eingerichtet werden. Die NAT-Ausnahmekonfiguration auf HOASA sieht ähnlich aus:
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
Überprüfen der ISAKMP-Richtlinien
Wenn der IPsec-Tunnel nicht aktiv ist, überprüfen Sie, ob die ISAKMP-Richtlinien mit den Remote-Peers übereinstimmen. Diese ISAKMP-Richtlinie gilt sowohl für das Site-to-Site- (L2L-) als auch für das Remote-IPsec-VPN. Wenn die Cisco VPN Clients oder das Site-to-Site-VPN den Tunnel mit dem Remote-Endgerät nicht herstellen können, überprüfen Sie, ob die beiden Peers dieselben Werte für Verschlüsselung, Hash, Authentifizierung und Diffie-Hellman-Parameter enthalten. Überprüfen Sie, ob die Remote-Peer-Richtlinie eine Lebensdauer angibt, die kleiner oder gleich der Lebensdauer in der Richtlinie ist, die der Initiator gesendet hat. Wenn die Lebensdauern nicht identisch sind, verwendet die Security-Appliance die kürzere Lebensdauer. Wenn keine akzeptable Übereinstimmung vorhanden ist, lehnt ISAKMP die Aushandlung ab, und die Sicherheitszuordnung wird nicht eingerichtet.
"Error: Unable to remove Peer TblEntry, Removing peer from peer table failed, no match!"
Dies ist ein Beispiel für eine detaillierte Protokollmeldung:
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
Diese Meldung wird in der Regel aufgrund falsch übereinstimmender ISAKMP-Richtlinien oder einer fehlenden NAT 0-Anweisung angezeigt. Darüber hinaus wird folgende Meldung angezeigt:
Error Message %ASA-6-713219: Queueing KEY-ACQUIRE messages to be processed when P1 SA is complete.
Diese Meldung zeigt an, dass sich Phase-2-Nachrichten nach Abschluss von Phase 1 in der Warteschlange befinden. Diese Fehlermeldung ist auf einen der folgenden Gründe zurückzuführen:
-
Nicht übereinstimmende Phase auf einem der Peers
-
ACL blockiert die Peers vor Abschluss von Phase 1
Diese Meldung wird in der Regel angezeigt, nachdem die Meldung Removing peer from peer table failed, no match!error (Peer aus Peertabelle entfernen) fehlgeschlagen ist. Wenn der Cisco VPN-Client keine Verbindung zum Headend-Gerät herstellen kann, liegt das Problem möglicherweise in der Diskrepanz der ISAKMP-Richtlinie. Das Headend-Gerät muss mit einem IKE-Angebot des Cisco VPN Client übereinstimmen. Für die auf der ASA verwendete ISAKMP-Richtlinie und den IPsec-Transformationssatz kann der Cisco VPN-Client keine Richtlinie mit einer Kombination aus DES und SHA verwenden. Wenn Sie DES verwenden, müssen Sie MD5 für den Hash-Algorithmus verwenden, oder Sie können andere Kombinationen wie 3DES mit SHA und 3DES mit MD5 verwenden.
Überprüfen der korrekten Weiterleitung
Stellen Sie sicher, dass Ihre Verschlüsselungsgeräte wie Router und ASA Security Appliances über die richtigen Routing-Informationen zum Senden von Datenverkehr über den VPN-Tunnel verfügen. Wenn sich hinter Ihrem Gateway-Gerät andere Router befinden, überprüfen Sie, ob diese den Tunnel erreichen können und welche Netzwerke sich auf der anderen Seite befinden. Eine Schlüsselkomponente des Routings in einer VPN-Bereitstellung ist die Reverse Route Injection (RRI). RRI fügt dynamische Einträge für Remote-Netzwerke oder VPN-Clients in die Routing-Tabelle eines VPN-Gateways ein. Diese Routen sind sowohl für das Gerät, auf dem sie installiert sind, als auch für andere Geräte im Netzwerk nützlich, da Routen, die von RRI installiert wurden, über Routing-Protokolle wie EIGRP oder OSPF neu verteilt werden können.
Bei einer LAN-zu-LAN-Konfiguration ist es wichtig, dass für jeden Endpunkt eine oder mehrere Routen zu den Netzwerken vorhanden sind, in denen der Datenverkehr verschlüsselt werden muss. In diesem Beispiel muss Router A über Routen zu den Netzwerken hinter Router B bis 10.89.129.2 verfügen. Router B muss über eine ähnliche Route wie 192.168.100.0 /24 verfügen. Die erste Möglichkeit, sicherzustellen, dass jeder Router die entsprechenden Routen kennt, besteht darin, für jedes Zielnetzwerk statische Routen zu konfigurieren. Router A kann beispielsweise die folgenden Routenanweisungen konfigurieren:
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
Wenn Router A durch eine ASA ersetzt wurde, kann die Konfiguration wie folgt aussehen:
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
Wenn hinter jedem Endpunkt eine große Anzahl von Netzwerken vorhanden ist, gestaltet sich die Konfiguration statischer Routen schwierig. Stattdessen wird empfohlen, die Reverse Route Injection zu verwenden. RRI platziert die Routing-Tabellen-Routen für alle Remote-Netzwerke, die in der Krypto-ACL aufgeführt sind. Die Krypto-ACL und die Krypto-Zuordnung von Router A können beispielsweise wie folgt aussehen:
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
Wenn Router A durch ASA ersetzt wurde, kann die Konfiguration wie folgt aussehen:
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 einer RAS-Konfiguration sind Routing-Änderungen nicht immer erforderlich. Wenn jedoch hinter dem VPN-Gateway-Router oder der Security Appliance weitere Router vorhanden sind, müssen diese den Pfad zu den VPN-Clients erlernen. Stellen Sie sich in diesem Beispiel vor, dass die VPN-Clients bei der Verbindung Adressen im Bereich von 10.0.0.0 /24 erhalten.
Wenn zwischen dem Gateway und den anderen Routern kein Routing-Protokoll verwendet wird, können statische Routen auf Routern wie Router 2 verwendet werden:
ip route 10.0.0.0 255.255.255.0 192.168.100.1
Wenn zwischen dem Gateway und anderen Routern ein Routing-Protokoll wie EIGRP oder OSPF verwendet wird, wird empfohlen, Reverse Route Injection wie beschrieben zu verwenden. RRI fügt Routen für den VPN-Client automatisch zur Routing-Tabelle des Gateways hinzu. Diese Routen können dann an die anderen Router im Netzwerk verteilt werden.
Cisco IOS® Router:
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
Das Routing-Problem tritt auf, wenn sich der Pool der den VPN-Clients zugewiesenen IP-Adressen mit den internen Netzwerken des Headend-Geräts überschneidet. Weitere Informationen finden Sie unter Überlappende private Netzwerke .
Vergewissern Sie sich, dass der Transformationssatz korrekt ist.
Stellen Sie sicher, dass die IPsec-Verschlüsselung und die Hash-Algorithmen, die von dem Transformationssatz auf beiden Seiten verwendet werden, identisch sind. Weitere Informationen finden Sie im Abschnitt "Befehlsreferenz" des Konfigurationsleitfadens für die Cisco Security Appliance. Für die auf der ASA verwendete ISAKMP-Richtlinie und den IPsec-Transformationssatz kann der Cisco VPN-Client keine Richtlinie mit einer Kombination aus DES und SHA verwenden. Wenn Sie DES verwenden, müssen Sie MD5 für den Hash-Algorithmus verwenden, oder Sie können die anderen Kombinationen verwenden: 3DES mit SHA und 3DES mit MD5.
Überprüfen Sie, ob die Crypto Map-Sequenznummer, der Name und die Crypto Map auf die richtige Schnittstelle angewendet wurden, auf der der IPsec-Tunnel startet/endet.
Wenn statische und dynamische Peers auf derselben Crypto Map konfiguriert werden, ist die Reihenfolge der Crypto Map-Einträge entscheidend. Die Sequenznummer des dynamischen Crypto Map-Eintrags muss höher sein als die aller anderen statischen Crypto Map-Einträge. Wenn die statischen Einträge höher nummeriert sind als die dynamischen Einträge, schlagen die Verbindungen mit diesen Peers fehl, und die Fehlersuche wird wie folgt angezeigt:
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!
Für jede Schnittstelle in der Sicherheits-Appliance ist nur eine dynamische Crypto-Zuordnung zulässig. Dies ist ein Beispiel für eine korrekt nummerierte Crypto Map, die einen statischen und einen dynamischen Eintrag enthält. Der dynamische Eintrag hat die höchste Sequenznummer, und es bleibt noch Raum, um zusätzliche statische Einträge hinzuzufügen:
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
Bei Crypto Map-Namen wird die Groß- und Kleinschreibung berücksichtigt. Diese Fehlermeldung wird auch angezeigt, wenn die dynamische Crypto Map-Sequenz falsch ist, was dazu führt, dass der Peer die falsche Crypto Map trifft. Dies wird auch durch eine nicht übereinstimmende Krypto-Zugriffsliste verursacht, die den Datenverkehr definiert:%ASA-3-713042: IKE Initiator unable to find policy:
Wenn mehrere VPN-Tunnel an derselben Schnittstelle terminiert werden, erstellen Sie eine Crypto Map mit demselben Namen (pro Schnittstelle ist nur eine Crypto Map zulässig), jedoch mit einer anderen Sequenznummer. Dies gilt für den Router und die ASA. Siehe ASA: Neuen Tunnel oder Remote-Zugriff zu einem vorhandenen L2L-VPN hinzufügen - Cisco für weitere Informationen zur Konfiguration der Crypto Map für L2L- und Remote Access-VPN-Szenarien.
Überprüfen der korrekten Peer-IP-Adresse
Erstellen und verwalten Sie die Datenbank mit verbindungsspezifischen Datensätzen für IPsec. Geben Sie für eine LAN-to-LAN (L2L)-IPsec-VPN-Konfiguration der ASA Security Appliance als Remote-Peer-IP-Adresse (Remote-Tunnelende) in der Tunnelgruppe <Name> den Befehl ipsec-l2l an. Die Peer-IP-Adresse muss mit dem Namen der Tunnelgruppe und den BefehlenCrypto map set address übereinstimmen. Wenn Sie das VPN mit ASDM konfigurieren, wird automatisch der Tunnelgruppenname mit der richtigen Peer-IP-Adresse generiert. Wenn die Peer-IP-Adresse nicht richtig konfiguriert ist, können die Protokolle diese Meldung enthalten, die durch die ordnungsgemäße Konfiguration der Peer-IP-Adresse aufgelöst werden kann:
[IKEv1]: Group = DefaultL2LGroup, IP = x.x.x.x, ERROR, had problems decrypting packet, probably due to mismatched pre-shared key. Aborting
Wenn die Peer-IP-Adresse in der ASA-Krypto-Konfiguration nicht richtig konfiguriert wurde, kann die ASA den VPN-Tunnel nicht herstellen und hängt nur in der Phase MM_WAIT_MSG4. Korrigieren Sie zur Behebung des Problems die Peer-IP-Adresse in der Konfiguration. Dies ist die Ausgabe des Befehls show crypto isakmp sacommand when the VPN tunnel hangs at in the MM_WAIT_MSG4 state:
hostname#show crypto isakmp sa
1 IKE Peer: XX.XX.XX.XX
Type : L2L Role : initiator
Rekey : no State : MM_WAIT_MSG4
Überprüfen der Tunnelgruppe und der Gruppennamen
%ASA-3-713206: Tunnel Rejected: Conflicting protocols specified by tunnel-group and group-policy
Diese Meldung wird angezeigt, wenn ein Tunnel verworfen wird, weil der in der Gruppenrichtlinie angegebene zulässige Tunnel sich von dem zulässigen Tunnel in der Konfiguration der Tunnelgruppe unterscheidet.
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
Aktivieren Sie IPSec in der Standardgruppenrichtlinie für die vorhandenen Protokolle in der Standardgruppenrichtlinie.
group-policy DfltGrpPolicy attributes vpn-tunnel-protocol L2TP-IPSec IPSec webvpn
Deaktivieren von XAUTH für L2L-Peers
Wenn ein LAN-zu-LAN-Tunnel und ein Remote Access-VPN-Tunnel auf derselben Crypto Map konfiguriert sind, wird der LAN-zu-LAN-Peer aufgefordert, XAUTH-Informationen einzugeben, und der LAN-zu-LAN-Tunnel schlägt mit CONF_XAUTH in der Ausgabe des Befehls show crypto isakmp sacommand fehl. Dies ist ein Beispiel für die SA-Ausgabe:
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
Dieses Problem betrifft nur Cisco IOS®, wenn ASA nicht von diesem Problem betroffen ist, da Tunnelgruppen verwendet werden. Führen Sie das Schlüsselwort o-xauthaus aus, wenn Sie den ISAKMP-Schlüssel eingeben, damit das Gerät den Peer nicht zur Eingabe von XAUTH-Informationen (Benutzername und Kennwort) auffordert. Dieses Schlüsselwort deaktiviert XAUTH für statische IPsec-Peers. Führen Sie auf dem Gerät, auf dem L2L- und RA VPN auf derselben Crypto Map konfiguriert sind, einen ähnlichen Befehl aus:
router(config)#crypto isakmp key cisco123 address 172.22.1.164 no-xauth
In einem Szenario, in dem die ASA als Easy VPN-Server fungiert, kann der Easy VPN-Client aufgrund eines Xauth-Problems keine Verbindung zum Headend herstellen. Deaktivieren Sie die Benutzerauthentifizierung im ASA-Gerät, um das Problem zu beheben:
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
Im Abschnitt Miscellaneousdieses Dokuments finden Sie weitere Informationen zum Befehl sakmp ikev1-user-authentication.
VPN-Pool aufgebraucht
Wenn der dem VPN-Pool zugewiesene Bereich von IP-Adressen nicht ausreicht, können Sie die Verfügbarkeit von IP-Adressen auf zwei Arten erweitern:
-
Entfernen Sie den vorhandenen Bereich, und definieren Sie den neuen Bereich:
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
-
Wenn nicht zusammenhängende Subnetze zum VPN-Pool hinzugefügt werden müssen, können Sie zwei separate VPN-Pools definieren und diese dann unter den "Tunnelgruppenattributen " angeben. Hier ein Beispiel:
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
Die Reihenfolge, in der Sie die Pools angeben, ist wichtig, da die ASA Adressen aus diesen Pools in der Reihenfolge zuweist, in der die Pools in diesem Befehl angezeigt werden. Die Adresspooleinstellungen im Gruppenrichtlinien-Befehl "address pools" setzen die lokalen Pooleinstellungen im Befehl tunnel-group address-pool immer außer Kraft.
Probleme mit der Latenz für VPN-Client-Datenverkehr
Wenn bei einer VPN-Verbindung Latenzprobleme auftreten, überprüfen Sie diese Bedingungen, um dieses Problem zu beheben:
-
Überprüfen Sie, ob die MSS des Pakets weiter reduziert werden kann.
-
Wenn IPsec/tcp anstelle von IPsec/udp verwendet wird, konfigurieren Sie "erve-vpn-flow".
-
Laden Sie die Cisco ASA neu.
VPN-Clients können keine Verbindung mit ASA herstellen
Problem
Cisco VPN-Clients können sich nicht authentifizieren, wenn Xauth mit dem Radius-Server verwendet wird.
Lösung
Manchmal, wenn die Xauth-Zeitüberschreitung auftritt, können Sie den Zeitüberschreitungswert für den AAA-Server erhöhen, um dieses Problem zu beheben. Beispiele:
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
Problem
Cisco VPN-Clients können sich nicht authentifizieren, wenn X-auth mit dem Radius-Server verwendet wird.
Lösung
Stellen Sie zunächst sicher, dass die Authentifizierung ordnungsgemäß funktioniert. Um das Problem einzugrenzen, überprüfen Sie zuerst die Authentifizierung mit der lokalen Datenbank auf der ASA.
tunnel-group tggroup general-attributes
authentication-server-group none
authentication-server-group LOCAL
exit
Wenn dies funktioniert, hängt das Problem mit der Radius-Serverkonfiguration zusammen. Überprüfen Sie die Konnektivität des Radius-Servers von der ASA. Wenn der Ping ohne Probleme durchgeführt wird, überprüfen Sie die Radius-bezogene Konfiguration auf der ASA und die Datenbankkonfiguration auf dem Radius-Server. Sie können den Befehl debug radius ausführen, um Probleme mit dem Radius zu beheben. Informationen zur Beispieldebug-Radiusausgabe finden Sie unter dieser Beispielausgabe. Bevor Sie den Befehl debugauf dem ASA-Gerät verwenden, lesen Sie diese DokumentationWarnmeldung.
VPN-Client unterbricht die Verbindung häufig beim ersten Versuch oder „Security VPN Connection terminated by peer. Reason 433" (Grund 433) oder "Secure VPN Connection ended by Peer Reason 433:(Grund nicht durch Peer angegeben)"
Problem
Benutzer von Cisco VPN-Clients erhalten diesen Fehler, wenn sie versuchen, eine Verbindung zum Head-End-VPN-Gerät herzustellen.
- Der VPN-Client bricht die Verbindung beim ersten Versuch häufig ab.
- Die Sicherheits-VPN-Verbindung wurde aus Peer-Reason 433 beendet.
- Die sichere VPN-Verbindung wurde von der Gegenstelle beendet. Grund 433: (Grund wurde von der Gegenstelle nicht angegeben).
- Versucht, eine Netzwerk- oder Broadcast-IP-Adresse zuzuweisen, wobei (x.x.x.x) aus dem Pool entfernt wurde.
Lösung 1
Dieses Problem kann sich auf die Zuweisung des IP-Pools über ASA, Radius-Server, DHCP-Server oder den Radius-Server beziehen, der als DHCP-Server fungiert. Führen Sie den Befehl debug cryptoaus, um zu überprüfen, ob die Netzmaske und die IP-Adressen korrekt sind. Stellen Sie außerdem sicher, dass der Pool nicht die Netzwerkadresse und die Rundrufadresse enthält. Radius-Server müssen den Clients die richtigen IP-Adressen zuweisen.
Lösung 2
Dieses Problem tritt auch aufgrund des Fehlers der erweiterten Authentifizierung auf. Sie müssen den AAA-Server überprüfen, um diesen Fehler zu beheben. Überprüfen Sie das Kennwort für die Serverauthentifizierung auf dem Server und dem Client. Durch erneutes Laden des AAA-Servers kann dieses Problem behoben werden.
Lösung 3
Eine weitere Problemumgehung für dieses Problem ist die Deaktivierung der Bedrohungserkennungsfunktion. Bei mehreren erneuten Übertragungen für verschiedene und unvollständige Sicherheitszuordnungen (SAs) geht die ASA mit aktivierter Funktion zur Bedrohungserkennung davon aus, dass ein Scan-Angriff stattgefunden hat, und die VPN-Ports werden als Haupttäter markiert. Deaktivieren Sie die Funktion zur Erkennung von Sicherheitsrisiken, da dies zu Overhead-Problemen bei der ASA-Verarbeitung führen kann. Führen Sie die folgenden Befehle aus, um die Erkennung von Sicherheitsrisiken zu deaktivieren:
no threat-detection basic-threat no threat-detection scanning-threat shun no threat-detection statistics no threat-detection rate
Dies kann als Problemumgehung verwendet werden, um zu überprüfen, ob das Problem dadurch behoben wird. Stellen Sie sicher, dass Sie die Erkennung von Sicherheitsrisiken auf der Cisco ASA deaktivieren, da dadurch mehrere Sicherheitsfunktionen beeinträchtigt werden, z. B. die Minimierung der Scanversuche, DoS mit ungültigem SPI, Pakete, die die Anwendungsinspektion nicht bestehen, und unvollständige Sitzungen.
Lösung 4
Dieses Problem tritt auch auf, wenn ein Transformationssatz nicht ordnungsgemäß konfiguriert ist und eine ordnungsgemäße Konfiguration des Transformationssatzes das Problem löst.
Remote-Zugriffs- und EZVPN-Benutzer stellen eine Verbindung zu VPN her, können aber nicht auf externe Ressourcen zugreifen
Problem
- Benutzer mit Remote-Zugriff haben nach dem Herstellen einer VPN-Verbindung keine Internetverbindung mehr.
- Benutzer mit Remote-Zugriff können nicht auf Ressourcen zugreifen, die sich hinter anderen VPNs auf demselben Gerät befinden.
- Benutzer mit Remote-Zugriff können nur auf das lokale Netzwerk zugreifen.
Lösungen
Versuchen Sie folgende Lösungen, um das Problem zu beheben:
Kein Zugriff auf die Server in der DMZ möglich
Sobald der VPN-Client eingerichtet ist, der IPsec-Tunnel mit dem VPN-Headend-Gerät (ASA/Cisco IOS® Router), können VPN-Client-Benutzer jedoch auf die Ressourcen des INSIDE-Netzwerks (10.10.10.0/24) zugreifen. können sie nicht auf das DMZ-Netzwerk zugreifen (10.1.1.0/24).
Diagramm
Vergewissern Sie sich, dass der Split-Tunnel KEINE NAT-Konfiguration zum Headend-Gerät hinzugefügt wurde, um auf die Ressourcen im DMZ-Netzwerk zuzugreifen.
ASA-Konfiguration
Diese Konfiguration zeigt, wie die NAT-Ausnahme für das DMZ-Netzwerk konfiguriert wird, damit die VPN-Benutzer auf das DMZ-Netzwerk zugreifen können:
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
Wenn Sie einen neuen Eintrag für die NAT-Konfiguration hinzugefügt haben, löschen Sie die NAT-Übersetzung.
Clear xlate Clear local
Überprüfung
Wenn der Tunnel eingerichtet ist, wechseln Sie zum Cisco VPN Client, und wählen Sie Status > Route Details (Status > Routendetails), um zu überprüfen, ob die sicheren Routen sowohl für das DMZ- als auch für das INSIDE-Netzwerk angezeigt werden.
Siehe ASA: Neuen Tunnel oder Remote Access zu einem vorhandenen L2L VPN hinzufügen - Cisco für die erforderlichen Schritte zum Hinzufügen eines neuen VPN-Tunnels oder eines Remote Access-VPN zu einer bereits vorhandenen L2L VPN-Konfiguration. Weitere Informationen finden Sie auch unterASA: Allow Split Tunneling for VPN Clients on the ASA Configuration example for step-by-step instructions on how to allow VPN Clients access to the internet during tunneled into a Cisco 5500 Series Adaptive Security Appliance (ASA).
VPN-Clients können DNS nicht auflösen
Wenn der Tunnel eingerichtet ist und VPN-Clients den DNS nicht auflösen können, kann sich das Problem auf die DNS-Serverkonfiguration im Headend-Gerät (ASA) beziehen. Überprüfen der Verbindung zwischen den VPN-Clients und dem DNS-Server Die DNS-Serverkonfigurationen müssen unter der Gruppenrichtlinie konfiguriert und unter der Gruppenrichtlinie in den allgemeinen Tunnelgruppenattributen angewendet werden:
!--- 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
VPN-Clients können keine namensbasierte Verbindung zu internen Servern herstellen
Der VPN-Client kann die Hosts oder Server des internen Remote- oder Headend-Netzwerks nicht nach Namen pingen. Sie müssen die Split-DNS-Konfiguration auf dem ASA-Gerät aktivieren, um dieses Problem zu beheben.
Split-Tunnel: Kein Zugriff auf das Internet oder ausgeschlossene Netzwerke möglich
Mithilfe des Split-Tunnels können IPsec-Clients für den Remote-Zugriff Pakete in verschlüsselter Form bedingt über den IPsec-Tunnel oder in unverschlüsselter Form an eine Netzwerkschnittstelle weiterleiten, wo sie an ihr endgültiges Ziel weitergeleitet werden.
Split-tunnel sind standardmäßig deaktiviert. Sie können sehen, dass dieser den CommandTunnelAll-Datenverkehr ausführt.
split-tunnel-policy {tunnelall | tunnelspecified | excludespecified}
Die Option excludeSpecified wird nur für Cisco VPN Clients unterstützt, nicht EZVPN Clients.
ciscoasa(config-group-policy)#split-tunnel-policy excludespecified
Detaillierte Konfigurationsbeispiele für Split-Tunnel finden Sie in den folgenden Dokumenten:
Hairpin-Lösung
Diese Funktion ist nützlich für VPN-Datenverkehr, der über eine Schnittstelle eingeht, dann aber über dieselbe Schnittstelle weitergeleitet wird. Beispielsweise sind in einem Hub-and-Spoke-VPN-Netzwerk, in dem der Hub die Security Appliance ist, und in Remote-VPN-Netzwerken Spokes. Der Spoke-to-Spoke-Kommunikationsverkehr muss in die Security Appliance und dann wieder in die andere Spoke-Leitung geleitet werden. Führen Sie die Konfiguration für gleichen Datenverkehr aus, um zu ermöglichen, dass der Datenverkehr über dieselbe Schnittstelle ein- und ausgeht:
securityappliance(config)#same-security-traffic permit intra-interface
Lokaler LAN-Zugang
RAS-Benutzer stellen eine Verbindung mit dem VPN her und können nur eine Verbindung mit lokalen Netzwerken herstellen. Ein ausführlicheres Konfigurationsbeispiel finden Sie unterASA: Lokalen LAN-Zugriff für VPN-Clients zulassen.
Überlappende private Netzwerke
Problem
Wenn Sie nach dem Tunnelaufbau nicht auf das interne Netzwerk zugreifen können, überprüfen Sie die dem VPN-Client zugewiesene IP-Adresse, die sich mit dem internen Netzwerk hinter dem Headend-Gerät überschneidet.
Lösung
Überprüfen Sie, ob sich die IP-Adressen im Pool, die den VPN-Clients zugewiesen sind, das interne Netzwerk des Headend-Geräts und das interne Netzwerk des VPN-Clients in unterschiedlichen Netzwerken befinden. Sie können dasselbe Hauptnetzwerk verschiedenen Subnetzen zuweisen, jedoch treten manchmal Routing-Probleme auf. Weitere Beispiele finden Sie unter Diagramm undBeispiel für DMZ-Abschnitt "Kein Zugriff auf Server möglich".
m=Mehr als drei VPN-Client-Benutzer können nicht verbunden werden
Problem
Nur drei VPN-Clients können eine Verbindung mit ASA/ASA herstellen, und die Verbindung für den vierten Client fällt aus. Dabei wird folgende Fehlermeldung angezeigt:
Secure VPN Connection terminated locally by the client. Reason 413: User Authentication failed.
tunnel rejected; the maximum tunnel count has been reached
Lösungen
In den meisten Fällen hängt dieses Problem mit einer Einstellung für die gleichzeitige Anmeldung innerhalb der Gruppenrichtlinie und dem maximalen Sitzungslimit zusammen. Versuchen Sie folgende Lösungen, um das Problem zu beheben:
Konfigurieren gleichzeitiger Anmeldungen
Wenn das Kontrollkästchen Vererbung in ASDM aktiviert ist, ist nur die Standardanzahl gleichzeitiger Anmeldungen für den Benutzer zulässig. Der Standardwert für gleichzeitige Anmeldungen ist 3. Erhöhen Sie den Wert für gleichzeitige Anmeldungen, um dieses Problem zu beheben.
-
Starten Sie ASDM, und navigieren Sie dann zuConfiguration > VPN > Group Policy.
-
Wählen Sie die entsprechende Gruppe aus, und klicken Sie auf die Schaltfläche Bearbeiten.
-
Deaktivieren Sie auf der Registerkarte Allgemein das Kontrollkästchen Vererbung fürSimultane Anmeldungen unter Verbindungseinstellungen. Wählen Sie einen geeigneten Wert im Feld aus.
Der Mindestwert für dieses Feld ist 0. Dadurch werden Anmeldungen deaktiviert und der Benutzerzugriff verhindert. Wenn Sie sich mit demselben Benutzerkonto von einem anderen PC aus anmelden, wird die aktuelle Sitzung (die Verbindung, die von einem anderen PC mit demselben Benutzerkonto hergestellt wurde) beendet, und die neue Sitzung wird eingerichtet. Dies ist das Standardverhalten und unabhängig von gleichzeitigen VPN-Anmeldungen.
Konfigurieren der ASA mit der CLI
Führen Sie diese Schritte aus, um die gewünschte Anzahl gleichzeitiger Anmeldungen zu konfigurieren. In diesem Beispiel wurde 20 als gewünschter Wert ausgewählt:
ciscoasa(config)#group-policy Bryan attributes ciscoasa(config-group-policy)#vpn-simultaneous-logins 20
Weitere Informationen zu diesem Befehl finden Sie unter Cisco Security Appliance Command Reference. Führen Sie den Befehl vpn-sessiondb max-session-limit im globalen Konfigurationsmodus aus, um die Anzahl der VPN-Sitzungen auf einen niedrigeren Wert zu begrenzen, als von der Security Appliance zugelassen wurde. Führen Sie die Überschreibung dieses Befehls aus, um die Sitzungsbeschränkung zu entfernen, und führen Sie den Befehl erneut aus, um die aktuelle Einstellung zu überschreiben:
vpn-sessiondb max-session-limit {session-limit}
Dieses Beispiel zeigt, wie Sie einen maximalen VPN-Sitzungsgrenzwert von 450 festlegen:
hostname#vpn-sessiondb max-session-limit 450
Konfigurieren
Fehlermeldung:
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>
Lösung
Führen Sie diese Schritte aus, um die gewünschte Anzahl gleichzeitiger Anmeldungen zu konfigurieren. Sie können die gleichzeitigen Anmeldungen für diese SA auch auf 5 einstellen. Wählen Sie Configuration > User Management > Groups > Modify 10.19.187.229 > General > Simultaneous Logins (Konfiguration > Benutzerverwaltung > Gruppen > Ändern 10.19.187.229 > General > Simultaneous Logins), und ändern Sie die Anzahl der Anmeldungen auf5.
Die Sitzung oder eine Anwendung kann nicht initiiert werden, und die Übertragung nach dem Tunnelaufbau ist langsam
Problem
Nach der Einrichtung des IPsec-Tunnels wird die Anwendung oder die Sitzung nicht über den gesamten Tunnel hinweg initiiert.
Lösungen
Führen Sie den Befehl epingaus, um das Netzwerk zu überprüfen oder zu ermitteln, ob der Anwendungsserver vom Netzwerk aus erreichbar ist. Es kann ein Problem mit der maximalen Segmentgröße (MSS) für transiente Pakete auftreten, die einen Router oder ein /ASA-Gerät durchlaufen, insbesondere TCP-Segmente mit dem SYN-Bit-Set.
Cisco IOS® Router - Ändern des MSS-Werts in der externen Schnittstelle (Tunnelendschnittstelle) des Routers
Führen Sie die folgenden Befehle aus, um den MSS-Wert in der externen Schnittstelle (Tunnelendschnittstelle) des Routers zu ändern:
Router>enable Router#configure terminal Router(config)#interface ethernet0/1 Router(config-if)#ip tcp adjust-mss 1300 Router(config-if)#end
Diese Meldungen zeigen die Debug-Ausgabe für TCP MSS an:
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)]
Die MSS wird auf dem Router wie konfiguriert auf 1300 eingestellt. Weitere Informationen finden Sie unterASA und Cisco IOS®: VPN-Fragmentierung.
ASA - Weitere Informationen finden Sie in der Dokumentation zu /ASA
Es besteht keine Möglichkeit, ordnungsgemäß auf das Internet zuzugreifen, oder die Übertragung über den Tunnel ist langsam, da eine Fehlermeldung zur MTU-Größe und MSS-Probleme vorliegen. Lesen Sie dieses Dokument, um das Problem zu beheben:
VPN-Tunnel kann nicht von ASA initiiert werden
Problem
Sie können den VPN-Tunnel nicht von der ASA-Schnittstelle aus und nach der Tunneleinrichtung initiieren. Der Remote-End-/VPN-Client kann keinen Ping an die interne Schnittstelle der ASA im VPN-Tunnel senden. Beispielsweise kann der VPN-Client keine SSH- oder HTTP-Verbindung zu ASAs innerhalb der Schnittstelle über einen VPN-Tunnel initiieren.
Lösung
Die interne Schnittstelle kann nur dann vom anderen Ende des Tunnels angepingt werden, wenn der Befehl management-access im globalen Konfigurationsmodus konfiguriert ist.
ASA-02(config)#management-access inside ASA-02(config)#show management-access management-access inside
Dieser Befehl unterstützt auch die SSH-Initiierung oder die HTTP-Verbindung für die interne Schnittstelle der ASA über einen VPN-Tunnel. Die Informationen gelten auch für DMZ-Schnittstellen. Wenn Sie z. B. einen Ping an die DMZ-Schnittstelle von /ASA senden oder einen Tunnel von der DMZ-Schnittstelle aus initiieren möchten, ist die Ausführung des DMZ-Befehls für den Verwaltungszugriff erforderlich.
ASA-02(config)#management-access DMZ
Wenn der VPN-Client keine Verbindung herstellen kann, stellen Sie sicher, dass die ESP- und UDP-Ports offen sind. Wenn diese Ports jedoch nicht geöffnet sind, versuchen Sie, über TCP 10000 eine Verbindung herzustellen. Wählen Sie dazu diesen Port unter dem VPN-Client-Verbindungseintrag aus. Klicken Sie mit der rechten Maustaste auf Ändern > Registerkarte Transport > IPsec über TCP.
Datenverkehr kann nicht über VPN-Tunnel weitergeleitet werden
Problem
Sie können Datenverkehr nicht über einen VPN-Tunnel weiterleiten.
Lösung
Dieses Problem kann auch auftreten, wenn ESP-Pakete blockiert werden. Um dieses Problem zu beheben, konfigurieren Sie den VPN-Tunnel neu. Sie können auch auftreten, wenn Daten nicht verschlüsselt, sondern nur über den VPN-Tunnel entschlüsselt werden, wie in der folgenden Ausgabe gezeigt:
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
Um dieses Problem zu beheben, überprüfen Sie die folgenden Bedingungen:
-
Wenn die Crypto-Zugriffslisten mit denen des Remote-Standorts übereinstimmen und die NAT 0-Zugriffslisten korrekt sind.
-
Wenn das Routing korrekt ist und der Datenverkehr außerhalb der Schnittstelle eintrifft, die den Datenverkehr innerhalb der Schnittstelle weiterleitet, zeigt die Beispielausgabe, dass die Entschlüsselung abgeschlossen ist, die Verschlüsselung jedoch nicht erfolgt.
-
Wenn der Befehl ysopt permit connection-vpn auf der ASA konfiguriert wird. Falls nicht konfiguriert, konfigurieren Sie diesen Befehl, da er den verschlüsselten/VPN-Verkehr zur ASA von der Überprüfung der Schnittstellenzugriffskontrolllisten ausnimmt.
Konfigurieren des Backup-Peers für den VPN-Tunnel auf derselben Crypto Map
Problem
Sie möchten mehrere Backup-Peers für einen einzelnen VPN-Tunnel verwenden.
Lösung
Die Konfiguration mehrerer Peers entspricht der Bereitstellung einer Fallbackliste. Für jeden Tunnel versucht die Security-Appliance, mit dem ersten Peer in der Liste zu verhandeln. Wenn dieser Peer nicht antwortet, arbeitet sich die Security-Appliance in der Liste nach unten, bis entweder ein Peer antwortet oder keine weiteren Peers in der Liste vorhanden sind. Auf der ASA ist bereits eine Crypto Map als primärer Peer konfiguriert. Der sekundäre Peer kann nach dem primären hinzugefügt werden. Diese Beispielkonfiguration zeigt den primären Peer als X.X.X.X. und den Backup-Peer als Y.Y.Y.Y. an:
ASA(config)#crypto map mymap 10 set peer X.X.X.X Y.Y.Y.Y
Deaktivieren/Neustarten des VPN-Tunnels
Problem
Führen Sie die in diesem Abschnitt beschriebenen Schritte aus, um den VPN-Tunnel vorübergehend zu deaktivieren und den Dienst neu zu starten.
Lösung
Führen Sie im globalen Konfigurationsmodus den Befehl rypto map interface aus, um eine zuvor definierte Crypto Map für eine Schnittstelle zu entfernen. Führen Sie das Formular dieses Befehls aus, um den Crypto Map Set von der Schnittstelle zu entfernen.
hostname(config)#no crypto map map-name interface interface-name
Mit diesem Befehl wird eine Crypto Map entfernt, die für jede aktive Sicherheits-Appliance-Schnittstelle festgelegt wurde, und der IPsec-VPN-Tunnel wird in dieser Schnittstelle deaktiviert. Um den IPsec-Tunnel auf einer Schnittstelle neu zu starten, müssen Sie einer Schnittstelle einen Krypto-Zuordnungssatz zuweisen, bevor diese Schnittstelle IPsec-Dienste bereitstellen kann.
hostname(config)#crypto map map-name interface interface-name
Einige Tunnel nicht verschlüsselt
Problem
Wenn eine große Anzahl von Tunneln auf dem VPN-Gateway konfiguriert ist, leiten einige Tunnel den Datenverkehr nicht weiter. Die ASA empfängt keine verschlüsselten Pakete für diese Tunnel.
Lösung
Dieses Problem tritt auf, weil die ASA die verschlüsselten Pakete nicht durch die Tunnel weiterleitet. In der ASP-Tabelle werden doppelte Verschlüsselungsregeln erstellt.
Error:- %ASA-5-713904: Group = DefaultRAGroup, IP = x.x.x.x, ... Nicht unterstützter Transaktionsmodus Version 2.Tunnel beendet
Problem
%ASA-5-713904: Group = DefaultRAGroup, IP = 192.0.2.0,... nicht unterstützter Transaktionsmodus v2 version.Tunnel terminatederror-Meldung wird angezeigt.
Lösung
Der Grund für die v2-Fehlermeldung für den Transaktionsmodus ist, dass ASA nur IKE-Moduskonfiguration v6 und nicht die alte Version v2 unterstützt. Verwenden Sie IKE Mode Config v6, um diesen Fehler zu beheben.
Fehler:- %ASA-6-722036: Gruppe client-group Benutzer xxxx IP x.x.x.x überträgt großes Paket 1220 (Schwellenwert 1206)
Problem
%ASA-6-722036: Die Fehlermeldung Group < client-group > User < xxxx > IP < x.x.x.x> Transmitting large packet 1220 (threshold 1206) wird in den Protokollen der ASA angezeigt. Was bedeutet dieses Protokoll und wie wird dieses Problem behoben?
Lösung
Diese Protokollmeldung gibt an, dass ein großes Paket an den Client gesendet wurde. Die Paketquelle kannte die MTU des Clients nicht. Dies kann auf die Komprimierung nicht komprimierbarer Daten zurückzuführen sein. Sie können die SVC-Komprimierung mit dem Befehl vc komprimierung none deaktivieren, wodurch das Problem behoben wird.
Fehlermeldung bei aktivierter QoS an einem Ende des VPN-Tunnels
Problem
Wenn Sie QoS an einem Ende des VPN-Tunnels aktiviert haben, wird folgende Fehlermeldung angezeigt:
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
Lösung
Diese Meldung wird normalerweise angezeigt, wenn ein Ende des Tunnels QoS durchführt. Dies geschieht, wenn ein Paket als außer Betrieb erkannt wird. Sie können QoS deaktivieren, um dies zu stoppen. Sie kann jedoch ignoriert werden, solange der Datenverkehr durch den Tunnel fließen kann.
Warnung: Kryptografiezuordnungseintrag unvollständig
Problem
Wenn Sie den Befehl crypto map mymap 20 ipsec-isakmps ausführen, wird folgender Fehler angezeigt: WARNUNG: Crypto Map-Eintrag unvollständig
Beispiele:
ciscoasa(config)#crypto map mymap 20 ipsec-isakmp WARNING: crypto map entry incomplete
Lösung
Dies ist eine normale Warnung, wenn Sie eine neue Crypto Map definieren. eine Erinnerung, dass Parameter wie access-list (match address), transform set und peer address konfiguriert werden müssen, bevor sie ordnungsgemäß funktionieren. Standardmäßig wird auch die erste Zeile angezeigt, die Sie zur Definition der Crypto Map eingeben. Diese wird jedoch nicht in der Konfiguration angezeigt.
Error:- %ASA-4-400024: IDS:2151 Large ICMP Packet von der externen Schnittstelle
Problem
Ein großes Ping-Paket kann nicht über den VPN-Tunnel weitergeleitet werden. Wenn wir versuchen, große Ping-Pakete weiterzuleiten, erhalten wir den Fehler %ASA-4-400024: IDS:2151 Large ICMP packet from to on interface outside.
Lösung
Deaktivieren Sie die Signaturen 2150 und 2151, um dieses Problem zu beheben. Wenn die Signaturen deaktiviert sind, funktioniert der Ping-Befehl ordnungsgemäß. Führen Sie die folgenden Befehle aus, um die Signaturen zu deaktivieren:
- ASA(config)#ip audit signature 2151 disable
- ASA(config)#ip audit signature 2150 disable
Fehler:- %ASA-4-402119: IPSEC: Protokollpaket (SPI=spi, Sequenznummer= seq_num) von Remote_IP (Benutzername) an Local_IP empfangen, das nicht auf Anti-Replay überprüft werden konnte
Problem
Ich habe in den Protokollmeldungen der ASA folgenden Fehler erhalten:
Fehler:- %|ASA-4-402119: IPSEC: Protokollpaket (SPI=spi, Sequenznummer= seq_num) von remote_IP (Benutzername) an local_IP empfangen, bei dem die Anti-Replay-Prüfung fehlgeschlagen ist.
Lösung
Um diesen Fehler zu beheben, führen Sie den Befehl rypto ipsec security-association replay window-size aus, um die Fenstergröße zu variieren.
hostname(config)#crypto ipsec security-association replay window-size 1024
Cisco empfiehlt die Verwendung der vollen Fenstergröße 1024, um alle Anti-Replay-Probleme zu beseitigen.
Fehlermeldung - %ASA-4-407001: Deny traffic for local-host interface_name:inside_address, license limit of number exceeded
Problem
Nur wenige Hosts können keine Verbindung zum Internet herstellen. Diese Fehlermeldung wird im Syslog angezeigt: Fehlermeldung - %ASA-4-407001: Deny traffic for local-host interface_name:inside_address, license limit of number exceeded
Lösung
Diese Fehlermeldung wird angezeigt, wenn die Anzahl der Benutzer das Benutzerlimit für die verwendete Lizenz überschreitet. Dieser Fehler kann durch ein Upgrade der Lizenz auf eine höhere Anzahl von Benutzern behoben werden. Die Benutzerlizenz kann je nach Bedarf 50, 100 oder eine unbegrenzte Zahl von Benutzern enthalten.
Fehlermeldung: %VPN_HW-4-PACKET_ERROR:
Problem
Die Fehlermeldung "%VPN_HW-4-PACKET_ERROR:" zeigt an, dass das vom Router empfangene ESP-Paket mit HMAC nicht übereinstimmt. Dieser Fehler kann durch folgende Probleme verursacht werden:
-
VPN-H/W-Modul defekt
-
Beschädigtes ESP-Paket
Lösung
So beheben Sie diese Fehlermeldung:
-
Ignorieren Sie die Fehlermeldungen, es sei denn, der Datenverkehr ist unterbrochen.
-
Wenn der Datenverkehr unterbrochen wird, ersetzen Sie das Modul.
Fehlermeldung: Command rejected: delete crypto connection between VLAN XXXX and XXXX, first
Problem
Wenn Sie versuchen, ein zulässiges VLAN am Trunk-Port auf einem Switch hinzuzufügen, wird folgende Fehlermeldung angezeigt: Command rejected: Löschen Sie zunächst die Krypto-Verbindung zwischen VLAN XXXX und VLAN XXXX. Der WAN-Edge-Trunk kann nicht geändert werden, um zusätzliche VLANs zuzulassen. Wenn Sie dem IPSEC VPN SPA-Trunk keine VLANs hinzufügen können. Dieser Befehl wird abgelehnt, da er zu einem VLAN mit Kryptografieverbindung führt, das zur Liste der zulässigen VLANs gehört, was eine potenzielle IPSec-Sicherheitsverletzung darstellt.
Anmerkung: Dieses Verhalten gilt für alle Trunk-Ports.
Lösung
Führen Sie anstelle des Befehls no switchport trunk allowed vlan (vlanlist) den Befehl switchport trunk allows vlan nonecommand oder den Befehl "switchport trunk allowed vlan remove (vlanlist)" aus.
Fehlermeldung: % FW-3-RESPONDER_WND_SCALE_INI_NO_SCALE: Dropped Packet - Ungültige Fensterskalierungsoption für Sitzung x.x.x.x.x:27331 bis x.x.x.x:23 [Initiator(Flag 0, Faktor 0) Responder (Flag 1, Faktor 2)]
Problem
Dieser Fehler tritt auf, wenn Sie versuchen, eine Telnet-Verbindung von einem Gerät am anderen Ende eines VPN-Tunnels oder über den Router selbst herzustellen: Fehlermeldung - % FW-3-RESPONDER_WND_SCALE_INI+NO_SCALE: Verworfenes Paket - Ungültige Fensterskalierungsoption für Sitzung x.x.x.x:27331 bis x.x.x.x:23 pediaK[Initiator(Flag 0, Faktor 0) Responder (Flag 1, Faktor2)]
Lösung
Die Benutzerlizenz kann je nach Bedarf 50, 100 oder eine unbegrenzte Zahl von Benutzern enthalten. Eine Fensterskala-Funktion wurde hinzugefügt, um eine schnelle Übertragung von Daten über lange Fett-Netzwerke (LFN) zu ermöglichen. Dies sind in der Regel Verbindungen mit hoher Bandbreite und hoher Latenz. Netzwerke mit Satellitenverbindungen sind ein Beispiel für ein LFN, da Satellitenverbindungen immer hohe Ausbreitungsverzögerungen mit typischerweise hoher Bandbreite aufweisen. Um die Fensterskalierungsfunktion zur Unterstützung von LFNs zu aktivieren, muss die TCP-Fenstergröße mehr als 65.535 betragen. Diese Fehlermeldung kann behoben werden, wenn Sie die TCP-Fenstergröße auf mehr als 65.535 erhöhen.
%ASA-5-305013: Asymmetric NAT rules matched for forward and reverse . Please update this issue flows
Problem
Diese Fehlermeldung wird angezeigt, sobald der VPN-Tunnel aktiviert wird: %ASA-5-305013: Asymetrische NAT-Regelübereinstimmungen für Vorwärts- und Rückwärtslauf. Please update this issue flows.
Lösung
Um dieses Problem zu beheben, wenn sich die Schnittstelle zum Host mit NAT nicht identisch ist, verwenden Sie die zugeordnete Adresse anstelle der tatsächlichen Adresse, um die Verbindung zum Host herzustellen. Aktivieren Sie außerdem den Befehl einspect, wenn die Anwendung die IP-Adresse einbettet.
%ASA-5-713068: Received non-routine Notify message: notify_type
Problem
Diese Fehlermeldung wird angezeigt, wenn der VPN-Tunnel nicht gestartet werden kann: %ASA-5-713068: Received non-routine Notify message: notify_type
Lösung
Diese Meldung wird aufgrund einer fehlerhaften Konfiguration angezeigt (wenn Richtlinien oder ACLs auf Peers nicht gleich konfiguriert sind). Sobald die Richtlinien und ACLs abgeglichen wurden, wird der Tunnel ohne Probleme geöffnet.
%ASA-5-720012: (VPN-Secondary) Fehler beim Aktualisieren der IPSec-Failover-Laufzeitdaten auf der Standby-Einheit (oder) %ASA-6-720012: (VPN-Einheit) Fehler beim Aktualisieren der IPsec-Failover-Laufzeitdaten auf der Standby-Einheit
Problem
Eine der folgenden Fehlermeldungen wird angezeigt, wenn Sie versuchen, ein Upgrade der Cisco Adaptive Security Appliance (ASA) durchzuführen:
- %ASA-5-720012: (VPN-Secondary) Fehler beim Aktualisieren der IPSec-Failover-Laufzeitdaten auf der Standby-Einheit.
- %ASA-6-720012: (VPN-Einheit) Fehler beim Aktualisieren der IPsec-Failover-Laufzeitdaten auf der Standby-Einheit.
Lösung
Diese Fehlermeldungen sind informative Fehler und haben keine Auswirkungen auf die Funktionen der ASA oder des VPN. Sie werden angezeigt, wenn das VPN-Failover-Subsystem die IPsec-bezogenen Laufzeitdaten nicht aktualisieren kann, da der zugehörige IPsec-Tunnel auf der Standby-Einheit gelöscht wurde. Führen Sie den Befehl wr standby auf dem aktiven Gerät aus, um diese zu beheben.
Error:- %ASA-3-713063: IKE Peer address not configured for destination 0.0.0.0
Problem
Die Fehlermeldung %ASA-3-713063: Die Fehlermeldung IKE-Peer-Adresse, die nicht für das Ziel 0.0.0.0 konfiguriert wurde, wird angezeigt, und der Tunnel wird nicht angezeigt.
Lösung
Diese Meldung wird angezeigt, wenn die IKE-Peer-Adresse nicht für einen L2L-Tunnel konfiguriert ist. Der Fehler kann behoben werden, wenn Sie die Sequenznummer der Crypto Map ändern, die Crypto Map entfernen und erneut anwenden.
Fehler: %ASA-3-752006: Tunnel Manager failed to dispatch a KEY_ACQUIRE message
Problem
Die Fehlermeldung %ASA-3-752006: Tunnel Manager failed to dispatch a KEY_ACQUIRE message. Wahrscheinliche Fehlkonfiguration der Crypto Map oder Tunnel-Gruppe. wird auf der Cisco ASA angezeigt.
Lösung
Diese Fehlermeldung kann durch eine falsche Konfiguration der Krypto-Zuordnung oder der Tunnel-Gruppe verursacht werden. Stellen Sie sicher, dass beide korrekt konfiguriert sind. Weitere Informationen zu dieser Fehlermeldung finden Sie unter Fehler 752006.
Hier einige Korrekturmaßnahmen:
-
Entfernen Sie die Krypto-ACL, die der dynamischen Zuordnung zugeordnet ist.
-
Entfernen Sie nicht verwendete IKEv2-bezogene Konfigurationen, falls vorhanden.
-
Überprüfen Sie, ob die Krypto-ACL richtig zugeordnet ist.
-
Entfernen Sie alle doppelten Zugriffslisteneinträge.
Fehler: %ASA-4-402116: IPSEC: Ein ESP-Paket (SPI= 0x99554D4E, Sequenznummer= 0x9E) wurde von XX.XX.XX.XX (Benutzer= XX.XX.XX.XX) an YY.YY.YY.YY empfangen.
In einer LAN-zu-LAN-VPN-Tunnel-Einrichtung wird folgender Fehler auf einem ASA-Ende empfangen:
Das entkapselte innere Paket stimmt nicht mit der ausgehandelten Richtlinie in der SA überein.
Das Paket gibt als Ziel 10.32.77.67, als Quelle 10.105.30.1 und als Protokoll icmp an.
Die SA gibt ihren lokalen Proxy als 10.32.77.67/255.255.255.255/ip/0 und ihren remote_proxy als 10.105.42.192/255.255.255.224/ip/0 an.
Lösung
Sie müssen die eindeutigen Zugriffslisten für den Datenverkehr überprüfen, die an beiden Enden des VPN-Tunnels definiert sind. Beide müssen als exakte Spiegelbilder übereinstimmen.
Failed to launch 64-bit VA installer to enable the virtual adapter due to error 0xffffffff
Problem
Die Protokollnachricht Failed to launch 64-bit VA installer to enable the virtual adapter due to error 0xffffffff wird angezeigt, wenn AnyConnect keine Verbindung herstellen kann.
Lösung
Gehen Sie wie folgt vor, um das Problem zu beheben:
-
Gehen Sie zuSystem > Internet Communication Management > Internet Communication settings, und stellen Sie sicher, dass die automatische Aktualisierung der Stammzertifikate deaktiviert ist.
-
Wenn sie deaktiviert ist, deaktivieren Sie die gesamte administrative Vorlage des Gruppenrichtlinienobjekts, das dem betroffenen Computer zugewiesen ist, und testen Sie sie erneut. Weitere Informationen finden Sie unterDeaktivieren des automatischen Stammzertifikatupdates.
Cisco VPN-Client funktioniert nicht mit der Datenkarte unter Windows 7
Problem
Der Cisco VPN-Client funktioniert nicht mit der Datenkarte unter Windows 7.
Lösung
Der unter Windows 7 installierte Cisco VPN-Client funktioniert nicht mit 3G-Verbindungen, da auf VPN-Clients, die auf Windows 7-Systemen installiert sind, keine Datenkarten unterstützt werden.
Warnung: „VPN functionality may not work at all“
Problem
Bei Versuchen, ISAKMP auf der externen Schnittstelle von ASA zu aktivieren, wird diese Warnmeldung empfangen:
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.
Der Zugriff auf die ASA über SSH und HTTPS wird gestoppt, und andere SSL-Clients sind ebenfalls betroffen.
Lösung
Dieses Problem ist auf Speicheranforderungen verschiedener Module wie Logger und Krypto zurückzuführen. Stellen Sie sicher, dass Sie nicht über den Befehl log queue 0verfügen. Dadurch wird die Warteschlangengröße auf 8192 festgelegt, und die Speicherzuweisung wird erhöht. Bei Plattformen wie ASA5505 und ASA5510 ist diese Speicherzuweisung tendenziell auf andere Module beschränkt, für die nur wenig Speicher zur Verfügung steht.
IPSec-Padding-Fehler
Problem
Folgende Fehlermeldung wird angezeigt:
%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
Lösung
Das Problem tritt auf, weil das IPSec-VPN ohne Hash-Algorithmus aushandelt. Paket-Hash stellt die Integritätsprüfung für den ESP-Kanal sicher. Aus diesem Grund werden fehlerhafte Pakete ohne Hash von der Cisco ASA unerkannt akzeptiert und versucht, diese Pakete zu entschlüsseln. Da diese Pakete jedoch fehlerhaft sind, findet die ASA Fehler bei der Paketentschlüsselung. Dies verursacht die Padding-Fehlermeldungen, die angezeigt werden. Es wird empfohlen, einen Hash-Algorithmus in den Transformationssatz für das VPN aufzunehmen und sicherzustellen, dass die Verbindung zwischen den Peers über minimale Paketfehlbildungen verfügt.
VPN-Tunnel wird nach 18 Stunden getrennt
Problem
Der VPN-Tunnel wird nach 18 Stunden getrennt, obwohl die Lebensdauer auf 24 Stunden festgelegt ist.
Lösung
Die Lebensdauer ist die maximale Zeit, die die SA für einen Rekey verwendet werden kann. Der Wert, den Sie in der Konfiguration als Lebensdauer eingeben, stimmt nicht mit der Schlüssel-Neuerstellungszeit der Sicherheitszuordnung überein. Es ist notwendig, eine neue SA (oder SA-Paar im Fall von IPsec) auszuhandeln, bevor die aktuelle abläuft. Die rekey-Zeit muss kleiner als die Lebensdauer sein, damit mehrere Versuche möglich sind, falls der erste rekey-Versuch fehlschlägt.
In den RFCs wird nicht angegeben, wie die Rekey-Zeit berechnet wird. Dies bleibt Ihrem Ermessen überlassen, daher variiert die Zeit je nach Plattform. Einige Implementierungen können einen Zufallsfaktor verwenden, um den Timer für die Schlüssel-Neuerstellung zu berechnen. Wenn die ASA beispielsweise den Tunnel initiiert, ist es normal, dass die Schlüssel mit 64800 Sekunden neu verschlüsselt werden = 75 % von 86400. Wenn der Router initiiert wird, kann die ASA länger warten, bis dem Peer mehr Zeit für die Initiierung des neuen Schlüssels zur Verfügung steht. Daher ist es normal, dass die VPN-Sitzung alle 18 Stunden getrennt wird, um einen anderen Schlüssel für die VPN-Aushandlung zu verwenden.
Datenverkehrsfluss wird nicht aufrechterhalten, nachdem der LAN-zu-LAN-Tunnel neu verhandelt wurde
Problem
Der Datenverkehrsfluss wird nicht aufrechterhalten, nachdem der LAN-zu-LAN-Tunnel neu ausgehandelt wurde.
Lösung
Die ASA überwacht jede durchlaufende Verbindung und speichert einen Eintrag in der Statustabelle in Übereinstimmung mit der Funktion für die Anwendungsinspektion. Verschlüsselte Verkehrsdetails, die das VPN passieren, werden in Form einer Sicherheitszuordnungs-Datenbank (Security Association, SA) verwaltet. Bei LAN-zu-LAN-VPN-Verbindungen werden zwei verschiedene Datenströme verwaltet. Einer davon ist der verschlüsselte Datenverkehr zwischen VPN-Gateways. Der andere ist der Datenstrom zwischen der Netzwerkressource hinter dem VPN-Gateway und dem Endbenutzer hinter dem anderen Ende.
Wenn das VPN beendet wird, werden die Flow-Details für diese bestimmte Sicherheitszuordnung gelöscht. Der von der ASA für diese TCP-Verbindung verwaltete Eintrag in der Statustabelle veraltet jedoch aufgrund fehlender Aktivität, was den Download behindert. Das bedeutet, dass die ASA die TCP-Verbindung für diesen bestimmten Datenfluss beibehält, während die Benutzeranwendung beendet wird. Die TCP-Verbindungen werden verirrt und verlieren irgendwann ihre Gültigkeit, wenn der TCP-Idle-Timer abläuft. Dieses Problem wurde mit der Einführung der Funktion "Persistent IPSec Tunneled Flows" gelöst. Der neue Befehl "sysopt connection serve-vpn-flows" wurde in die Cisco ASA integriert, um die Informationen der Statustabelle bei der Neuaushandlung des VPN-Tunnels zu speichern.
Dieser Befehl ist standardmäßig deaktiviert. Um dies zu aktivieren, pflegt die Cisco ASA die Informationen der TCP-Statustabelle, wenn sich das L2L-VPN von der Unterbrechung erholt und den Tunnel wieder herstellt.
Eine Fehlermeldung besagt, dass die Bandbreite für die Kryptofunktion erreicht wurde
Problem
Auf dem Router der 2900-Serie wird folgende Fehlermeldung angezeigt:
Fehler: 20. März 10:51:29: %CERM-4-TX_BW_LIMIT: Maximales Tx-Bandbreitenlimit von 8.500 Kbit/s für die Verschlüsselungsfunktion mit der SecurityK9-Technologiepaket-Lizenz erreicht.
Lösung
Dies ist ein bekanntes Problem, das aufgrund der strengen Richtlinien der Regierung der Vereinigten Staaten auftritt. Gemäß der securityk9-Lizenz kann sie nur eine Payload-Verschlüsselung mit Raten von bis zu 90 Mbit/s zulassen und die Anzahl der verschlüsselten Tunnel/TLS-Sitzungen für das Gerät einschränken. Weitere Informationen zu den Exportbeschränkungen für Kryptographien finden Sie unter Cisco ISR G2 SEC and HSEC Licensing.
Für Cisco Geräte wird ein unidirektionaler Datenverkehr von weniger als 85 Mbit/s innerhalb und außerhalb des ISR G2-Routers mit einer bidirektionalen Gesamtgeschwindigkeit von 170 Mbit/s abgeleitet. Diese Anforderung gilt für die Cisco ISR G2-Plattformen der Serien 1900, 2900 und 3900. Mit diesem Befehl können Sie die folgenden Einschränkungen anzeigen:
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----
Um dieses Problem zu vermeiden, erwerben Sie eine HSECK9-Lizenz. Eine Lizenz für die Funktion "hseck9" bietet eine erweiterte Payload-Verschlüsselungsfunktion mit einer höheren Anzahl an VPN-Tunneln und sicheren Sprachsitzungen. Weitere Informationen zur Lizenzierung von Cisco ISR Routern finden Sie unter Software Activation (Softwareaktivierung).
Problem: Ausgehender Verschlüsselungsverkehr im IPsec-Tunnel schlägt fehl, selbst wenn eingehender Entschlüsselungsverkehr funktioniert
Lösung
Dieses Problem wurde bei einer IPsec-Verbindung nach mehreren erneuten Schlüsseln festgestellt. Die Auslösebedingung ist jedoch unklar. Dieses Problem kann behoben werden, wenn Sie die Ausgabe des Befehls how asp drop überprüfen und überprüfen, ob der Kontextzähler für abgelaufene VPN für jedes gesendete ausgehende Paket zunimmt.
Verschiedenes
In der Ausgabe der Befehle „show crypto isakmp sa“ und „debug“ wird die Meldung „AG_INIT_EXCH“ angezeigt
Wenn der Tunnel nicht initiiert wird, wird die AG_INIT_EXCHmessage in der Ausgabe des Befehls show crypto isakmp sacommand und auch in der debugoutput angezeigt. Der Grund kann auf eine Inkongruenz der ISAKMP-Richtlinien zurückzuführen sein oder darauf, dass der udp-Port 500 blockiert ist.
Debug-Meldung „Received an IPC message during invalid state“ (Eine IPC-Meldung wurde während eines ungültigen Status empfangen) wird angezeigt
Diese Meldung dient nur der Information und hat nichts mit der Trennung des VPN-Tunnels zu tun.
Zugehörige Informationen
- ASA und Cisco IOS®: VPN-Fragmentierung
- Cisco Adaptive Security Appliances der ASA 5500-Serie
- IPSec-Aushandlung/IKE-Protokolle
- Technischer Support und Dokumentation für Cisco Systeme
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
2.0 |
22-Jul-2026
|
Aktualisierte Rechtschreibung, Grammatik, eingefügte horizontale Linien in separate Abschnitte zur besseren Lesbarkeit, korrigierte CCW-Warnungen. |
1.0 |
31-Mar-2014
|
Erstveröffentlichung |
Feedback