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 sowie lokale und entfernte IDs schriftlich festlegen.
2. Auf beiden Firewalls Uhrzeit, 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 sowie expliziten Peer-IDs 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 10.10.10.0/24 → SF1 → policy-based IPsec → SF2 → 10.20.20.0/24 SF2-LAN

• SF1-WAN: 198.51.100.10
• SF2-WAN: 203.0.113.20
• SF1-Zertifikat: SF1_Certificate
• SF2-Zertifikat: SF2_Certificate
• SF1 Certificate ID: 198.51.100.10
• SF2 Certificate ID: 203.0.113.20

Die WAN-Adressen stammen aus den Dokumentationsnetzen nach RFC 5737, die LAN-Adressen aus privaten Netzen. 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.

Vor dem Erstellen wird unter Administration > Time eine funktionierende NTP-Synchronisation geprüft. Falsche Uhrzeiten können Zertifikatsimporte und die Gültigkeitsprüfung scheitern lassen. Für diesen IPsec-Ablauf werden ausserdem RSA-Zertifikate benötigt; SFOS 22 unterstützt ECDSA-Zertifikate zwar für andere Zwecke, aber nicht für IPsec-Verbindungen.

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 mit dem Zweck Validation only 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. Bei einer Subordinate CA muss auch deren Root CA vorhanden sein. 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. Als Remote CA certificate wird keine öffentliche CA gewählt: Sophos warnt, dass sonst jedes passende, von dieser CA ausgestellte Zertifikat einen unerwünschten Zugang ermöglichen kann.

Lokale und entfernte Zertifikate vorbereiten

Eigenes Zertifikat auf SF1 erstellen

Auf SF1 wird unter Certificates > Certificates > Add > Generate locally-signed certificate ein Zertifikat angelegt. Gewählt werden RSA, eine zur eigenen Richtlinie passende Key length und ein zulässiger Secure hash; RSA 2048 und SHA-256 sind die Beispielwerte aus der Sophos-Anleitung. Valid from und Valid until werden so festgelegt, dass genug Zeit für einen kontrollierten Renewal bleibt. SFOS setzt standardmässig ein Jahr, doch die Organisationsrichtlinie entscheidet über die tatsächliche Laufzeit.

Als Name wird im Beispiel SF1_Certificate verwendet, als Common name SophosFirewall1; auf SF2 entsprechend SF2_Certificate und SophosFirewall2. Diese Namen werden passend zur eigenen Umgebung gewählt. Der Common name ist ein eigenes Zertifikatsfeld und ersetzt weder den Objektnamen noch die separat gewählte Certificate ID.

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 198.51.100.10 verwendet. Sophos erlaubt hier jede gültige IP-Adresse; gewählt wird ein stabiler Identifier, dessen Typ und Wert in der Peer-Konfiguration gespiegelt werden.

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.

Beim Upload auf beiden Gegenstellen wird Certificate file format ausdrücklich auf CER (.cer) gesetzt. Unter Certificate > Choose File wird das von der anderen Firewall heruntergeladene öffentliche Zertifikat ausgewählt und mit Save gespeichert. Das Umbenennen einer Dateierweiterung wählt dieses Format nicht aus und konvertiert auch keine Zertifikatskodierung; der private Schlüssel wird nicht übertragen.

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 203.0.113.20, 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. SFOS ergänzt lokal gesperrte, lokal signierte Zertifikate automatisch in der eigenen Default-CRL. Die Gegenstelle erhält diese Information aber erst, wenn die aktuelle CRL dorthin übertragen und unter Certificates > Certificate revocation lists > Add importiert wird. Bei extern ausgestellten Zertifikaten wird die CRL der externen CA importiert. Den Gesamtprozess erklärt Certificate Revocation Lists auf Sophos Firewall.

Vor dem Anlegen der Verbindung werden auf beiden Firewalls unter Hosts and services > IP host > Add die Netzobjekte erstellt oder vorhandene Objekte geprüft:

• Name: SF1_LAN; IP version: IPv4; Type: Network; IP address: 10.10.10.0; Subnet: 255.255.255.0 (/24).
• Name: SF2_LAN; IP version: IPv4; Type: Network; IP address: 10.20.20.0; Subnet: 255.255.255.0 (/24).

Jedes Objekt wird mit Save gespeichert. Namen, Netzadressen und Masken sind anpassbare Beispielwerte und müssen die tatsächlich freizugebenden LAN-Netze abbilden. Auf SF1 ist SF1_LAN lokal und SF2_LAN entfernt; auf SF2 ist es umgekehrt. Vor der Auswahl als Local oder Remote subnet werden die Werte auf beiden Seiten abgeglichen, damit nicht versehentlich ein zu grosses Netz freigegeben wird.

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
• Remote CA certificate: SF2_CA
• Listening interface: WAN von SF1
• Local subnet: SF1_LAN
• Gateway address: WAN-Adresse von SF2
• Remote subnet: SF2_LAN
• Local ID type / Local ID: IP address / 198.51.100.10
• Remote ID type / Remote ID: IP address / 203.0.113.20

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
• Remote CA certificate: SF1_CA
• Local subnet: SF2_LAN
• Gateway address: WAN-Adresse von SF1
• Remote subnet: SF1_LAN
• Local ID type / Local ID: IP address / 203.0.113.20
• Remote ID type / Remote ID: IP address / 198.51.100.10

Die Profile und IDs müssen als Paar geplant sein: Local ID auf der einen Seite entspricht Remote ID auf der anderen. DNS-, IP- und E-Mail-IDs müssen nicht als Gateway-Adresse auflösbar sein, aber Typ und Wert müssen exakt gespiegelt werden. Bei DER ASN1 DN [X.509] wird als Remote ID der Distinguished Name des Peer-Zertifikats eingetragen. 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 je eine eingehende und ausgehende Regel oben in der Gruppe Automatic VPN rules. 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.

Erst wenn CA-Vertrauen, Zertifikate, IDs, Netzobjekte, Device Access und Regelplanung auf beiden Seiten geprüft sind, wird die Verbindung aktiviert. Bei einer produktiven Umstellung erfolgt dies im Wartungsfenster mit dem vorbereiteten Rückweg: Auf SF1 wird Activate on save eingeschaltet und Save gewählt, danach ebenso auf SF2. Dadurch wird der Responder aktiviert und die Filiale kann die Verbindung initiieren. Save allein ist ohne diese Option kein verlässlicher Aktivierungsschritt. Automatisch erzeugte Regeln werden anschliessend wie oben beschrieben geprüft; sie werden nicht blind vor bestehende Sicherheitsregeln verschoben.

Tunnel und Zertifikate abnehmen

Die Abnahme trennt vier Ebenen:

1. Unter Site-to-site VPN > IPsec wird auf SF1 die grüne Anzeige in Active geprüft: Der Responder ist damit aktiviert, aber ein Tunnel ist noch nicht nachgewiesen. Nach dem Verbindungsaufbau durch SF2 müssen dort Active und Connection grün sein. Connection bestätigt den aufgebauten Tunnel; erst der anschliessende Diensttest weist nutzbaren Traffic nach. Bleibt Connection nicht grün, werden die folgenden Zertifikats- und Logprüfungen durchgeführt.
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.

/log/strongswan.log ist der wichtigste Startpunkt für IKE- und Zertifikatsfehler. Ergänzend dokumentieren /log/charon.log den IPsec-VPN-Dienst und /log/ipsec_monitor.log die Überwachung des IPsec-Diensts; /log/ipsec_conn/ipsec_<connectionname>.log erfasst verbindungsspezifische Aktionen. /log/dgd.log ist bei Link- oder VPN-Failover relevant. 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. Zusätzlich wird geprüft, ob das richtige Remote CA certificate ausgewählt ist. 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 Local und Remote ID nach Typ und Wert spiegelbildlich zusammenpassen. In /log/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.

Bei einem HA-Cluster erfolgen die Änderungen am aktuellen Primary; danach wird die Synchronisation der Firewall-Konfiguration zum Auxiliary abgewartet. Zertifikatsauswahl und Tunnel werden zuerst am Primary geprüft und ein geplanter HA-Failover anschliessend mit echtem Traffic abgenommen. Ein Backup mit HA wird nur am aktuellen Primary wiederhergestellt; die Wiederherstellung startet ihn ohne Failover neu. Das ist ein Notfallweg mit Unterbruch, kein schneller Ersatz für das Zurückstellen der Zertifikatszuweisung.

Häufige Fragen