Fehlerbehebung bei IPsec-VPN und Failovergruppen

Zur Fehlerbehebung bei Site-to-Site-IPsec-VPN-Verbindungen und Failover-Gruppen können Sie die Protokolle, IPsec-Profile und Verbindungseigenschaften überprüfen.

Überprüfen Sie Protokolle und Konfigurationen

Protokolle

Die Firewall verwendet die folgenden Dateien in /log So verfolgen Sie die IPsec-Ereignisse:

strongswan.log: IPsec VPN-Dienstprotokoll
charon.log: IPsec VPN Charon (IKE-Daemon)-Protokoll
strongswan-monitor.log: IPsec-Daemon-Überwachungsprotokoll
dgd.log: Dead Gateway Detection (DGD) und VPN-Failover-Protokoll

Diese Seite hilft bei der Behebung von Fehlern, die mit dieser Fehlermeldung in Zusammenhang stehen: IPsec connection could not be established

Öffnen Sie die folgende Protokolldatei: /log/strongswan.log

IPsec-Verbindungen

Informationen zur Fehlerbehebung bei einer Failover-Gruppe finden Sie in den zusätzlichen Eigenschaften der IPsec-Verbindungen der Gruppe und ihrer IPsec-Profile.

Um die zusätzlichen Eigenschaften von IPsec-Verbindungen anzuzeigen, gehen Sie zu Site-to-Site-VPN > IPsec.
Unter IPsec-Verbindungenauf Zusätzliche Eigenschaften anzeigen über der Namensspalte und wählen Sie die Eigenschaften aus, die Sie in der IPsec-Verbindungsliste sehen möchten.

IPsec-Profile

Um die zusätzlichen Eigenschaften des in einer Verbindung verwendeten IPsec-Profils anzuzeigen, gehen Sie zu Profile > IPsec-Profile.
Klicken Zusätzliche Eigenschaften anzeigen über der Namensspalte und wählen Sie die zusätzlichen Eigenschaften aus, die Sie sehen möchten.

Problembehandlung bei IPsec-Verbindungen und Failovergruppen

Sehen Sie sich die folgenden Probleme und deren Lösung an.

Remote-Peer lehnt Phase-1-Vorschlag ab

Das strongSwan-Protokoll zeigt die folgende Fehlermeldung: Remote peer is refusing our Phase 1 proposals

Ursache: Nicht übereinstimmende Vorschläge der Phase 1 zwischen den beiden Peers.

Stellen Sie sicher, dass die VPN-Konfiguration auf beiden Firewalls für Folgendes die gleichen Einstellungen aufweist:
- Phase 1: Verschlüsselung, Authentifizierung und DH-Gruppe.
- Gateway-Adresse: Die Peer-Gateway-Adresse, die Sie in der lokalen Firewall eingegeben haben, stimmt mit der Abhörschnittstelle in der Remote-Konfiguration überein.
- Andere Einstellungen: Lokale und Remote-IDs.
Wenn alle Einstellungen übereinstimmen, muss der Remote-Firewall-Administrator die Konfiguration auf seiner Seite überprüfen, da die Remote-Firewall die Verbindung abgelehnt hat.

Remote-Peer authentifiziert sich nicht

Das strongSwan-Protokoll zeigt die folgenden Meldungen:

We have successfully exchanged Encryption and Authentication algorithms, we are now negotiating the Phase 1 SA encryption (hashing) key

Remote peer reports we failed to authenticate

Ursache: Die Remote-Firewall konnte die lokale Anfrage nicht authentifizieren, da die ID-Typen nicht übereinstimmen. Beispiel: Sie haben die IPsec-Verbindung der lokalen Firewall so konfiguriert, dass die lokale ID auf die IP-Adresse eingestellt ist, die Remote-Firewall ist jedoch so konfiguriert, dass sie einen DNS-Namen erwartet.

Überprüfen Sie die Protokolle der Remote-Firewall, um sicherzustellen, dass der Fehler durch die Nichtübereinstimmung der ID-Typen verursacht wurde.
Aktualisieren Sie die lokalen und Remote-ID-Typen und IDs mit übereinstimmenden Werten auf beiden Firewalls.

Entschlüsselungsfehler

In den Protokollen werden die folgenden Fehlermeldungen angezeigt:

Error on decryption of the exchange

Information field of the IKE request is malformed or not readable

Ursache: Die Ursache liegt wahrscheinlich in einer Nichtübereinstimmung des Preshared Keys zwischen den beiden Firewalls.

In seltenen Fällen kann es vorkommen, dass der ISP oder ein vorgelagertes Gerät, beispielsweise ein Router oder eine andere Firewall, das Paket beschädigt.

Stellen Sie sicher, dass der vorinstallierte Schlüssel in der VPN-Konfiguration auf beiden Firewalls übereinstimmt.
Wenn der vorinstallierte Schlüssel übereinstimmt, überprüfen Sie beim ISP oder auf den Upstream-Geräten, ob sie das Paket beschädigt haben.
Stellen Sie sicher, dass die MTU- und MSS-Einstellungen der WAN-Schnittstelle mit den vom ISP angegebenen Werten übereinstimmen.

Remote-Peer meldet keine Übereinstimmung mit den akzeptablen Vorschlägen

Das strongSwan-Protokoll zeigt die folgenden Meldungen:

Phase 1 is up

Initiating establishment of Phase 2 SA

Remote peer reports no match on the acceptable proposals

Die Remote-Firewall zeigt die folgende Fehlermeldung an: NO_PROPOSAL_CHOSEN

Ursache: Nicht übereinstimmender Vorschlag für Phase 2.

Stellen Sie sicher, dass die Phase-2-Einstellungen für Verschlüsselungs- und Authentifizierungsalgorithmen und DH-Gruppe auf beiden Firewalls übereinstimmen.
Wenn sie übereinstimmen, suchen Sie in den Protokollen der Remote-Firewall nach der Ursache.

Ungültige ID

Das strongSwan-Protokoll zeigt die folgenden Meldungen:

Phase 1 is up

Remote peer reports INVALID_ID_INFORMATION

Ursache:

Melden Sie sich bei der CLI an und klicken Sie auf 5 für Geräteverwaltung und klicken Sie dann auf 3 für Erweiterte Shell.
Geben Sie den folgenden Befehl ein: ipsec statusall

Sie können sehen, dass die SA (Security Association) nicht angezeigt wird. Siehe folgende Abbildung:
Geben Sie den folgenden Befehl ein: ip xfrm policy

Die Ausgabe zeigt die SAs der Phase 2 nicht an. Während der Aushandlung der Phase 2 stimmten die in den Firewalls angegebenen lokalen und Remote-Subnetze nicht überein. Beispielsweise erwartet die Remote-Firewall 192.168.0.0/24, die lokale Firewall versucht jedoch, über 192.168.1.0/24 auszuhandeln.
Stellen Sie sicher, dass die konfigurierten Subnetze auf beiden Firewalls übereinstimmen.
Wenn die Subnetze übereinstimmen, muss der Remote-Administrator die Protokolle der Remote-Firewall überprüfen, wenn der Fehler weiterhin besteht.

IPsec-Verbindungen werden hergestellt, der Datenverkehr wird jedoch später unterbrochen

Zwischen der Sophos Firewall und einer Firewall eines Drittanbieters werden eine oder mehrere IPsec-Verbindungen hergestellt. Nach einiger Zeit wird der Datenverkehr unterbrochen.

Melden Sie sich bei der CLI-Konsole an. Siehe Zugriff auf die Befehlszeilenkonsole.
Typ 5 zu wählen Device Managementund geben Sie dann 3 zu wählen Advanced Shell.
Geben Sie den folgenden Befehl ein: ipsec statusall

Die Ausgabe zeigt, dass IPSec-SAs eingerichtet wurden.
Optional: Geben Sie für routenbasiertes VPN den folgenden Befehl ein: ip xfrm state

Die Ausgabe zeigt, dass die Transformationssätze für das VPN vorhanden sind, d. h., die SAs stimmen überein.
Überprüfen Sie eine oder mehrere der folgenden möglichen Ursachen und Lösungen:

Ursache: Die Remote-Firewall von Drittanbietern verwendet eine verkehrsbasierte Neuverschlüsselung.

Auflösung: Die Sophos Firewall unterstützt nur zeitbasierte Neuverschlüsselung. Wenn Sie auf der Remote-Firewall eines Drittanbieters eine verkehrsbasierte Neuverschlüsselung konfiguriert haben, ändern Sie diese in zeitbasierte Neuverschlüsselung.

Ursache: Zwei oder mehr IPsec-Verbindungen haben dieselben lokalen und Remote-Subnetze (einschließlich Any-Any-Konfigurationen), befinden sich jedoch nicht in derselben Failover-Gruppe.

Auflösung: Mehrere IPsec-Verbindungen mit denselben lokalen und Remote-Subnetzen (einschließlich Any-Any-Konfigurationen) funktionieren nur, wenn sich die IPsec-Verbindungen in derselben Failover-Gruppe befinden. Um dieses Problem zu beheben, gehen Sie wie folgt vor:
1. Gehe zu Site-to-Site-VPN > IPsec.
2. Unter IPsec-Verbindungenauf Zusätzliche Eigenschaften anzeigen.
3. Wählen Lokales Subnetz Und Remote-Subnetz.
4. Klicken OK.
  
  Der Lokales Subnetz Und Remote-Subnetz werden angezeigt. Überprüfen Sie die IPsec-Verbindungen mit ähnlichen lokalen und Remote-Subnetzkonfigurationen.
  
  Beispiel:
5. Konfigurieren Sie die IPsec-Verbindungen mit ähnlichen lokalen und Remote-Subnetzkonfigurationen in derselben Failover-Gruppe. Siehe Hinzufügen einer Failovergruppe.
6. Wenn Sie sie nicht in derselben Failover-Gruppe konfigurieren möchten, müssen Sie die lokalen und Remote-Subnetzkonfigurationen dieser IPsec-Verbindungen ändern und sicherstellen, dass sie nicht ähnlich sind.
Ursache: Für routenbasiertes VPN werden zwei oder mehr XFRM-Schnittstellen mit einer IP-Adresse konfiguriert, die zur selben Netzwerkadresse gehört oder überlappende Subnetze aufweist.

Auflösung: Jede XFRM-Schnittstelle muss eine eindeutige Netzwerkadresse haben und darf keine überlappenden Subnetze aufweisen.

Wenn zum Beispiel xfrm1 ist konfiguriert mit 192.168.0.1/24 Und xfrm2 ist konfiguriert mit 192.168.0.6/24, sie befinden sich in derselben Netzwerkadresse, sodass ein Routing-Problem auftritt. Ein weiteres Beispiel ist, wenn xfrm1 ist konfiguriert mit 192.168.0.1/16 Und xfrm2 ist konfiguriert mit 192.168.0.6/24, die Subnetze überlappen sich, sodass ein Routing-Problem auftritt.

Um dieses Problem zu beheben, gehen Sie zu Netzwerk > Schnittstellen und ändern Sie die IP-Adresskonfiguration der XFRM-Schnittstellen, die sich im selben Netzwerk befinden oder überlappende Subnetze haben. Siehe Bearbeiten der XFRM-Schnittstelle.

Ursache: Bei richtlinienbasiertem VPN wird das Leerlauf-Timeout auf der Remote-Firewall festgelegt.

Auflösung: Deaktivieren Sie das Leerlauf-Timeout der Remote-Firewall.

Ursache: Kollisionen beim Schlüsselaustausch.

Auflösung: Um Kollisionen beim Schlüsselaustausch zu vermeiden, gehen Sie wie folgt vor:
1. Stellen Sie die Schlüssellebensdauerwerte des Initiators für Phase 1 und Phase 2 niedriger ein als die des Antwortenden.
2. Stellen Sie die Schlüssellebensdauer der Phase 2 in beiden Firewalls niedriger ein als den Wert der Phase 1.
  
  Beispiel:
  
  Schlüssellebensdauer Firewall 1 Firewall 2
  
  Phase 1 12600 Sekunden 10800 Sekunden
  
  Phase 2 5400 Sekunden 3600 Sekunden

Schlüssellebensdauer	Firewall 1	Firewall 2
Phase 1	12600 Sekunden	10800 Sekunden
Phase 2	5400 Sekunden	3600 Sekunden

Die IPsec-Verbindung wird getrennt, da die zugehörige Schnittstelle ausgeschaltet ist

Wenn Ihre Site-to-Site-IPsec-Verbindung getrennt ist, überprüfen Sie, ob Sie die zugehörige Schnittstelle ausgeschaltet haben.

Wenn Sie die zugehörige Schnittstelle ausgeschaltet haben:

Site-to-Site-IPsec-Verbindungsinitiatoren trennen die Verbindung sofort.
Site-to-Site-IPsec-Verbindungs-Responder und Remote-Access-Verbindungen trennen die Verbindung, wenn Inaktivität oder ein Dead Peer Detection (DPD)-Timeout auftritt.