Zur Startseite gehen
0,00 €*

Permalink zur Seite

Verwenden Sie beim Verweisen auf diese Seite stets den folgenden Permalink. Er bleibt in zukünftigen Hilfeversionen unverändert.

https://docs.sophos.com/nsg/sophos-firewall/21.5/Help/en-us/webhelp/onlinehelp/index.html?contextId=site-to-site-VPN-troubleshooting-IPsec

Fehlerbehebung bei IPsec-VPN- und Failover-Gruppen

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

Protokolle und Konfigurationen prüfen

Protokolle

Die Firewall verwendet die folgenden Dateien in /log um die IPsec-Ereignisse zu verfolgen:

  • strongswan.log: IPsec-VPN-Dienstprotokoll
  • charon.log: IPsec VPN charon (IKE-Daemon)-Protokoll
  • strongswan-monitor.log: IPsec-Daemon-Überwachungsprotokoll
  • dgd.logProtokoll für die Erkennung ausgefallener Gateways (DGD) und VPN-Failover

Diese Seite hilft bei der Fehlerbehebung im Zusammenhang mit dieser Fehlermeldung: IPsec connection could not be established

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

IPsec-Verbindungen

Zur Fehlerbehebung bei einer Failovergruppe sollten Sie die zusätzlichen Eigenschaften der IPsec-Verbindungen der Gruppe und deren IPsec-Profile überprüfen.

  1. Um die zusätzlichen Eigenschaften von IPsec-Verbindungen anzuzeigen, gehen Sie zu Site-to-Site-VPN > IPsec.

  2. Unter IPsec-Verbindungen, klicken Weitere Eigenschaften anzeigen Wählen Sie oberhalb der Namensspalte die Eigenschaften aus, die in der IPsec-Verbindungsliste angezeigt werden sollen.

    IPsec connection's additional properties.

IPsec-Profile

  1. Um die zusätzlichen Eigenschaften des in einer Verbindung verwendeten IPsec-Profils anzuzeigen, gehen Sie zu Profile > IPsec-Profile.

  2. Klicken Weitere Eigenschaften anzeigen Wählen Sie oberhalb der Namensspalte die zusätzlichen Eigenschaften aus, die Sie anzeigen möchten.

    IPsec profile's additional properties.

Fehlerbehebung bei IPsec-Verbindungen und Failovergruppen

Siehe die folgenden Probleme und deren Lösung.

Remote-Peer lehnt Phase-1-Vorschlag ab

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

Ursache: Nicht übereinstimmende Phase-1-Vorschläge der beiden Partner.

  1. Stellen Sie sicher, dass die VPN-Konfiguration auf beiden Firewalls die gleichen Einstellungen für Folgendes aufweist:

    • Phase 1: Verschlüsselung, Authentifizierung und DH-Gruppe.
    • Gateway-Adresse: Die Peer-Gateway-Adresse, die Sie auf der lokalen Firewall eingegeben haben, entspricht der Listening-Schnittstelle in der Remote-Konfiguration.
    • Weitere Einstellungen: Lokale und Remote-IDs.

  2. Wenn alle Einstellungen übereinstimmen, muss der Remote-Firewall-Administrator die Konfiguration auf seiner Seite überprüfen, da die Remote-Firewall die Verbindung verweigert hat.

Der Remote-Peer authentifiziert sich nicht.

Das strongSwan-Protokoll zeigt folgende Meldungen an:

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 mit der lokalen ID „IP-Adresse“ konfiguriert, die Remote-Firewall erwartet jedoch einen DNS-Namen.

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

Entschlüsselungsfehler

Die Protokolle zeigen folgende Fehlermeldungen:

Error on decryption of the exchange

Information field of the IKE request is malformed or not readable

Ursache: Die Ursache dürfte eine Diskrepanz zwischen den vorab vereinbarten Schlüsseln der beiden Firewalls sein.

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

  1. Stellen Sie sicher, dass der vorab geteilte Schlüssel in der VPN-Konfiguration auf beiden Firewalls übereinstimmt.
  2. Wenn der vorab geteilte Schlüssel übereinstimmt, überprüfen Sie beim Internetdienstanbieter oder bei den vorgelagerten Geräten, ob das Paket beschädigt wurde.
  3. Stellen Sie sicher, dass die MTU- und MSS-Einstellungen der WAN-Schnittstelle mit den vom ISP angegebenen Werten übereinstimmen.

Der entfernte Peer meldet, dass keine Übereinstimmung mit den akzeptablen Vorschlägen gefunden wurde.

Das strongSwan-Protokoll zeigt folgende Meldungen an:

Phase 1 is up

Initiating establishment of Phase 2 SA

Remote peer reports no match on the acceptable proposals

Die Remote-Firewall zeigt folgende Fehlermeldung an: NO_PROPOSAL_CHOSEN

Ursache: Nicht übereinstimmender Phase-2-Vorschlag.

  1. Stellen Sie sicher, dass die Phase-2-Einstellungen für Verschlüsselungs- und Authentifizierungsalgorithmen sowie die DH-Gruppe auf beiden Firewalls übereinstimmen.
  2. Wenn sie übereinstimmen, überprüfen Sie die Protokolle der Remote-Firewall auf die Ursache.

Ungültige ID

Das strongSwan-Protokoll zeigt folgende Meldungen an:

Phase 1 is up

Remote peer reports INVALID_ID_INFORMATION

Ursache:

  1. Melden Sie sich bei der CLI an und klicken Sie 5 für Geräteverwaltung und dann klicken 3 für Erweiterte Shell.

  2. Geben Sie folgenden Befehl ein: ipsec statusall

    Sie können sehen, dass die SA (Security Association) nicht angezeigt wird. Siehe folgendes Bild:

    Security association error.

  3. Geben Sie folgenden Befehl ein: ip xfrm policy

    Die Ausgabe zeigt die Phase-2-SAs nicht an. Während der Phase-2-Aushandlung stimmten die auf den Firewalls angegebenen lokalen und Remote-Subnetze nicht überein. Beispielsweise erwartet die Remote-Firewall das Subnetz 192.168.0.0/24, die lokale Firewall versucht jedoch, das Subnetz 192.168.1.0/24 auszuhandeln.

  4. Stellen Sie sicher, dass die konfigurierten Subnetze auf beiden Firewalls übereinstimmen.

  5. Wenn die Subnetze übereinstimmen, muss der Remote-Administrator die Protokolle der Remote-Firewall überprüfen, falls der Fehler weiterhin besteht.

IPsec-Verbindungen werden hergestellt, aber der Datenverkehr stoppt später

Zwischen der Sophos Firewall und einer Firewall eines Drittanbieters werden eine oder mehrere IPsec-Verbindungen hergestellt. Der Datenverkehr stoppt nach einiger Zeit.

  1. Melden Sie sich an der CLI-Konsole an. Siehe Zugriff auf die Befehlszeilenkonsole.
  2. Typ 5 zu wählen Device Managementdann tippen 3 zu wählen Advanced Shell.

  3. Geben Sie folgenden Befehl ein: ipsec statusall

    Die Ausgabe zeigt, dass IPSec-SAs eingerichtet wurden.

  4. Optional: Für routenbasierte VPNs geben Sie folgenden Befehl ein: ip xfrm state

    Die Ausgabe zeigt, dass die Transformationssätze für das VPN existieren, d. h. die SAs stimmen überein.

  5. Markieren Sie eine oder mehrere der folgenden möglichen Ursachen und Lösungen:

    Ursache: Die Remote-Firewall eines Drittanbieters verwendet verkehrsbasierte Neuschlüsselung.

    Auflösung: Die Sophos Firewall unterstützt ausschließlich zeitbasierte Schlüsselerneuerung. Falls Sie auf der Remote-Firewall eines Drittanbieters eine verkehrsbasierte Schlüsselerneuerung konfiguriert haben, ändern Sie diese bitte in eine zeitbasierte Schlüsselerneuerung.

    Ursache: Zwei oder mehr IPsec-Verbindungen haben die gleichen lokalen und entfernten Subnetze (einschließlich Any-Any-Konfigurationen), befinden sich aber nicht in der gleichen Failover-Gruppe.

    Auflösung: Mehrere IPsec-Verbindungen mit demselben lokalen und entfernten Subnetz (einschließlich Any-Any-Konfigurationen) funktionieren nur, wenn sich die IPsec-Verbindungen in derselben Failover-Gruppe befinden. Gehen Sie wie folgt vor, um dieses Problem zu beheben:

    1. Gehe zu Site-to-Site-VPN > IPsec.
    2. Unter IPsec-Verbindungen, klicken Weitere Eigenschaften anzeigen.
    3. Wählen Lokales Subnetz Und Remote-Subnetz.

    4. Klicken OK.

      Der Lokales Subnetz Und Remote-Subnetz Es werden Spalten angezeigt. Überprüfen Sie die IPsec-Verbindungen mit ähnlichen lokalen und Remote-Subnetzkonfigurationen.

      Beispiel:

      Site-to-site IPsec local and remote subnets.

    5. Konfigurieren Sie die IPsec-Verbindungen mit ähnlichen lokalen und Remote-Subnetzkonfigurationen in derselben Failovergruppe. Siehe Fügen Sie eine Failovergruppe hinzu..

    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: Bei routenbasierten VPNs werden zwei oder mehr XFRM-Schnittstellen mit einer IP-Adresse konfiguriert, die entweder zur selben Netzwerkadresse gehört oder sich in überlappenden Subnetzen befindet.

    Auflösung: Jede XFRM-Schnittstelle muss sich in einer eindeutigen Netzwerkadresse befinden und darf keine sich überschneidenden Subnetze aufweisen.

    Wenn xfrm1 ist konfiguriert mit 192.168.0.1/24 Und xfrm2 ist konfiguriert mit 192.168.0.6/24Sie befinden sich im selben Netzwerkadressenbereich, daher tritt ein Routing-Problem auf. Ein weiteres Beispiel ist, wenn xfrm1 ist konfiguriert mit 192.168.0.1/16 Und xfrm2 ist konfiguriert mit 192.168.0.6/24Da sich die Subnetze überschneiden, entsteht ein Routing-Problem.

    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 aufweisen. Siehe Bearbeiten Sie die xfrm-Schnittstelle.

    Ursache: Bei richtlinienbasierten VPNs wird das Leerlauf-Timeout auf der Remote-Firewall festgelegt.

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

    Ursache: Schlüsselaustauschkonflikte.

    Auflösung: Um Schlüsselaustauschkonflikte zu vermeiden, gehen Sie wie folgt vor:

    1. Setzen Sie die Lebensdauerwerte für Phase 1 und Phase 2 des Initiators niedriger als die des Responders.

    2. Die Lebensdauer des Phase-2-Schlüssels sollte in beiden Firewalls niedriger sein als der Wert für Phase 1.

      Beispiel:

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

Die IPsec-Verbindung wurde getrennt, da die zugehörige Schnittstelle deaktiviert ist.

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

Wenn Sie die zugehörige Schnittstelle deaktiviert haben:

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

Hilfe benötigt?

Die Anleitung passt nicht zu Ihrer Situation oder funktioniert nicht wie erwartet? Wir stehen Ihnen gern zur Seite, damit Ihre Konfiguration reibungslos funktioniert. Unser zertifiziertes Support-Team hilft Ihnen schnell weiter:

Support-Ticket eröffnen