Konfigurieren von richtlinienbasiertem und routenbasiertem VPN von ASA und FTD zu MS Azure
Inhalt
Einleitung
In diesem Dokument werden die Konzepte und die Konfiguration für ein VPN zwischen Cisco ASA und Cisco Secure Firewall sowie Microsoft Azure Cloud Services beschrieben.
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
- Für ein IKEv2-Routing-basiertes VPN, das VTI auf ASA verwendet: ASA-Code Version 9.8(1) oder höher (Azure muss für routenbasiertes VPN konfiguriert sein.)
- Für ein richtlinienbasiertes IKEv1-VPN, das die Crypto Map auf ASA und FTD verwendet: ASA-Code Version 8.2 oder höher und FTD 6.2.0 oder höher (Azure muss für richtlinienbasiertes VPN konfiguriert sein.)
- Für IKEv2-VPN auf Routenbasis, das Crypto Map auf ASA mit richtlinienbasierten Datenverkehrsauswahl-Optionen verwendet: ASA-Code Version 8.2 oder höher, der mit einer Crypto Map konfiguriert ist (Azure muss für routenbasiertes VPN mit UsePolicyBasedTrafficSelectors konfiguriert sein.)
- Kenntnisse von FMC für FTD-Management und -Konfiguration.
Verwendete Komponenten
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
- FTD von Cisco
- Cisco FMC
- Microsoft Azure
- Cisco ASAv mit ASA 9.18.4.22
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.
Hintergrundinformationen
Konzepte
VPN-Verschlüsselungsdomäne
Der IP-Adressbereich mit IPSec ermöglicht die Teilnahme am VPN-Tunnel. Die Verschlüsselungsdomäne wird mithilfe eines lokalen Datenverkehrs- und Remotedatenverkehrs-Selektors definiert, um anzugeben, welche lokalen und entfernten Subnetzbereiche von IPSec erfasst und verschlüsselt werden.
Es gibt zwei Methoden zur Definition der VPN-Verschlüsselungsdomänen: routenbasierte oder richtlinienbasierte Datenverkehrsauswahl:
Routenbasiert:
Die Verschlüsselungsdomäne ist so festgelegt, dass jeder Datenverkehr zugelassen wird, der in den IPSec-Tunnel eingeht. Die Auswahl für lokalen und Remote-IPSec-Datenverkehr ist auf 0.0.0.0 festgelegt. Dies bedeutet, dass jeder Datenverkehr, der in den IPSec-Tunnel geroutet wird, unabhängig vom Quell-/Ziel-Subnetz verschlüsselt wird.
Cisco Adaptive Security Appliance (ASA) unterstützt routenbasiertes VPN unter Verwendung von Virtual Tunnel Interfaces (VTIs) ab Version 9.8.
Cisco Secure Firewall oder FirePOWER Threat Defense (FTD), verwaltet vom FirePOWER Management Center (FMC), unterstützt routenbasiertes VPN unter Verwendung von VTIs in Version 6.7 und höher.
Richtlinienbasiert:
Die Verschlüsselungsdomäne ist so festgelegt, dass nur bestimmte IP-Bereiche sowohl für die Quelle als auch für das Ziel verschlüsselt werden. Richtlinienbasierte lokale Datenverkehrsauswahl- und Remote-Datenverkehrsauswahl geben an, welcher Datenverkehr über IPSec verschlüsselt werden soll.
ASA unterstützt richtlinienbasiertes VPN mit Crypto Maps ab Version 8.2.
Microsoft Azure unterstützt route-, richtlinienbasierte oder routenbasierte Datenverkehrsauswahl mit simulierten richtlinienbasierten Datenverkehrsselektoren. Azure schränkt derzeit die IKE-Version (Internet Key Exchange) ein, die Sie auf Grundlage der ausgewählten VPN-Methode konfigurieren können. Routenbasiert erfordert IKEv2, richtlinienbasiert IKEv1. Wenn IKEv2 verwendet wird, muss routenbasiert in Azure ausgewählt werden, und ASA muss einen VTI verwenden.
Wenn die ASA aufgrund der Codeversion nur Kryptografiezuordnungen unterstützt, muss Azure für eine routenbasierte Auswahl von richtlinienbasiertem Datenverkehr konfiguriert werden. Dies wird im Azure-Portal über die PowerShell-Skriptbereitstellung erreicht, um eine Option zu implementieren, die Microsoft UsePolicyBasedTrafficSelectors aufruft. Diese Option können Sie verwenden: Verbinden eines VPN-Gateways mit mehreren standortbasierten richtlinienbasierten VPN-Geräten.
Zusammenfassend aus der ASA- und FTD-Konfigurationsperspektive:
- Für ASA, die mit einem VTI konfiguriert wurde, muss Azure für ein routenbasiertes VPN konfiguriert werden.
- Weitere Informationen zur Konfiguration von VTIs für FTD finden Sie hier: Firepower Management Center Configuration Guide, Version 6.7
- Für ASA/FTD, die mit einer Crypto Map konfiguriert wurden, muss Azure für richtlinienbasiertes VPN oder routenbasiert mit UsePolicyBasedTrafficSelectors konfiguriert werden.
Konfigurieren
Führen Sie die Konfigurationsschritte aus. Sie können entweder IKEv1, IKEv2-Routenbasiert mit VTI oder IKEv2-Routenbasiert mit richtlinienbasierten Traffic Selectors (Crypto Map auf ASA) konfigurieren.
IKEv1-Konfiguration auf ASA
Implementieren Sie für ein standortübergreifendes IKEv1-VPN von ASA zu Azure die nächste ASA-Konfiguration. Stellen Sie sicher, dass Sie im Azure-Portal einen richtlinienbasierten Tunnel konfigurieren. Für dieses Beispiel werden auf ASA Crypto Maps verwendet.
Weitere Informationen finden Sie unter Konfigurieren von IKEv1-IPsec-Site-to-Site-Tunneln mit dem ASDM oder der CLI auf der ASAv für vollständige IKEv1-Informationen zur ASA-Konfiguration.
1. Aktivieren Sie IKEv1 auf der externen Schnittstelle.
Cisco-ASA(config)#crypto ikev1 enable outside
2. Erstellen Sie eine IKEv1-Richtlinie, die die Algorithmen/Methoden für Hash, Authentifizierung, Diffie-Hellman-Gruppe, Lebensdauer und Verschlüsselung definiert.
Cisco-ASA(config)#crypto ikev1 policy 1
Cisco-ASA(config-ikev1-policy)#authentication pre-share
Cisco-ASA(config-ikev1-policy)#encryption aes
Cisco-ASA(config-ikev1-policy)#hash sha
Cisco-ASA(config-ikev1-policy)#group 14
Cisco-ASA(config-ikev1-policy)#lifetime 28800
3. Erstellen Sie unter den IPsec-Attributen eine Tunnelgruppe, und konfigurieren Sie die Peer-IP-Adresse und den vorinstallierten Tunnelschlüssel.
Cisco-ASA(config)#tunnel-group 192.168.1.1 type ipsec-l2l
Cisco-ASA(config)#tunnel-group 192.168.1.1 ipsec-attributes
Cisco-ASA(config-tunnel-ipsec)#ikev1 pre-shared-key cisco
4. Erstellen Sie eine Zugriffsliste, die den zu verschlüsselnden und zu tunnelnden Datenverkehr definiert.
In diesem Beispiel stammt der relevante Datenverkehr vom Tunnel, der vom Subnetz 10.2.2.0 an 10.1.1.0 stammt. Er kann mehrere Einträge enthalten, wenn zwischen den Standorten mehrere Subnetze vorhanden sind.
In Version 8.4 und höher können Objekte oder Objektgruppen erstellt werden, die als Container für Netzwerke, Subnetze, Host-IP-Adressen oder mehrere Objekte dienen. Erstellen Sie zwei Objekte mit den lokalen und den Remote-Subnetzen, und verwenden Sie sie sowohl für die Crypto Access Control List (ACL)- als auch für die Network Address Translation (NAT)-Anweisungen.
Cisco-ASA(config)#object network 10.2.2.0_24
Cisco-ASA(config-network-object)#subnet 10.2.2.0 255.255.255.0
Cisco-ASA(config)#object network 10.1.1.0_24
Cisco-ASA(config-network-object)#subnet 10.1.1.0 255.255.255.0
Cisco-ASA(config)#access-list 100 extended permit ip object 10.2.2.0_24 object 10.1.1.0_24
5. Konfigurieren Sie den Transformationssatz (TS), der das Schlüsselwort IKEv1 enthalten muss. Ein identisches TS muss auch am Remote-Ende erstellt werden.
Cisco-ASA(config)#crypto ipsec ikev1 transform-set myset esp-aes esp-sha-hmac
Schritt 6: Konfigurieren Sie die Crypto Map, und wenden Sie sie auf die externe Schnittstelle an, die über folgende Komponenten verfügt:
- TS
- Die Peer-IP-Adresse.
- Die definierte Zugriffsliste, die den relevanten Datenverkehr enthält.
- In der Konfiguration wird die Perfect Forward Secrecy (PFS) nicht festgelegt. VPN-Geräte und IPsec-/IKE-Parameter für Site-to-Site-VPN-Gateway-Verbindungen geben an, dass PFS für IKEv1 in Azure deaktiviert ist.
Bei einer optionalen PFS-Einstellung wird ein neues Paar Diffie-Hellman-Schlüssel erstellt, das zum Schutz der Daten verwendet wird (beide Seiten müssen PFS-fähig sein, bevor Phase 2 gestartet wird). Diese Einstellung kann aktiviert werden, indem der folgende Befehl ausgeführt wird: crypto map outside_map 20 set pfs.
- Die festgelegten IPSec-Lebensdauern für Phase 2 basieren auf den VPN-Geräten und den IPsec-/IKE-Parametern für Site-to-Site-VPN-Gateway-Verbindungen. Weitere Informationen erhalten Sie vom Microsoft Azure-Support.
Cisco-ASA(config)#crypto map outside_map 20 match address 100
Cisco-ASA(config)#crypto map outside_map 20 set peer 192.168.1.1
Cisco-ASA(config)#crypto map outside_map 20 set ikev1 transform-set myset
Cisco-ASA(config)#crypto map outside_map 20 set security-association lifetime seconds 3600
Cisco-ASA(config)#crypto map outside_map 20 set security-association lifetime kilobytes 102400000 Cisco-ASA(config)#crypto map outside_map interface outside
7. Stellen Sie sicher, dass der VPN-Datenverkehr keiner anderen NAT-Regel unterliegt. Erstellen Sie eine NAT-Ausnahmeregelung:
Cisco-ASA(config)#nat (inside,outside) 1 source static 10.2.2.0_24 10.2.2.0_24 destination static 10.1.1.0_24 10.1.1.0_24 no-proxy-arp route-lookup
Cisco-ASA(config)#object-group network 10.x.x.x_SOURCE
Cisco-ASA(config-network-object-group)#network-object 10.4.4.0 255.255.255.0
Cisco-ASA(config-network-object-group)#network-object 10.2.2.0 255.255.255.0
Cisco-ASA(config)#object network 10.x.x.x_DESTINATION
Cisco-ASA(config-network-object-group)#network-object 10.3.3.0 255.255.255.0
Cisco-ASA(config-network-object-group)#network-object 10.1.1.0 255.255.255.0
Cisco-ASA(config)#nat (inside,outside) 1 source static 10.x.x.x_SOURCE 10.x.x.x_SOURCE destination static 10.x.x.x_DESTINATION 10.x.x.x_DESTINATION no-proxy-arp route-lookup
IKEv2 Routenbasiert mit VTI auf ASA-Code 9.8 (1) oder höher
Bei einem Site-to-Site IKEv2 Route Based VPN on ASA-Code verwenden Sie diese Konfiguration. Stellen Sie sicher, dass Azure für routenbasiertes VPN konfiguriert ist, und konfigurieren Sie UsePolicyBasedTrafficSelectors nicht im Azure-Portal. Auf der ASA wird ein VTI konfiguriert.
Referenz-CLI-Buch 3: Konfigurationsleitfaden für die VPN-CLI der Cisco ASA-Serie, 9.8 für umfassende Informationen zur ASA VTI-Konfiguration
1. Aktivieren Sie IKEv2 auf der externen Schnittstelle:
Cisco-ASA(config)#crypto ikev2 enable outside
2. Fügen Sie eine IKEv2 Phase 1-Richtlinie hinzu.
Cisco-ASA(config)#crypto ikev2 policy 1 Cisco-ASA(config-ikev2-policy)#encryption aes-256 Cisco-ASA(config-ikev2-policy)#integrity sha256 Cisco-ASA(config-ikev2-policy)#group 14 Cisco-ASA(config-ikev2-policy)#lifetime seconds 28800
3. Fügen Sie einen IPsec-Vorschlag für IKEv2 Phase 2 hinzu. Geben Sie die Sicherheitsparameter im Konfigurationsmodus crypto IPsec ikev2 ipsec-offer an:
Protokoll-ESP-Verschlüsselung {des | 3de | aes | aes-192 | aes-256 | aes-gcm | aes-gcm-192 | aes-gcm-256 | aes-gmac | aes-gmac-192 | aes-gmac-256 | null}
Protokoll-ESP-Integrität {md5 | SHA-1 | SHA-256 | SHA-384 | SHA-512 | null}
Cisco-ASA(config)#crypto ipsec ikev2 ipsec-proposal SET1
Cisco-ASA(config-ipsec-proposal)#protocol esp encryption aes-256
Cisco-ASA(config-ipsec-proposal)#protocol esp integrity sha-256
4. Fügen Sie ein IPSec-Profil hinzu, das Folgendes angibt:
- Der zuvor konfigurierte IPSec-Vorschlag für ikev2 Phase 2.
- Die IPSec-Lebensdauer für Phase 2 (optional) in Sekunden und/oder Kilobyte.
- Die PFS-Gruppe (optional)
Cisco-ASA(config)#crypto ipsec profile PROFILE1
Cisco-ASA(config-ipsec-profile)#set ikev2 ipsec-proposal SET1
Cisco-ASA(config-ipsec-profile)#set security-association lifetime seconds 27000
Cisco-ASA(config-ipsec-profile)#set security-association lifetime kilobytes unlimited
Cisco-ASA(config-ipsec-profile)#set pfs none
5. Erstellen Sie eine Tunnelgruppe unter den IPsec-Attributen, und konfigurieren Sie die Peer-IP-Adresse sowie den lokalen und Remote-Tunnel-Pre-Shared Key für IKEv2:
Cisco-ASA(config)#tunnel-group 192.168.1.1 type ipsec-l2l
Cisco-ASA(config)#tunnel-group 192.168.1.1 ipsec-attributes
Cisco-ASA(config-tunnel-ipsec)#ikev2 local-authentication pre-shared-key cisco
Cisco-ASA(config-tunnel-ipsec)#ikev2 remote-authentication pre-shared-key cisco
6. Erstellen Sie einen VTI, der Folgendes angibt:
- Eine neue Tunnelschnittstellennummer: interface tunnel [Nummer]
- Ein neuer Name für die Tunnelschnittstelle: nameEIF [Name]
- Eine auf der Tunnelschnittstelle nicht vorhandene IP-Adresse: ip address [IP-Adresse] [Maske]
- Tunnelquellenschnittstelle, bei der das VPN lokal terminiert: tunnel source interface [int-name]
- Die IP-Adresse des Azure-Gateways: tunnel destination [Öffentliche Azure-IP]
- IPSec-IPv4-Modus Tunnelmodus IPsec IPv4
- Das IPSec-Profil für diesen VTI: tunnel protection ipsec-Profil [Profilname]
Cisco-ASA(config)#interface tunnel 100 Cisco-ASA(config-if)#nameif vti Cisco-ASA(config-if)#ip address 169.254.0.1 255.255.255.252 Cisco-ASA(config-if)#tunnel source interface outside Cisco-ASA(config-if)#tunnel destination [Azure Public IP] Cisco-ASA(config-if)#tunnel mode ipsec ipv4 Cisco-ASA(config-if)#tunnel protection ipsec profile PROFILE1
7. Erstellen Sie eine statische Route, um Datenverkehr in den Tunnel zu leiten. Führen Sie den folgenden Befehl aus, um eine statische Route hinzuzufügen:
route if_name dest_ip mask gateway_ip [Entfernung]
dest_ip und mask ist die IP-Adresse für das Zielnetzwerk in der Azure-Cloud, z. B. 10.0.0.0/24. Bei gateway_ip muss es sich um eine beliebige IP-Adresse (vorhanden oder nicht vorhanden) im Tunnelschnittstellen-Subnetz handeln, z. B. 169.254.0.2. Diese gateway_ip dient dazu, Datenverkehr in die Tunnelschnittstelle zu leiten. Die jeweilige Gateway-IP selbst ist jedoch unwichtig.
Cisco-ASA(config)#route vti 10.0.0.0 255.255.255.0 169.254.0.2
IKEv1-Konfiguration auf FTD
Für ein standortübergreifendes IKEv1-VPN von FTD zu Azure müssen Sie das FTD-Gerät zuvor beim FMC registriert haben.
1. Erstellen Sie eine Site-to-Site-Richtlinie. Navigieren Sie zum FMC-Dashboard > Geräte > VPN > Site-to-Site..
2. Erstellen Sie eine neue Richtlinie. Klicken Sie auf das Dropdown-Menü Add VPN (VPN hinzufügen), und wählen Sie Firepower Threat Defense Device (FirePOWER-Schutzgerät).
3. Geben Sie im Fenster Create new VPN Topology (Neue VPN-Topologie erstellen) Ihren Topologienamen an, aktivieren Sie das Kontrollkästchen IKEV1 protocol (IKEV1-Protokoll), und klicken Sie auf die Registerkarte IKE. In diesem Beispiel werden vorinstallierte Schlüssel als Authentifizierungsmethode verwendet. Klicken Sie auf das Dropdown-Menü Authentifizierungstyp, und wählen Sie Pre-shared Manual Key (Vorinstallierter manueller Schlüssel). Geben Sie den manuellen vorinstallierten Schlüssel in die Textfelder Schlüssel und Schlüssel bestätigen ein.
4. Konfigurieren Sie die ISAKMP-Richtlinie oder die Parameter für Phase 1, indem Sie eine neue erstellen. Klicken Sie im gleichen Fenster auf die grüne Schaltfläche +, um eine neue ISAKMP-Richtlinie hinzuzufügen. Geben Sie den Namen der Richtlinie an, und wählen Sie die gewünschte Verschlüsselung, Hash, Diffie-Hellman-Gruppe, Lebensdauer und Authentifizierungsmethode aus, und klicken Sie auf Speichern.
5. Konfigurieren Sie die IPsec-Richtlinie oder die Parameter für Phase 2. Navigieren Sie zur Registerkarte IPsec, und wählen Sie Statisch im Kontrollkästchen Crypto Map Type (Crypto-Zuordnungstyp) aus. Klicken Sie auf das Bleistiftsymbol für die IKEV1-IPsec-Angebote bei der Option "Transformationssätze".
6. Erstellen Sie einen neuen IPsec-Vorschlag. Klicken Sie im Fenster "IKEv1 IPSec-Angebot" auf die grüne Schaltfläche +, um eine neue hinzuzufügen. Geben Sie den Namen der Richtlinie und die gewünschten Parameter für die ESP-Verschlüsselung und die ESP-Hash-Algorithmen an, und klicken Sie auf Speichern.
7. Fügen Sie im Fenster "IKEV1 IPsec-Vorschlag" Ihre neue IPsec-Richtlinie dem Abschnitt Ausgewählte Transformationssätze hinzu und klicken Sie auf OK.
8. Zurück auf der Registerkarte IPSec, konfigurieren Sie die gewünschte Lebensdauer und Größe.
9. Wählen Sie die Verschlüsselungsdomäne/Datenverkehrsauswahl/Geschützte Netzwerke aus. Navigieren Sie zur Registerkarte Endgeräte. Klicken Sie auf Knoten A,green + buttonum einen neuen hinzuzufügen. In diesem Beispiel wird Knoten A als lokale Subnetze des FTD verwendet.
10. Geben Sie im Fenster Endpunkt hinzufügen im Dropdown-Menü Gerät das FTD mit der zu verwendenden physischen Schnittstelle und IP-Adresse an.
11. Um die Auswahl für den lokalen Datenverkehr festzulegen, navigieren Sie zur Option Geschützte Netzwerke, und klicken Sie auf die grüne Schaltfläche +, um ein neues Objekt zu erstellen.
12. Klicken Sie im Fenster Netzwerkobjekte auf die grüne Schaltfläche + neben dem Text Verfügbare Netzwerke, um ein neues lokales Datenverkehrsselektionsobjekt zu erstellen.
13. Geben Sie im Fenster Neues Netzwerkobjekt den Namen des Objekts an, und wählen Sie ihn entsprechend aus. host/network/range/FQDN. Klicken Sie dann auf Speichern.
14. Fügen Sie das Objekt dem Abschnitt Ausgewählte Netzwerke im Fenster Netzwerkobjekte hinzu, und klicken Sie auf OK. Klicken Sie im Fenster Endpunkt hinzufügen auf OK.
15. Definieren Sie Knoten B, der in diesem Beispiel der Azure-Endpunkt ist. Navigieren Sie im Fenster Create New VPN Topology (Neue VPN-Topologie erstellen) zum Abschnitt Node B, und klicken Sie auf die grüne Schaltfläche +, um die Datenverkehrsauswahl für den Remote-Endpunkt hinzuzufügen. Geben Sie Extranet für alle VPN-Peer-Endpunkte an, die nicht vom gleichen FMC wie Knoten A verwaltet werden. Geben Sie den Namen des Geräts (nur lokal bedeutsam) und seine IP-Adresse ein.
16. Erstellen Sie das Remote-Datenverkehrsauswahlobjekt. Navigieren Sie zum Abschnitt Geschützte Netzwerke, und klicken Sie auf die grüne Schaltfläche +, um ein neues Objekt hinzuzufügen.
17. Klicken Sie im Fenster Netzwerkobjekte auf die grüne Schaltfläche + neben dem Text Verfügbare Netzwerke, um ein neues Objekt zu erstellen. Geben Sie im Fenster New Network Object (Neues Netzwerkobjekt) den Namen des Objekts an, und wählen Sie dementsprechend Host/Bereich/Netzwerk/FQDN aus, und klicken Sie dann auf Save (Speichern).
18. Fügen Sie im Fenster Netzwerkobjekte das neue Remoteobjekt dem Abschnitt Ausgewählte Netzwerke hinzu, und klicken Sie auf OK. Klicken Sie im Fenster Endpunkt hinzufügen auf OK.
19. Im Fenster Create New VPN Topology (Neue VPN-Topologie erstellen) können Sie jetzt beide Knoten mit ihren richtigen Datenverkehrsauswahl-/geschützten Netzwerken sehen. Klicken Sie auf Speichern.
20. Klicken Sie auf dem FMC-Dashboard im rechten oberen Bereich auf Deploy (Bereitstellen), wählen Sie das FTD-Gerät aus, und klicken Sie auf Deploy (Bereitstellen).
21. Die VPN-Konfiguration auf der CLI entspricht derjenigen für ASA-Geräte.
IKEv2-Routenbasiert mit richtlinienbasierten Datenverkehrs-Auswahlhilfen
Bei einem Site-to-Site-IKEv2-VPN auf ASA mit Crypto Maps verwenden Sie diese Konfiguration. Stellen Sie sicher, dass Azure für routenbasiertes VPN konfiguriert ist, und UsePolicyBasedTrafficSelectors müssen im Azure-Portal mithilfe von PowerShell konfiguriert werden.
Verbinden eines VPN-Gateways mit mehreren richtlinienbasierten lokalen VPN-Geräten von Microsoft beschreibt die Konfiguration von UsePolicyBasedTrafficSelectors in Verbindung mit dem routenbasierten Azure VPN-Modus. Ohne Abschluss dieses Schrittes kann die ASA mit Crypto Maps die Verbindung aufgrund einer Diskrepanz in den von Azure empfangenen Datenverkehrs-Selektoren nicht herstellen.
Referenz-CLI-Buch 3: Cisco ASA-Serie VPN CLI Configuration Guide, 9.8 für vollständige ASA IKEv2 mit Konfigurationsdaten für die Crypto Map.
1. Aktivieren Sie IKEv2 auf der externen Schnittstelle:
Cisco-ASA(config)#crypto ikev2 enable outside
2. Fügen Sie eine IKEv2 Phase 1-Richtlinie hinzu.
Cisco-ASA(config)#crypto ikev2 policy 1 Cisco-ASA(config-ikev2-policy)#encryption aes-256 Cisco-ASA(config-ikev2-policy)#integrity sha256 Cisco-ASA(config-ikev2-policy)#group 14 Cisco-ASA(config-ikev2-policy)#lifetime seconds 28800
3. Erstellen Sie eine Tunnelgruppe unter den IPsec-Attributen, und konfigurieren Sie die Peer-IP-Adresse sowie den lokalen und Remote-Tunnel-Pre-Shared Key für IKEv2:
Cisco-ASA(config)#tunnel-group 192.168.1.1 type ipsec-l2l
Cisco-ASA(config)#tunnel-group 192.168.1.1 ipsec-attributes
Cisco-ASA(config-tunnel-ipsec)#ikev2 local-authentication pre-shared-key cisco
Cisco-ASA(config-tunnel-ipsec)#ikev2 remote-authentication pre-shared-key cisco
4. Erstellen Sie eine Zugriffsliste, die den zu verschlüsselnden und zu tunnelnden Datenverkehr definiert. In diesem Beispiel ist der Datenverkehr von Interesse der Datenverkehr aus dem Tunnel, der vom Subnetz 10.2.2.0 an 10.1.1.0 stammt. Er kann mehrere Einträge enthalten, wenn zwischen den Standorten mehrere Subnetze vorhanden sind.
In Version 8.4 und höher können Objekte oder Objektgruppen erstellt werden, die als Container für Netzwerke, Subnetze, Host-IP-Adressen oder mehrere Objekte dienen. Erstellen Sie zwei Objekte mit den lokalen und den Remote-Subnetzen, und verwenden Sie sie sowohl für die Crypto ACL- als auch für die NAT-Anweisungen.
Cisco-ASA(config)#object network 10.2.2.0_24
Cisco-ASA(config-network-object)#subnet 10.2.2.0 255.255.255.0
Cisco-ASA(config)#object network 10.1.1.0_24
Cisco-ASA(config-network-object)#subnet 10.1.1.0 255.255.255.0
Cisco-ASA(config)#access-list 100 extended permit ip object 10.2.2.0_24 object 10.1.1.0_24
5. Fügen Sie einen IPsec-Vorschlag für IKEv2 Phase 2 hinzu. Geben Sie die Sicherheitsparameter im Konfigurationsmodus "crypto IPsec ikev2 ipsec-offer" an:
Protokoll-ESP-Verschlüsselung {des | 3de | aes | aes-192 | aes-256 | aes-gcm | aes-gcm-192 | aes-gcm-256 | aes-gmac | aes-gmac-192 | aes-gmac-256 | null}
Protokoll-ESP-Integrität {md5 | SHA-1 | SHA-256 | SHA-384 | SHA-512 | null}
Cisco-ASA(config)#crypto ipsec ikev2 ipsec-proposal SET1
Cisco-ASA(config-ipsec-proposal)#protocol esp encryption aes-256
Cisco-ASA(config-ipsec-proposal)#protocol esp integrity sha-256
6. Konfigurieren Sie eine Crypto Map, und wenden Sie diese auf die externe Schnittstelle an, die folgende Komponenten enthält:
・ Die Peer-IP-Adresse.
・ Die definierte Zugriffsliste, die den relevanten Datenverkehr enthält.
・ Der Vorschlag für IKEv2 Phase 2 IPSec.
・ IPSec-Lebensdauer in Sekunden.
・ Eine optionale PFS-Einstellung (Perfect Forward Secrecy), die ein neues Paar Diffie-Hellman-Schlüssel erstellt, die zum Schutz der Daten verwendet werden (beide Seiten müssen PFS-fähig sein, bevor Phase 2 gestartet wird).
Microsoft hat Informationen veröffentlicht, die mit den von Azure verwendeten IPSec-Lebensdauer- und PFS-Attributen der Phase 2 in Konflikt stehen.
Die aufgeführten Attribute stammen von Routenbasierten VPN IPsec Security Association-Angeboten (IKE Quick Mode SA).
Konflikte verursachende IPSec-Attributinformationen aus Phase 2 von Microsoft sind Beispielkonfiguration: Cisco ASA-Gerät (IKEv2/kein BGP). Weitere Informationen erhalten Sie vom Microsoft Azure-Support.
Cisco-ASA(config)#crypto map outside_map 20 match address 100 Cisco-ASA(config)#crypto map outside_map 20 set peer 192.168.1.1 Cisco-ASA(config)#crypto map outside_map 20 set ikev2 ipsec-proposal myset
Cisco-ASA(config)#crypto map outside_map 20 set security-association lifetime seconds 27000
Cisco-ASA(config)#crypto map outside_map 20 set security-association lifetime kilobytes unlimited Cisco-ASA(config)#crypto map outside_map 20 set pfs none Cisco-ASA(config)#crypto map outside_map interface outside
8. Stellen Sie sicher, dass der VPN-Datenverkehr keiner anderen NAT-Regel unterliegt. Erstellen Sie eine NAT-Ausnahmeregelung:
Cisco-ASA(config)#nat (inside,outside) 1 source static 10.2.2.0_24 10.2.2.0_24 destination static 10.1.1.0_24 10.1.1.0_24 no-proxy-arp route-lookup
Cisco-ASA(config)#object-group network 10.x.x.x_SOURCE
Cisco-ASA(config-network-object-group)#network-object 10.4.4.0 255.255.255.0
Cisco-ASA(config-network-object-group)#network-object 10.2.2.0 255.255.255.0
Cisco-ASA(config)#object network 10.x.x.x_DESTINATION
Cisco-ASA(config-network-object-group)#network-object 10.3.3.0 255.255.255.0
Cisco-ASA(config-network-object-group)#network-object 10.1.1.0 255.255.255.0
Cisco-ASA(config)#nat (inside,outside) 1 source static 10.x.x.x_SOURCE 10.x.x.x_SOURCE destination static 10.x.x.x_DESTINATION 10.x.x.x_DESTINATION no-proxy-arp route-lookup
Überprüfung
Nachdem Sie die Konfiguration auf ASA und Azure-Gateway abgeschlossen haben, initiiert Azure den VPN-Tunnel. Mit den folgenden Befehlen können Sie überprüfen, ob der Tunnel richtig erstellt wurde:
Phase 1
Überprüfen Sie, ob die Phase 1 Security Association (SA) erstellt wurde:
Als Nächstes wird eine IKEv2 SA angezeigt, die von der lokalen externen Schnittstelle IP 192.168.1.2 auf dem UDP-Port 500 zur Remote-Ziel-IP 192.168.2.2 erstellt wurde. Darüber hinaus gibt es eine gültige untergeordnete SA, die für den Fluss des verschlüsselten Datenverkehrs erstellt wurde.
Cisco-ASA# show crypto ikev2 sa
IKEv2 SAs:
Session-id:44615, Status:UP-ACTIVE, IKE count:1, CHILD count:1
Tunnel-id Local Remote Status Role
3208253 192.168.1.2/500 192.168.2.2/500 READY INITIATOR
Encr: AES-CBC, keysize: 256, Hash: SHA256, DH Grp:14, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/142 sec
*-->Child sa: local selector 192.168.0.0/0 - 192.168.0.255/65535
remote selector 192.168.3.0/0 - 192.168.3.255/65535
ESP spi in/out: 0x9b60edc5/0x8e7a2e12
In diesem Beispiel wird IKEv1 SA mit ASA als Initiator für Peer-IP 192.168.2.2 mit einer Restlebensdauer von 86388 Sekunden erstellt:
Cisco-ASA# sh crypto ikev1 sa detail
IKEv1 SAs:
Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1
1 IKE Peer: 192.168.2.2
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
Encrypt : aes Hash : SHA
Auth : preshared Lifetime: 86400
Lifetime Remaining: 86388
Phase 2
Überprüfen Sie, ob die IPSec-Sicherheitszuordnung für Phase 2 mit show crypto ipsec sa peer [peer-ip] erstellt wurde:
Cisco-ASA# show crypto ipsec sa peer 192.168.2.2
peer address: 192.168.2.2
Crypto map tag: outside, seq num: 10, local addr: 192.168.1.2
access-list VPN extended permit ip 192.168.0.0 255.255.255.0 192.168.3.0 255.255.255.0
local ident (addr/mask/prot/port): (192.168.0.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.3.0/255.255.255.0/0/0)
current_peer: 192.168.2.2
#pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
#pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 4, #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
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#send errors: 0, #recv errors: 0
local crypto endpt.: 192.168.1.2/500, remote crypto endpt.: 192.168.2.2/500
path mtu 1500, ipsec overhead 74(44), media mtu 1500
PMTU time remaining (sec): 0, DF policy: copy-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: 8E7A2E12
current inbound spi : 9B60EDC5
inbound esp sas:
spi: 0x9B60EDC5 (2606820805)
SA State: active
transform: esp-aes-256 esp-sha256-hmac no compression
in use settings ={L2L, Tunnel, IKEv2, }
slot: 0, conn_id: 182743040, crypto-map: outside
sa timing: remaining key lifetime (kB/sec): (4193279/28522)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x0000001F
outbound esp sas:
spi: 0x8E7A2E12 (2390371858)
SA State: active
transform: esp-aes-256 esp-sha256-hmac no compression
in use settings ={L2L, Tunnel, IKEv2, }
slot: 0, conn_id: 182743040, crypto-map: outside
sa timing: remaining key lifetime (kB/sec): (3962879/28522)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
Vier Pakete werden fehlerfrei gesendet und vier über IPSec SA empfangen. Eine eingehende SA mit SPI 0x9B60EDC5 und eine ausgehende SA mit SPI 0x8E7A2E12 werden erwartungsgemäß installiert.
Sie können die Datenübertragung über den Tunnel auch durch eine Überprüfung der Einträge vpn-sessiondb l2l überprüfen:
Cisco-ASA#show vpn-sessiondb l2l
Session Type: LAN-to-LAN
Connection : 192.168.2.2
Index : 44615 IP Addr : 192.168.2.2
Protocol : IKEv2 IPsec
Encryption : IKEv2: (1)AES256 IPsec: (1)AES256
Hashing : IKEv2: (1)SHA256 IPsec: (1)SHA256
Bytes Tx : 400 Bytes Rx : 400
Login Time : 18:32:54 UTC Tue Mar 13 2018
Duration : 0h:05m:22s
Bytes Tx: und Bytes Rx: zeigt Zähler für gesendete und empfangene Daten über die IPSec-SA an.
Fehlerbehebung
1. Überprüfen Sie, ob der Datenverkehr für das VPN von der ASA an der internen Schnittstelle empfangen wird, die für das private Azure-Netzwerk bestimmt ist. Zum Testen können Sie einen kontinuierlichen Ping von einem internen Client konfigurieren und eine Paketerfassung auf ASA konfigurieren, um zu überprüfen, ob dieser empfangen wird:
capture [cap-name] interface [if-name] match [protocol] [src-ip] [src-mask] [dest-ip] [dest-mask]
show capture [cap-name]
Cisco-ASA#capture inside interface inside match ip host [local-host] host [remote-host]
Cisco-ASA#show capture inside 2 packets captured 1: 18:50:42.835863 192.168.0.2 > 192.168.3.2: icmp: echo request 2: 18:50:42.839128 192.168.3.2 > 192.168.0.2: icmp: echo reply 2 packets shown
- Wenn Antwortdatenverkehr von Azure erkannt wird, ist das VPN ordnungsgemäß erstellt und sendet/empfängt Datenverkehr.
- Wenn kein Quelldatenverkehr vorhanden ist, überprüfen Sie, ob Ihr Absender die richtige Weiterleitung an die ASA ist.
- Wenn Quelldatenverkehr erkannt wird, aber kein Antwortdatenverkehr von Azure vorhanden ist, fahren Sie mit der Überprüfung der Ursache fort.
2. Überprüfen Sie, ob der über die ASA-interne Schnittstelle empfangene Datenverkehr von der ASA ordnungsgemäß verarbeitet und in das VPN geroutet wird:
So simulieren Sie eine ICMP-Echoanfrage:
packet-tracer input [Name der internen Schnittstelle] icmp [inside-host-ip] 8 0 [azure-host-ip] detail
Weitere Informationen finden Sie in den Richtlinien zur Paketverfolgung, Fehlerbehebung bei Zugriffsproblemen mit Packet-Tracer
Cisco-ASA# packet-tracer input inside icmp 192.168.0.2 8 0 192.168.3.2 detail
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7f6c19afb0a0, priority=13, domain=capture, deny=false
hits=3, user_data=0x7f6c19afb9b0, cs_id=0x0, l3_type=0x0
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0000.0000.0000
input_ifc=inside, output_ifc=any
Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7f6c195971f0, priority=1, domain=permit, deny=false
hits=32, user_data=0x0, cs_id=0x0, l3_type=0x8
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0100.0000.0000
input_ifc=inside, output_ifc=any
Phase: 3
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 192.168.1.1 using egress ifc outside
Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7f6c19250290, priority=0, domain=nat-per-session, deny=true
hits=41, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=any, output_ifc=any
Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7f6c1987c120, priority=0, domain=inspect-ip-options, deny=true
hits=26, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=inside, output_ifc=any
Phase: 6
Type: QOS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7f6c19a60280, priority=70, domain=qos-per-class, deny=false
hits=30, user_data=0x7f6c19a5c030, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=any, output_ifc=any
Phase: 7
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7f6c1983ab50, priority=66, domain=inspect-icmp-error, deny=false
hits=27, user_data=0x7f6c1987afc0, cs_id=0x0, use_real_addr, flags=0x0, protocol=1
src ip/id=0.0.0.0, mask=0.0.0.0, icmp-type=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, icmp-code=0, tag=any, dscp=0x0
input_ifc=inside, output_ifc=any
Phase: 8
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
out id=0x7f6c19afe1a0, priority=70, domain=encrypt, deny=false
hits=2, user_data=0x13134, cs_id=0x7f6c19349670, reverse, flags=0x0, protocol=0
src ip/id=192.168.0.0, mask=255.255.255.0, port=0, tag=any
dst ip/id=192.168.3.0, mask=255.255.255.0, port=0, tag=any, dscp=0x0
input_ifc=any, output_ifc=outside
Phase: 9
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 43, packet dispatched to next module
Module information for forward flow ...
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_inspect_icmp
snp_fp_adjacency
snp_fp_encrypt
snp_fp_fragment
snp_ifc_stat
Module information for reverse flow ...
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow
NAT befreit den Datenverkehr (keine Übersetzung wird wirksam). Vergewissern Sie sich, dass keine NAT-Übersetzung für den VPN-Datenverkehr erfolgt. Überprüfen Sie außerdem, ob die Ausgabeschnittstelle korrekt ist. Dabei muss es sich entweder um die physische Schnittstelle handeln, auf die die Crypto Map angewendet wird, oder um die virtuelle Tunnelschnittstelle.
Stellen Sie sicher, dass keine Zugriffslisten-Drops erkannt werden. Wenn in der VPN-Phase ENCRYPT angezeigt wird: ALLOW, der Tunnel ist bereits gebaut und Sie können sehen, IPSec SA mit encaps installiert.
2.1. Bei VERSCHLÜSSELUNG: ALLOW wird im Paketverfolger angezeigt.
- Überprüfen Sie, ob die IPsec-SA installiert ist, und verschlüsseln Sie den Datenverkehr mithilfe von show crypto ipsec sa.
- Sie können eine Erfassung an der externen Schnittstelle durchführen, um sicherzustellen, dass verschlüsselte Pakete von ASA gesendet und verschlüsselte Antworten von Azure empfangen werden.
2.2. Wenn ENCRYPT:DROP im Packet-Tracer angezeigt wird.
- Der VPN-Tunnel ist noch nicht eingerichtet, wird aber verhandelt. Dies ist ein erwarteter Zustand, wenn Sie den Tunnel zum ersten Mal hochfahren. Führen Sie Debugs aus, um den Tunnelaushandlungsprozess anzuzeigen und festzustellen, wo und ob ein Fehler auftritt.
Vergewissern Sie sich, dass die richtige Version von IKE ausgelöst wird und der gemeinsame Prozess keine relevanten Fehler aufweist:
Cisco-ASA#debug crypto ike-common 255 Cisco-ASA# Mar 13 18:58:14 [IKE COMMON DEBUG]Tunnel Manager dispatching a KEY_ACQUIRE message to IKEv1. Map Tag = outside. Map Sequence Number = 10.
Wenn bei der Initiierung von VPN-Datenverkehr keine ike-common-Debug-Ausgabe erkannt wird, bedeutet dies, dass Datenverkehr verworfen wird, bevor er den Crypto-Prozess erreicht, oder crypto ikev1/ikev2 ist auf dem Gerät nicht aktiviert. Überprüfen Sie die Verschlüsselungskonfiguration und Paketverluste.
Wenn typische Debugs zeigen, dass der Kryptografieprozess ausgelöst wird, debuggen Sie die von IKE konfigurierte Version, um Tunnelaushandlungsmeldungen anzuzeigen und festzustellen, wo der Fehler beim Tunnelaufbau mit Azure auftritt.
IKEv1
Weitere Informationen finden Sie im vollständigen Ikev1-Debugverfahren und der Analyse: ASA IPsec- und IKE-Debugs (IKEv1-Hauptmodus) Troubleshooting TechNote.
Cisco-ASA#debug crypto ikev1 127
Cisco-ASA#debug crypto ipsec 127
IKEv2
Weitere Informationen finden Sie im vollständigen Ikev2-Debugverfahren und in der Analyse: Verwenden Sie ASA IKEv2-Debugs für Site-to-Site-VPN mit PSKs.
Cisco-ASA#debug crypto ikev2 platform 127 Cisco-ASA#debug crypto ikev2 protocol 127 Cisco-ASA#debug crypto ipsec 127
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
5.0 |
24-Jul-2026
|
Aktualisierte Artikelbeschreibung, Bildverknüpfungen, Stilanforderungen und Formatierung. |
3.0 |
09-Sep-2022
|
Prüfung/Neuzertifizierung von Inhalten |
2.0 |
28-Feb-2022
|
Unterstützung für FTD 6.7 wurde als Teil der Firestarter-Anfrage hinzugefügt. |
1.0 |
27-Mar-2019
|
Erstveröffentlichung |
Feedback