Sophos Firewall Site-to-Site IPsec VPN einrichten

Ein Site-to-Site IPsec VPN verbindet zwei Standorte oder eine Sophos Firewall mit einer Drittanbieter-Firewall über einen verschlüsselten Tunnel. In der Praxis scheitert ein solcher Tunnel selten an einem einzelnen Haken in der Oberfläche. Häufiger sind unklare Netze, unterschiedliche IPsec-Profile, fehlende Firewall-Regeln, NAT-Sonderfälle oder ein Rückweg, der auf einer Seite vergessen wurde.

Der Artikel erklärt den sauberen Aufbau eines Site-to-Site-IPsec-Tunnels auf der Sophos Firewall. Der Fokus liegt auf Planung, Umsetzung und Abnahmetest. Wenn ein bestehender Tunnel bereits grün ist, aber kein Traffic fliesst, ist zusätzlich Sophos Firewall IPsec VPN Troubleshooting der bessere Anschlussartikel.

Wann dieser Artikel passt

Der Artikel passt für klassische Standortverbindungen, zum Beispiel:

• Hauptstandort zu Filiale
• Sophos Firewall zu Sophos Firewall
• Sophos Firewall zu Drittanbieter-Firewall
• Sophos Firewall zu Cloud-Gateway, wenn kein spezieller Cloud-Assistent genutzt wird
• Migration von einfachen alten policy-based Tunneln auf eine dokumentierte aktuelle Konfiguration

Für Microsoft Azure oder AWS gibt es zusätzlich eigene Artikel mit den anbieterspezifischen Stolperfallen: Sophos Firewall mit Azure VPN Gateway verbinden und Sophos Firewall mit AWS Site-to-Site VPN verbinden.

Nicht gemeint ist Remote Access für einzelne Benutzer. Dafür passen die Artikel Sophos Connect auf Sophos Firewall konfigurieren, Sophos Connect oder SSL VPN: Welche Remote-Access-Lösung passt? und Legacy Remote Access IPsec vor SFOS 22 MR1 migrieren.

Policy-based oder route-based IPsec

Vor der Konfiguration muss entschieden werden, ob der Tunnel policy-based oder route-based aufgebaut wird. In aktuellen SFOS-Versionen sind diese Begriffe deutlicher getrennt als in älteren Anleitungen, die teilweise noch von Site-to-Site oder Tunnel Interface sprechen.

• Policy-based IPsec: passt für einfache Standortverbindungen mit klaren lokalen und entfernten Netzen. Gesteuert wird primär über lokale und entfernte Subnetze in der IPsec-Verbindung sowie über Firewall-Regeln. Sophos erstellt dabei einzelne Phase-2-Tunnel für die Kombinationen aus lokalen und entfernten Subnetzen.
• Route-based IPsec mit Traffic Selectors: nutzt ebenfalls lokale und entfernte Subnetze, erstellt aber ein eigenes XFRM-Interface für die Verbindung. Das erleichtert Debugging und trennt den Tunnel besser von anderen IPsec-Verbindungen.
• Route-based IPsec Any-to-Any: ist die flexibelste Variante für wachsende Netze, SD-WAN, dynamisches Routing und Dual-Stack-Designs. Welche Pakete in den Tunnel gehen, entscheiden dann Routen und Firewall-Regeln, nicht mehr die Subnetze in der IPsec-Verbindung.

Für kleine, stabile Verbindungen ist policy-based IPsec oft am schnellsten verständlich. Sophos empfiehlt für neue und wachsende Designs aber häufig route-based VPN, weil XFRM-Interfaces, Routen und MTU-Analyse sauberer handhabbar sind. Ein weiterer Betriebsvorteil: Bei Any-to-Any-Designs lassen sich Netze eher über Routing und Regeln erweitern, während Änderungen an Subnetzen oder Traffic Selectors bestehende Verbindungen trennen können. Wichtig ist: Die beiden Enden dürfen nicht gemischt werden. Ein Ende policy-based und das andere Ende route-based ist kein sauberes Tunnel-Design.

Voraussetzungen

Vor dem Einrichten sollten diese Informationen dokumentiert sein:

• Lokales Gateway: WAN-IP oder FQDN der lokalen Sophos Firewall.
• Remote Gateway: öffentliche IP oder FQDN der Gegenstelle.
• Gateway type: Zentrale meistens Respond only, Filiale meistens Initiate the connection.
• IP version: IPv4, IPv6 oder Dual. Dual ist nur für route-based Tunnel-Interfaces mit Any-to-Any als lokale und entfernte Subnetze verfügbar. Bei Dual müssen IPv4- und IPv6-Firewall-Regeln separat geplant werden.
• Lokale Netze: zum Beispiel 172.16.10.0/24 und 172.16.20.0/24.
• Remote Netze: zum Beispiel 10.20.30.0/24.
• VPN-Typ: policy-based oder route-based. Der Connection type Host-to-host existiert ebenfalls, ist aber nicht der Fokus dieser Standortanleitung.
• Listening interface: WAN-Interface der lokalen Firewall. Ein Bridge-Interface kann dafür nicht verwendet werden.
• IKE-Version: bevorzugt IKEv2, falls die Gegenstelle es unterstützt.
• Authentifizierung: Preshared Key oder Zertifikat.
• Local ID und Remote ID: besonders wichtig bei FQDN, dynamischen Gegenstellen, NAT-T oder Wildcard-Gateway.
• IPsec-Profil: Encryption, Authentication, DH Group, PFS und Key Lifetime.
• Firewall-Regeln: erlaubte Quellen, Ziele und Dienste.
• NAT: kein NAT, SNAT/DNAT wegen überlappenden Netzen oder Provideranforderung.
• Betrieb: Owner, Wartungsfenster, Testplan, Monitoring und Rückfallweg.

⚠️ Site-to-Site VPN sollte nicht ohne dokumentierten Rückweg umgesetzt werden. Wenn die lokale Firewall Traffic in den Tunnel sendet, die Gegenstelle aber keine Route zurück kennt oder NAT anders erwartet, sieht der Tunnel oft gesund aus, obwohl Anwendungen nicht funktionieren.

Vor der Konfiguration planen

Netze eindeutig halten

Lokale und entfernte Netze dürfen sich nicht ungewollt überschneiden. Besonders problematisch sind häufige Standardnetze wie 192.168.0.0/24, 192.168.1.0/24 oder mehrfach verwendete Filialnetze. Wenn sich Netze überschneiden, braucht es ein bewusstes NAT-Design. Einfach denselben Adressbereich auf beiden Seiten zu verwenden und später “irgendwie” zu übersetzen, erzeugt schwer wartbare Tunnel.

Für neue Standorte lohnt sich deshalb ein sauberes IP-Adresskonzept. Wenn VLANs oder Zonen noch nicht sauber modelliert sind, hilft Sophos Firewall Zonen und Interfaces konfigurieren.

IPsec-Profil abstimmen

Beide Seiten müssen bei Phase 1 und Phase 2 kompatible Parameter verwenden. Dazu gehören Verschlüsselung, Authentifizierung, DH-Gruppe, PFS und Lebensdauer. Bei Verbindungen zu Drittanbieter-Firewalls ist es oft am einfachsten, zuerst ein gemeinsames Profil schriftlich festzuhalten und danach beide Seiten zu konfigurieren.

Bei IKEv2 kann Sophos eindeutige Preshared Keys pro Local-/Remote-ID-Kombination verwenden. Bei IKEv1 ist dieses Verhalten eingeschränkter, weil pro Gateway-Kombination nur ein PSK greift. In Umgebungen mit mehreren Tunneln zur gleichen Gegenstelle sollte deshalb IKEv2 mit sauberen IDs bevorzugt werden.

NAT Traversal ist auf der Sophos Firewall immer aktiv. Wenn eine Seite hinter einem Router oder Provider-NAT steht, werden Local ID und Remote ID dadurch noch wichtiger, weil die öffentliche Gateway-Adresse nicht mehr allein zur sauberen Peer-Erkennung reicht. DNS-, IP- oder E-Mail-IDs müssen dabei nicht öffentlich auflösbar sein; sie müssen auf beiden Seiten im passenden Format übereinstimmen.

Wenn Zertifikate verwendet werden, müssen die Zertifikatsformate und die Rollen beider Seiten genau zusammenpassen. Sophos unterstützt für IPsec-Verbindungen keine ECDSA-Zertifikate; für solche Tunnel sollten RSA-Zertifikate geplant werden. Eine öffentliche CA sollte nicht pauschal als Remote CA Certificate verwendet werden, weil dadurch zu viel Vertrauen in fremde Zertifikate entsteht.

Wenn ein Tunnel nicht hochkommt, sind NO_PROPOSAL_CHOSEN, ID-Fehler oder Authentifizierungsfehler typische Hinweise. Die strukturierte Analyse steht in Sophos Firewall IPsec VPN Troubleshooting.

Firewall-Regeln nicht vergessen

Ein IPsec-Tunnel erlaubt noch keinen produktiven Zugriff. Traffic durch den Tunnel braucht weiterhin passende Firewall-Regeln. Bei policy-based Verbindungen sind das meistens Regeln zwischen LAN und VPN oder zwischen eigenen Zonen. Bei route-based Designs gehört das XFRM-Interface zur VPN-Zone; Routen und Firewall-Regeln entscheiden danach, welcher Traffic wirklich durch den Tunnel darf.

Für die Einführung sollte Log firewall traffic in den betroffenen Regeln aktiviert werden. Sonst fehlt später genau die Information, welche Regel einen Test erlaubt oder blockiert hat. Der allgemeine Prüfablauf steht in Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.

Automatisch erstellte Regeln bewusst prüfen

Beim Erstellen einer Site-to-Site-IPsec-Verbindung kann die Option Create firewall rule helfen, einen ersten Regelsatz anzulegen. Das ersetzt aber keine Sicherheitsprüfung. Sophos Firewall erstellt diese Regeln an oberster Stelle der Firewall-Regelliste. In aktuellen SFOS-Versionen entstehen dafür getrennte Regeln für eingehenden und ausgehenden Traffic mit den Präfixen Incoming und Outgoing.

Für den Betrieb ist deshalb wichtig:

• Regelposition: Automatisch erstellte Regeln nach dem Speichern an die richtige Stelle verschieben.
• Richtung: Eingehende und ausgehende Regel getrennt prüfen, nicht nur den Tunnelnamen.
• Quellen und Ziele: Lokale und entfernte Netze enger setzen, wenn der Assistent zu breit erstellt.
• Dienste: Any nur für den ersten Test verwenden und danach auf benötigte Dienste reduzieren.
• Logging: Während Einführung und Fehleranalyse aktivieren.
• Security Features: IPS, Web, Application Control oder NDR bewusst setzen, nicht zufällig übernehmen.

⚠️ Automatisch erstellte Firewall-Regeln sind ein Startpunkt, kein fertiges Sicherheitsdesign. Besonders bei Standorttunneln zu Servernetzen sollte man nach dem ersten Test die Dienste, Quellen und Ziele reduzieren.

Bei route-based IPsec mit Any-zu-Any-Subnetzen muss man besonders sauber arbeiten. Für solche route-based Designs können keine automatischen Firewall-Regeln erstellt werden. Bei Dual-IP-Versionen sind IPv4- und IPv6-Regeln getrennt zu planen. In diesen Szenarien sollten Firewall-Regeln, XFRM-Interface, Routen und Tests bewusst manuell aufgebaut werden.

Policy-based IPsec einrichten

Policy-based IPsec ist die klassische Variante für einfache Site-to-Site-Verbindungen. Die lokalen und entfernten Netze werden direkt in der IPsec-Verbindung definiert.

1. IPsec-Profil prüfen oder erstellen

Menüpfad:

Profiles > IPsec profiles

Zuerst prüfen, ob ein vorhandenes Profil zur Gegenstelle passt. Wenn ein eigenes Profil benötigt wird, sollte es eindeutig benannt werden, zum Beispiel IPsec_IKEv2_AES256_G14. Der Name muss später verständlich bleiben, wenn mehrere Tunnel und Gegenstellen existieren.

Zu dokumentieren sind mindestens:

• IKE-Version
• Phase-1-Encryption und Authentication
• DH Group
• Phase-2-Encryption und Authentication
• PFS
• Key lifetime

Bei Drittanbieter-Firewalls sollte die Gegenstelle dieselben Werte schriftlich bestätigen. Ein Screenshot allein ist oft nicht genug, weil einzelne Felder je nach Hersteller anders benannt sind.

2. IPsec-Verbindung hinzufügen

Menüpfad:

Site-to-site VPN > IPsec

Eine neue IPsec-Verbindung erstellen und als Connection type Policy-based wählen. Danach die Grunddaten setzen:

• Name des Tunnels, zum Beispiel branch-zurich
• IP version, meistens IPv4
• Gateway type, zum Beispiel Respond only in der Zentrale oder Initiate the connection in der Filiale
• Listening interface als lokales WAN-Interface
• Gateway address der Gegenstelle als IP-Adresse oder DNS-Hostname
• Authentication type: Preshared Key oder Zertifikat
• Local ID und Remote ID, falls benötigt
• IPsec profile
• Local subnet
• Remote subnet

Bei Respond only kann eine Wildcard-Adresse * sinnvoll sein, wenn mehrere Filialen oder dynamische Gegenstellen zur Zentrale verbinden. Dann sind Local ID und Remote ID nicht optionaler Schmuck, sondern die eigentliche Unterscheidung der Peers. Bei Initiate the connection sollte die Gegenstelle als IP-Adresse oder Hostname definiert werden.

Bei Preshared Keys sollte ein starker, eindeutiger Schlüssel verwendet und sicher dokumentiert werden. Ein gemeinsam genutzter alter Standardschlüssel über mehrere Standorte ist ein unnötiges Betriebsrisiko.

Die erweiterten Einstellungen für User authentication mode gehören nur zu IKEv1-Profilen mit XAuth-Logik, etwa sehr alten Client-Server-Designs. Für normale Site-to-Site-Verbindungen mit IKEv2 sollte man daraus keinen zusätzlichen Authentifizierungsschritt ableiten. Ebenso sollten veraltete Idle-Connection-Settings nicht als modernes Betriebsdesign eingeplant werden.

3. Tunnel aktivieren

Beim Speichern kann Activate on save gesetzt werden. Bei produktiven Umgebungen sollte das in einem definierten Wartungsfenster passieren, wenn die Gegenstelle erreichbar ist und beide Seiten Logs prüfen können.

Nach dem Speichern zeigt die Liste zwei relevante Zustände:

• ob die Verbindung aktiv ist
• ob der Tunnel tatsächlich established ist

Ein aktiver Eintrag ist nicht automatisch ein aufgebauter Tunnel. Bei mehreren lokalen oder entfernten Netzen kann es ausserdem mehrere Security Associations geben.

Route-based IPsec einrichten

Route-based IPsec trennt VPN-Verhandlung und Routing klarer. Sophos Firewall erstellt dabei ein XFRM-Interface. Danach entscheiden statische Routen, SD-WAN Routes oder dynamisches Routing, welcher Traffic durch den Tunnel läuft.

1. Verbindung als route-based erstellen

Menüpfad:

Site-to-site VPN > IPsec

Bei der Verbindung Route-based (Tunnel interface) wählen. Die Parameter für Gateway, Authentifizierung, IDs und IPsec-Profil müssen weiterhin zur Gegenstelle passen. Zusätzlich muss man verstehen, welches XFRM-Interface danach entsteht und wie es geroutet wird.

Sophos zeigt das erzeugte XFRM-Interface unter dem verwendeten physischen Interface in:

Network > Interfaces

Je nach Design braucht das XFRM-Interface eine IP-Adresse. Besonders bei Any-zu-Any-Designs, Dual-IP-Version oder komplexeren Routing-Szenarien sollte die Interface-Adressierung sauber geplant werden. Das XFRM-Interface bleibt der VPN-Zone zugeordnet; diese Zonenzuordnung ist kein frei wählbares Designfeld wie bei normalen physischen Interfaces.

Wenn Any-zu-Any verwendet wird, entscheidet nicht mehr der Tunnel-Selector allein, welcher Traffic durch den Tunnel geht. Routen und Firewall-Regeln werden dann zur zentralen Steuerung. Das ist flexibel, aber auch fehleranfällig: Eine zu breite Regel kann mehr Traffic erlauben als beabsichtigt, eine fehlende Route kann den Tunnel grün zeigen lassen, ohne dass Nutztraffic fliesst.

Bei route-based VPN gibt es zwei wichtige Einschränkungen:

• Wenn beide Subnetze auf Any stehen oder Dual verwendet wird, muss das XFRM-Interface unter Network > Interfaces adressiert und danach über statische Route, SD-WAN Route oder dynamisches Routing genutzt werden.
• Wenn specific traffic selectors verwendet werden, erzeugt Sophos zwar ein XFRM-Interface, aber dieses Interface wird nicht wie ein Any-to-Any-XFRM mit IP-Adresse und manuellen Routen betrieben. Sophos erstellt die passende Route automatisch, wenn der Tunnel established ist.

Man sollte deshalb nicht nachträglich zwischen Any-to-Any und konkreten Selectors hin und her planen. Sophos erlaubt bei route-based Any-to-Any nicht einfach eine Änderung auf spezifische Traffic Selectors; dafür muss die Verbindung geklont oder neu aufgebaut werden.

2. Routing setzen

Bei route-based VPN reicht die IPsec-Verbindung allein nicht. Es braucht eine Route zum entfernten Netz:

• statische Route zum XFRM-Interface
• SD-WAN Route mit passendem Gateway oder Profil
• dynamische Route über BGP oder OSPF, wenn das Design dafür gebaut ist

Für einfache Setups ist eine statische Route oft ausreichend. Wenn mehrere WAN-Leitungen, SLA-Prüfungen oder Failoverpfade genutzt werden, ist eine SD-WAN Route sinnvoller. Der allgemeine Kontext zu SD-WAN, Reply Packets und systemgeneriertem Traffic steht in Sophos Firewall SD-WAN Routing für Reply Packets und System Traffic prüfen.

Bei route-based Any-to-Any sollte man nach dem Speichern bewusst drei Dinge prüfen:

1. XFRM-Interface unter Network > Interfaces sichtbar und adressiert.
2. Route zum Remote-Netz zeigt auf das XFRM-Interface beziehungsweise den passenden Gateway.
3. Firewall-Regeln erlauben genau die geplanten Richtungen und Dienste.

3. XFRM und MTU beachten

Route-based VPNs sind anfälliger für Missverständnisse bei Routing, MTU und MSS. Wenn kleine Tests funktionieren, grössere Transfers aber hängen bleiben, sollte man nicht sofort das IPsec-Profil ändern. Zuerst MTU, MSS, Fragmentierung und den echten Pfad prüfen. Der passende Ablauf steht in Sophos Firewall MTU und MSS bei VPN-Problemen prüfen.

Firewall-Regeln erstellen

Nach der IPsec-Konfiguration braucht es Regeln für den produktiven Traffic. Ohne passende Regeln bleibt der Tunnel zwar möglicherweise grün, Anwendungen funktionieren aber nicht.

Menüpfad:

Rules and policies > Firewall rules

Typische Regeln:

• Lokales Netz zu entferntem Netz: zum Beispiel LAN nach VPN oder Zielzone.
• Entferntes Netz zu lokalem Servernetz: zum Beispiel VPN oder XFRM-Zone nach Server.
• Management oder Monitoring: nur definierte Admin- oder Monitoring-Systeme erlauben.
• DNS, AD, RDP, HTTPS: nur benötigte Dienste freigeben, nicht pauschal Any.

Gute Praxis:

• Regelname mit Tunnel oder Standort, zum Beispiel LAN_to_Branch_Zurich.
• Source und Destination so eng wie möglich setzen.
• Services konkret definieren.
• Logging während Einführung und Troubleshooting aktivieren.
• Regelposition prüfen.
• Schutzfunktionen bewusst setzen, statt sie zufällig zu übernehmen.

Bei policy-based und route-based IPsec braucht man inbound und outbound Regeln, wenn beide Richtungen aktiv genutzt werden. Eine einzelne breite Regel wirkt schnell praktisch, verwischt aber die Frage, welche Seite welche Dienste wirklich erreichen darf. Für die Abnahme sind getrennte Regeln mit Logging oft besser lesbar.

Wenn der Tunnel Internettraffic einer Filiale über die Zentrale führen soll, braucht es zusätzlich ein bewusstes NAT- und Sicherheitskonzept. Das ist ein anderes Design als eine einfache Standortverbindung für interne Netze.

NAT bewusst planen

NAT ist bei IPsec nicht verboten, aber es muss klar begründet sein. Typische Fälle sind überlappende Netze, Cloud-Vorgaben oder Drittanbieter, die nur bestimmte Quelladressen akzeptieren.

Menüpfad:

Rules and policies > NAT rules

Vor einer NAT-Regel sollten diese Fragen beantwortet sein:

• Erwartet die Gegenstelle Original-IP-Adressen oder übersetzte Adressen?
• Gibt es überlappende Netze?
• Wird NAT in der IPsec-Verbindung oder über separate NAT-Regeln gelöst?
• Ist die Rückrichtung dokumentiert?
• Sieht der Log Viewer nach NAT die erwartete Source und Destination?

Für policy-based Sonderfälle mit NAT kann eine manuelle IPsec Route auf Sophos Firewall relevant werden. Das ist aber kein Standard-Schritt für jeden Tunnel.

Die NAT-Logik unterscheidet sich je nach VPN-Typ:

• Bei policy-based IPsec und route-based VPN mit Traffic Selectors kann NAT direkt in der IPsec-Verbindung für überlappende Netze konfiguriert werden.
• Bei route-based Any-to-Any werden NAT-Regeln unter Rules and policies > NAT rules verwendet.
• Bei überlappenden Netzen müssen beide Seiten denselben Übersetzungsplan verstehen. Einseitiges NAT ohne Rückplanung erzeugt oft grüne Tunnel ohne nutzbaren Verkehr.

Device Access und WAN-Zugriff

Für eingehende IPsec-Anfragen muss die Firewall IPsec-Traffic auf der passenden WAN-Zone annehmen können. Das wird nicht über eine normale LAN-zu-WAN-Regel gelöst, sondern über die lokalen Dienste der Firewall.

Menüpfad:

Administration > Device access

Dort muss IPsec für die benötigte Zone erlaubt sein. Gleichzeitig sollte man prüfen, ob andere lokale Dienste wie WebAdmin, SSH, User Portal oder VPN Portal unnötig breit erreichbar sind. Für die Härtung dieser lokalen Dienste ist Sophos Firewall Zugriff absichern: Device Access richtig konfigurieren der zentrale Artikel.

Tunnel testen

Ein guter Abnahmetest prüft nicht nur den grünen Status. Er prüft den tatsächlichen Datenfluss.

Abnahmematrix definieren

Vor dem ersten Test sollte eine kleine Abnahmematrix feststehen. Dadurch wird klar, welche Verbindung wirklich funktionieren muss und welche Verbindung bewusst nicht erlaubt sein soll.

Sinnvolle Testfälle:

• Lokales Clientnetz zu entferntem Servernetz: typischer Anwendungstest, zum Beispiel HTTPS, RDP, SMB, SQL oder ICMP nur als Basistest.
• Entferntes Clientnetz zu lokalem Servernetz: Gegenrichtung prüfen, wenn die Verbindung bidirektional genutzt wird.
• DNS oder AD über den Tunnel: nur testen, wenn diese Dienste wirklich über den Tunnel laufen sollen. Dabei Source, Zielserver und Port konkret festlegen.
• Monitoring oder Backup: prüfen, ob geplante Systeme aus der richtigen Richtung zugreifen und nicht versehentlich Any-Regeln benötigen.
• Nicht erlaubter Test: ein bewusst nicht freigegebener Port oder ein nicht erlaubtes Netz sollte blockiert werden. Sonst ist die Regelbasis zu breit.
• Grosse Übertragung: bei Dateiübertragung, RDP, VoIP oder Applikationsproblemen zusätzlich MTU/MSS und Fragmentierung beobachten.

Pro Testfall sollte man Source IP, Destination IP, Service, erwartete Firewall-Regel, erwartete NAT-Regel und erwartete Richtung notieren. Nach jedem Test werden Log Viewer, Packet Capture und Byte-Zähler verglichen. Wenn nur Ping getestet wird, ist der Tunnel noch nicht abgenommen.

1. Status prüfen

In der WebAdmin-Oberfläche:

Site-to-site VPN > IPsec

Prüfen:

• Verbindung ist aktiv.
• Tunnelstatus ist established.
• Bei mehreren Netzen sind alle erwarteten Child SAs aufgebaut.
• Keine wiederkehrenden Reconnects oder Fehler sichtbar.

2. Log Viewer prüfen

Menüpfad:

Log viewer

Testtraffic mit klarer Source, Destination und Service erzeugen. Danach im Log Viewer prüfen, welche Firewall-Regel matcht und ob NAT, Webfilter, IPS oder andere Module den Traffic beeinflussen.

3. Packet Capture verwenden

Wenn der Log Viewer nicht reicht, sollte Packet Capture mit engem Filter verwendet werden:

Diagnostics > Tools > Packet capture

Filterbeispiel:

host 172.16.10.25 and host 10.20.30.15

Bei VPN-Troubleshooting ist wichtig, beide Richtungen zu prüfen. Nur ausgehende Pakete ohne Antwort zeigen meistens ein Rückweg-, NAT- oder Gegenstellenproblem.

4. CLI nur gezielt verwenden

Für tiefere Analyse kann per SSH die Advanced Shell genutzt werden:

ipsec statusall

Dabei sind unter anderem interessant:

• IKE SA established
• Child SA installed
• lokale und entfernte Netze
• Byte-Zähler in beide Richtungen
• wiederkehrende Rekey- oder Disconnect-Meldungen

Wenn SSH noch nicht vorbereitet ist, hilft Sophos Firewall per SSH verbinden.

Typische Fehler

• Tunnel baut nicht auf: IKE-Version, Profil, PSK, Zertifikat, Local ID oder Remote ID passt wahrscheinlich nicht. strongswan.log, IPsec-Profil und Gegenstelle prüfen.
• Phase 1 steht, Phase 2 nicht: Lokale oder entfernte Netze beziehungsweise Phase-2-Proposal passen wahrscheinlich nicht. Traffic Selectors, Subnetze und PFS prüfen.
• Tunnel ist grün, aber kein Zugriff: Firewall-Regel, NAT, Routing oder Rückweg fehlt wahrscheinlich. Log Viewer, Packet Capture und Routing prüfen.
• Nur eine Richtung funktioniert: Die Gegenstelle kennt die Rückroute nicht oder NAT ist falsch. Gegenstelle, NAT-Regeln und Byte-Zähler prüfen.
• Kleine Pings funktionieren, Anwendungen hängen: MTU/MSS, Fragmentierung oder ein Security Feature ist wahrscheinlich beteiligt. MTU/MSS und Packet Capture prüfen.
• Route-based Tunnel funktioniert unklar: XFRM-Interface, Route oder SD-WAN Route passt wahrscheinlich nicht. Network > Interfaces, Routing und SD-WAN prüfen.
• Mehrere Tunnel beeinflussen sich: Überlappende Netze oder ähnliche Selector-Konfigurationen sind wahrscheinlich. Tunnelobjekte, Failover-Gruppe und Routen prüfen.

Checkliste

Vor dem Change:

• Lokale und entfernte Netze sind eindeutig.
• Policy-based oder route-based wurde bewusst entschieden.
• IPsec-Profil ist mit der Gegenstelle abgestimmt.
• Preshared Key oder Zertifikate sind sicher dokumentiert.
• Firewall-Regeln sind geplant, inklusive Richtung, Regelposition, Logging und Diensten.
• Bei Create firewall rule ist klar, welche automatisch erstellten Regeln nachbearbeitet werden müssen.
• Bei route-based Any-zu-Any sind manuelle Firewall-Regeln und Routen eingeplant.
• NAT ist entweder ausgeschlossen oder bewusst dokumentiert.
• Device Access für IPsec ist geprüft.
• Wartungsfenster, Gegenstelle und Rückfallweg sind bekannt.

Nach dem Change:

• Tunnelstatus ist established.
• Abnahmematrix mit mindestens einem Test pro benötigter Richtung definiert.
• Log Viewer zeigt die erwartete Firewall-Regel.
• Packet Capture zeigt Hin- und Rückrichtung.
• Interne DNS- und Anwendungszugriffe wurden getestet.
• Byte-Zähler steigen in beide Richtungen.
• NAT und Rückweg sind mit der Gegenstelle abgeglichen.
• Änderung ist in der Netzwerkdokumentation nachgeführt.

Häufige Fragen