Sophos Firewall IPsec Site-to-Site mit Zertifikaten einrichten

Ein gemeinsamer Preshared Key ist für einen einzelnen Standorttunnel schnell eingerichtet. Bei mehreren Firewalls oder strengeren PKI-Vorgaben ist ein digitales Zertifikat oft besser kontrollierbar: Jede Seite besitzt einen eigenen privaten Schlüssel, die Gegenstellen vertrauen den ausstellenden CAs, und ein einzelnes Zertifikat lässt sich gezielt erneuern oder sperren.

Dieser Ablauf zeigt eine policy-based IPsec-Verbindung zwischen zwei Sophos Firewalls. Er ergänzt die allgemeine Anleitung Site-to-Site IPsec VPN einrichten. Für route-based Designs bleiben Routing und XFRM zusätzlich zu planen; der hier beschriebene Trust- und Zertifikatsablauf bleibt jedoch derselbe.

Der sichere Ablauf in acht Schritten

1. Tunnelrollen, Netze, IKEv2-Profil und Certificate IDs schriftlich festlegen.
2. Auf beiden Firewalls Konfigurationsbackup und funktionierenden Adminzugang prüfen.
3. Die ausstellende CA jeder Firewall exportieren und auf der Gegenstelle importieren.
4. Auf jeder Firewall ein eigenes lokal signiertes Zertifikat mit eindeutiger Certificate ID erzeugen.
5. Nur das öffentliche Zertifikat exportieren und auf der Gegenstelle als Remote Certificate importieren.
6. Policy-based IPsec mit Authentication type > Digital certificate auf beiden Seiten anlegen.
7. Device Access und automatisch erzeugte Firewall-Regeln eng prüfen.
8. Tunnelstatus, Zertifikatsvertrauen, Logs und echten Traffic in beiden Richtungen abnehmen.

⚠️ Die private Schlüsseldatei bleibt auf der Firewall, auf der das Zertifikat erzeugt wurde. Für den Trust-Austausch werden nur CA-Zertifikate und öffentliche Peer-Zertifikate übertragen. Ohne getesteten zweiten Adminzugang, Backup und dokumentierten Rückweg werden weder bestehende PSK-Tunnel deaktiviert noch produktive Zertifikate ersetzt.

Beispiel und Planungswerte

Das Beispiel verbindet die Zentrale SF1 mit der Filiale SF2:

SF1-LAN 192.10.10.0/24 → SF1 → policy-based IPsec → SF2 → 192.20.20.0/24 SF2-LAN

• SF1-WAN: 172.10.10.1
• SF2-WAN: 172.20.20.1
• SF1-Zertifikat: SF1_Certificate
• SF2-Zertifikat: SF2_Certificate
• SF1 Certificate ID: 172.10.10.1
• SF2 Certificate ID: 172.20.20.1

Diese Adressen und Namen sind Dokumentationswerte. In der eigenen Umgebung werden die echten WAN-Adressen, Netzobjekte und ein organisationsweit eindeutiges ID-Schema verwendet. Die Certificate ID muss dauerhaft zur jeweiligen Gegenstelle passen und darf nicht spontan mit dem Anzeigenamen oder einem beliebigen SAN verwechselt werden.

CA-Vertrauen gegenseitig herstellen

Zuerst wird auf SF1 unter Certificates > Certificate authorities die ausstellende CA geprüft und heruntergeladen. Verwendet das Beispiel die lokale Default CA, wird die exportierte Datei eindeutig als Head_Office_Default.pem benannt. Auf SF2 wird sie unter Certificates > Certificate authorities > Add beispielsweise als SF1_CA importiert.

Danach folgt derselbe Ablauf in Gegenrichtung: Die CA von SF2 wird exportiert, eindeutig als Branch_Office_Default.pem benannt und auf SF1 beispielsweise als SF2_CA importiert.

Die Dateinamen dienen nur der Administration. Entscheidend sind Subject, Issuer, Fingerprint, Laufzeit und die richtige CA-Kette. Vor dem Import werden diese Werte über einen unabhängigen Kanal abgeglichen. Die allgemeinen Aufgaben rund um CAs, Zertifikate und Dienstzuweisungen erklärt Zertifikate auf Sophos Firewall verwalten.

Die eingebaute Default CA darf nicht nebenbei neu erzeugt werden. Eine Regeneration verändert den Trust Anchor und kann weitere Portale, TLS-Dienste und IPsec-Peers betreffen. Für eine Unternehmens-CA wird stattdessen deren vollständige vertrauenswürdige Kette importiert.

Lokale und entfernte Zertifikate vorbereiten

Eigenes Zertifikat auf SF1 erstellen

Auf SF1 wird unter Certificates > Certificates > Add > Generate locally-signed certificate ein Zertifikat angelegt. Das Sophos-Beispiel verwendet RSA, eine Key length von 2048 und SHA-256. Diese Werte sind kein Ersatz für die eigene Kryptografie- und Laufzeitrichtlinie; das gewählte IPsec-Profil und beide Peers müssen sie unterstützen.

Unter Subject Alternative Names (SANs) > Advanced settings wird eine Certificate ID ausgewählt. Unterstützt sind DNS, IP address, Email und DER ASN1 DN [X.509]. Im Beispiel wird IP address mit 172.10.10.1 verwendet.

Bei DER ASN1 DN [X.509] übernimmt Sophos den Subject der ausstellenden CA. In diesem Fall bleiben DNS names und IP address unter den SANs leer, weil die zusätzliche Belegung laut Sophos zu einem Konflikt bei der IPsec-Authentifizierung führt.

Nach Save werden Laufzeit, Issuer, Certificate ID und das Vorhandensein des privaten Schlüssels geprüft. Das Zertifikat wird öffentlich exportiert, die Erweiterung bei Bedarf auf .cer gesetzt und auf SF2 unter Certificates > Certificates > Add > Upload certificate als SF1_Certificate importiert. In der Spalte Trusted muss die Gegenstelle den Trust über SF1_CA bestätigen.

Eigenes Zertifikat auf SF2 erstellen

Auf SF2 wird derselbe Ablauf mit einem separaten privaten Schlüssel wiederholt. Im Beispiel heisst das Zertifikat SF2_Certificate, die Certificate ID ist 172.20.20.1, und die ausstellende CA ist die lokale CA von SF2.

Das öffentliche Zertifikat wird auf SF1 importiert. Dort muss Trusted über die zuvor importierte SF2_CA bestätigt sein. Damit besitzt jede Firewall genau zwei verschiedene Rollen:

• Local certificate: eigenes Zertifikat mit privatem Schlüssel.
• Remote certificate: öffentliches Zertifikat der Gegenstelle, validiert durch deren CA.

Ein grüner Trust-Haken beweist die Zertifikatskette, aber noch keinen funktionierenden Tunnel. Laufzeit, Certificate ID, IKE-Profil, Gateway und Netze müssen weiterhin zusammenpassen. Sperrung und CRL-Verteilung sind ein eigener Betriebsprozess; dazu gehört Certificate Revocation Lists auf Sophos Firewall.

IPsec-Verbindung auf beiden Seiten anlegen

Unter Site-to-site VPN > IPsec > Add werden zwei zueinander passende Verbindungen erstellt. Die Zentrale wartet im Beispiel auf die Filiale:

• Connection type: Policy-based
• Gateway type: Respond only
• Profile: Head office (IKEv2) oder ein abgestimmter eigener Profilklon
• Authentication type: Digital certificate
• Local certificate: SF1_Certificate
• Remote certificate: SF2_Certificate
• Listening interface: WAN von SF1
• Local subnet: SF1_LAN
• Gateway address: WAN-Adresse von SF2
• Remote subnet: SF2_LAN

Auf der Filiale werden die Rollen gespiegelt:

• Gateway type: Initiate the connection
• Profile: Branch office (IKEv2) oder das dazu passende eigene Profil
• Local certificate: SF2_Certificate
• Remote certificate: SF1_Certificate
• Local subnet: SF2_LAN
• Gateway address: WAN-Adresse von SF1
• Remote subnet: SF1_LAN

Die Profile müssen als Paar geplant sein. Wie IKEv2, Phase 1, Phase 2, PFS, Lifetimes und DPD zusammenspielen, steht unter IPsec-Profile auf Sophos Firewall verstehen.

Device Access und Firewall-Regeln prüfen

Die Seite mit Gateway type > Respond only muss IPsec-Verbindungen am vorgesehenen WAN-Pfad annehmen dürfen. Unter Administration > Device access wird deshalb IPsec nur für die tatsächlich benötigte WAN-Zone aktiviert oder bei bekannten Peer-Adressen über eine enge Local Service ACL Exception freigegeben. SSO, Zertifikate oder ein starker IPsec-Algorithmus rechtfertigen keine breite WebAdmin- oder SSH-Freigabe. Die sichere ACL-Planung steht unter Device Access auf Sophos Firewall.

Ist Create firewall rule aktiviert, erstellt SFOS automatische VPN-Regeln. Diese Regeln sind ein Startpunkt. Unter Rules and policies > Firewall rules werden Reihenfolge, Richtung, Quell- und Zielnetze, Dienste und Logging kontrolliert und auf den wirklichen Bedarf reduziert. Firewall-Regeln auf Sophos Firewall erstellen erklärt den Regeltest.

Ping/Ping6 für die VPN-Zone ist nur nötig, wenn bewusst eine Firewalladresse selbst als Testziel dienen soll. Für einen normalen End-to-End-Test zwischen Hosts hinter den Firewalls muss dieser lokale Dienst nicht pauschal geöffnet werden.

Tunnel und Zertifikate abnehmen

Die Abnahme trennt vier Ebenen:

1. Unter Site-to-site VPN > IPsec sind Verbindung und Tunnel aktiv.
2. Beide Firewalls zeigen das erwartete Local und Remote Certificate, gültige Laufzeiten und einen vertrauenswürdigen Issuer.
3. Ein echter Testhost erreicht den vorgesehenen Dienst im entfernten Netz, danach wird die Gegenrichtung geprüft.
4. Firewall Rule ID, Packet Capture und IPsec-Logs bestätigen denselben Pfad und dieselben Zeitstempel.

strongswan.log ist der wichtigste Startpunkt für IKE- und Zertifikatsfehler. Ergänzend helfen charon.log, ipsec_monitor.log und das verbindungsspezifische Log unter /log/ipsec_conn/. Den vollständigen Diagnoseablauf beschreibt Sophos Firewall IPsec Troubleshooting.

Fehler nach Symptom eingrenzen

Tunnel bleibt down

Zuerst wird geprüft, ob Local certificate und Remote certificate auf beiden Seiten wirklich gespiegelt sind. Danach folgen Certificate ID, Gateway address, IKEv2-Profil, Laufzeit und Trust-Kette. Ein importiertes Peer-Zertifikat ohne passende CA bleibt kein vertrauenswürdiger Identitätsnachweis.

Zertifikat ist Trusted, Authentifizierung schlägt trotzdem fehl

Trusted bestätigt nur die Kette. Bei DER ASN1 DN [X.509] dürfen keine zusätzlichen DNS- oder IP-SAN-Werte den Identifier überlagern. Bei den anderen ID-Typen müssen Wert, Typ und erwartete Gegenstelle genau zusammenpassen. In strongswan.log werden die tatsächlich angebotenen und erwarteten IDs zum selben Verbindungsversuch verglichen.

Tunnel ist grün, aber kein Traffic fliesst

Dann ist die Zertifikatsauthentifizierung bereits erfolgt. Jetzt werden lokale und entfernte Subnetze, automatische VPN-Regeln, Rule ID, NAT, Rückroute und der echte Zielservice geprüft. Zertifikate auf Verdacht neu zu erzeugen verschleiert in diesem Fehlerbild nur den ursprünglichen Zustand.

Zertifikat läuft bald ab

Das neue lokale Zertifikat wird parallel vorbereitet, öffentlich auf die Gegenstelle übertragen und dort als vertrauenswürdig geprüft. Erst in einem Wartungsfenster werden Local certificate und Remote certificate auf beiden Seiten kontrolliert umgestellt. Alte Zertifikate und CAs bleiben bis zur erfolgreichen bidirektionalen Abnahme verfügbar und werden erst danach entfernt oder gesperrt.

Rollback und Betrieb

Vor der Umstellung werden beide IPsec-Verbindungen, Zertifikatsnamen, Fingerprints, Certificate IDs, Laufzeiten und die aktuelle Regelreihenfolge dokumentiert. Ein Sophos Firewall Konfigurationsbackup gehört dazu, ersetzt aber keinen direkten Rückweg zur Firewall.

Scheitert die Abnahme, werden die zuvor verwendeten Zertifikatszuweisungen beziehungsweise der noch vorhandene PSK-Tunnel wieder aktiviert. Neu importierte Peer-Zertifikate oder CAs werden erst gelöscht, wenn keine andere Verbindung oder kein anderer Dienst sie verwendet. Danach werden Tunnelstatus und ein echter Testfluss erneut geprüft.

Im Betrieb brauchen Zertifikate einen Owner, ein Ablaufmonitoring und ein geplantes Renewal-Fenster. Der erste Alarm sollte genügend Zeit für Ausstellung, Trust-Verteilung, parallelen Test und Rollback lassen. Ein Zertifikat erst am Ablaufdatum zu ersetzen macht aus einer planbaren Wartung einen VPN-Ausfall.

Häufige Fragen