Sophos Firewall IPsec-Profile verstehen und sicher konfigurieren

Ein IPsec-Profil bestimmt, wie sicher und unter welchen Bedingungen ein IPsec-Tunnel ausgehandelt wird. Es legt IKE-Version, Verschlüsselung, Integrität, DH-Gruppe, PFS, Lifetimes, Rekeying und Dead Peer Detection fest. Stimmen diese Werte nicht zur Gegenstelle, bleibt der Tunnel down oder fällt erst beim späteren Rekey aus.

Kurzempfehlung für neue Site-to-Site-Verbindungen: IKEv2 verwenden, nur die tatsächlich benötigten starken Proposals anbieten, PFS und Rekeying aktivieren und DPD passend zur Rolle konfigurieren. Wenn beide Gegenstellen die Werte unterstützen, ist AES256GCM16 mit DH19 und PFS19 ein moderner Ausgangspunkt. Provider- und Gegenstellenanforderungen haben jedoch immer Vorrang.

Dieser Artikel erklärt das Profil. Die eigentliche Verbindung mit Gateway, IDs, Netzen, Regeln, NAT und Routing wird unter Sophos Firewall Site-to-Site IPsec VPN einrichten beschrieben. Wenn ein bestehender Tunnel nicht aufbaut oder keinen Traffic überträgt, passt Sophos Firewall IPsec VPN Troubleshooting.

Was ein IPsec-Profil steuert

Das Profil enthält die gemeinsamen Sicherheitsparameter für Phase 1 und Phase 2. Ein Profil kann mehreren Verbindungen zugewiesen werden. Genau deshalb sollte ein verwendetes System- oder Produktionsprofil nicht spontan geändert werden: Die Änderung kann alle damit verbundenen Tunnel beim nächsten Aufbau oder Rekey treffen.

Nicht zum Profil gehören:

öffentliche Peer-Adresse oder FQDN
Preshared Key, Zertifikat oder RSA Key
Local ID und Remote ID
lokale und entfernte Netze beziehungsweise Traffic Selectors
Firewall-Regeln, NAT und Routing
XFRM-Adresse, SD-WAN Route oder Failoverpfad

Diese Werte werden in der IPsec-Verbindung oder in den zugehörigen Netzwerkregeln konfiguriert. Ein grüner Phase-1-Status beweist daher weder, dass Phase 2 passt, noch dass der Nutztraffic richtig geroutet und erlaubt wird.

Authentication ist nicht gleich Authentication type

In einem IPsec-Profil bezeichnet Authentication den Integritätsalgorithmus wie SHA2 256. In der IPsec-Verbindung bestimmt Authentication type dagegen, ob sich die Gegenstellen mit Preshared Key, Zertifikat oder RSA Key ausweisen.

Diese beiden Felder lösen unterschiedliche Aufgaben. Ein korrektes SHA2 256 repariert deshalb keinen falschen PSK, und ein passendes Zertifikat gleicht kein inkompatibles Phase-1-Proposal aus.

Phase 1 und Phase 2 verständlich erklärt

Phase 1 baut die geschützte IKE Security Association auf. Über diesen Steuerkanal authentifizieren sich die Gegenstellen und handeln weitere Schlüssel und Parameter aus. Dafür müssen mindestens IKE-Version, Verschlüsselung, Integrität und DH-Gruppe kompatibel sein.

Phase 2 erzeugt die Child beziehungsweise IPsec Security Associations für den eigentlichen Nutztraffic. Hier greifen Phase-2-Verschlüsselung, Integrität, PFS und die Traffic Selectors. Ein Tunnel kann deshalb Phase 1 erfolgreich abschliessen, während wegen eines falschen PFS-Werts oder einer abweichenden Phase-2-Kombination keine Child SA entsteht.

Bei IKEv2 kann die erste Child SA bereits zusammen mit der IKE SA aufgebaut werden. Ein PFS- oder Rekey-Problem zeigt sich dadurch unter Umständen erst nach Stunden, wenn die Child SA erneuert werden muss. Eine Abnahme ist erst vollständig, wenn mindestens ein Rekey ohne Unterbruch beobachtet wurde.

Parameter mit der Gegenstelle abstimmen

Vor der Konfiguration werden die Werte schriftlich zwischen beiden Administratoren abgestimmt. Ein Screenshot genügt oft nicht, weil Hersteller dieselbe Funktion unterschiedlich benennen.

Mindestens zu dokumentieren sind:

Rolle: Initiator, Responder oder beidseitiger Aufbau
IKE-Version und bei IKEv1 der Main- oder Aggressive Mode
Phase-1-Encryption, Authentication und DH-Gruppe
Phase-1-Key-Life, Re-key Margin und Randomisierung
Phase-2-Encryption, Authentication, PFS und Key Life
zeitbasiertes Rekeying und welche Seite es startet
DPD-Intervall und Aktion bei nicht erreichbarer Gegenstelle
bekannte Providergrenzen und erlaubte Proposals

Der Profilname muss auf beiden Geräten nicht identisch sein. Entscheidend ist, dass mindestens eine vollständige Kombination auf beiden Seiten kompatibel ist. Mehr Proposals sind dabei nicht automatisch besser: Sie vergrössern die Angriffs- und Fehlerfläche und können IKE-Pakete so weit vergrössern, dass Fragmentierung zum Problem wird.

Sichere Ausgangskonfiguration wählen

Die folgenden Beispiele sind Avanet-Ausgangspunkte für neue Site-to-Site-Verbindungen. Sie ersetzen keine Vorgabe von Azure, AWS, einem Carrier oder einer Drittanbieter-Firewall.

Modernes Profil für kontrollierte Gegenstellen

Wenn beide Seiten aktuelle Verfahren unterstützen:

Key exchange: IKEv2
Phase 1: AES256GCM16, DH19
Phase 2: AES256GCM16, PFS19
Re-key connection: On
Use strict profile: On
Compression: Off
SHA2 96-bit truncation: Off
Dead peer detection: On

AES256GCM16 ist ein AEAD-Verfahren: Es verschlüsselt und schützt die Integrität in einem Schritt. Für diese Kombination wird kein zusätzliches Authentication-Verfahren wie SHA2 ausgewählt. GCM16 bezeichnet den 16-Byte-Authentication-Tag und nicht eine 16-Bit-Verschlüsselung.

Die Pseudo-Random Function für die IKE-Schlüsselerzeugung lässt sich in SFOS nicht separat auswählen. Die Firewall leitet sie aus den angebotenen Integritätsverfahren ab und stimmt sie mit der Gegenstelle ab.

DH19 verwendet eine elliptische Kurve und bietet einen guten Kompromiss aus Sicherheitsniveau, Paketgrösse und Rechenaufwand. AES128GCM16 ist ebenfalls ein aktuelles Verfahren und nicht automatisch unsicherer für einen normalen 128-Bit-Sicherheitslevel. Die Gesamtstärke richtet sich immer nach der schwächsten Komponente des Profils.

Kompatibilitätsprofil für aktuelle Drittanbieter

Unterstützt die Gegenstelle kein AES-GCM oder keine ECP-Gruppe, ist diese Kombination ein breit kompatiblerer Ausgangspunkt:

Key exchange: IKEv2
Phase 1: AES256, SHA2 256, DH14
Phase 2: AES256, SHA2 256, PFS14
Re-key connection: On
Dead peer detection: On

Hier arbeitet AES im CBC-Modus und benötigt deshalb den separaten Integritätsschutz SHA2 256. DH14 und PFS14 sind eine Kompatibilitätswahl, nicht die bevorzugte moderne Variante, wenn beide Peers DH19 unterstützen.

Für neue Profile vermeiden

Für neue Designs sollten IKEv1, Aggressive Mode, DES, 3DES, Blowfish, MD5, SHA1 sowie die DH-Gruppen 1, 2 und 5 nicht mehr eingesetzt werden. PFS: None bleibt ebenfalls nur eine dokumentierte Ausnahme für Gegenstellen, die PFS nicht unterstützen.

AES-GMAC ist trotz seiner Position im Phase-2-Feld Encryption keine Verschlüsselung, sondern liefert nur Authentisierung und Integrität. Für einen normalen vertraulichen Site-to-Site-Tunnel wird daher AES-GCM oder AES mit einem passenden SHA2-Verfahren verwendet.

Legacy-Abweichungen werden mit Grund, betroffener Gegenstelle, Risiko, Owner und Ablösetermin dokumentiert. Eine schwache Kombination sollte nicht zusätzlich zu starken Proposals stehen bleiben, nur weil der Tunnel damit ebenfalls aufbaut. Als fachliche Orientierung eignen sich die BSI TR-02102-3 zu IPsec und IKEv2 sowie der NIST Guide to IPsec VPNs.

Muss eine Umgebung formale Kryptografievorgaben erfüllen, beschreibt der eigene Ablauf, wie der FIPS-140-3-Modus auf Sophos Firewall Plattformen, Profile, Zertifikate, Backup und HA beeinflusst. FIPS-Konformität ersetzt dabei nicht die bewusste Auswahl eines modernen gemeinsamen Proposals.

Profil klonen oder neu erstellen

Menüpfad:

Profiles > IPsec profiles

Für Sophos-zu-Sophos-Verbindungen dienen die gepaarten Systemprofile als nachvollziehbare Vorlage:

Branch office (IKEv2) für die initiierende Filiale
Head office (IKEv2) für die antwortende Zentrale

Das passende Profil wird geklont und eindeutig benannt, zum Beispiel Branch-Zurich-IKEv2. So bleibt das Systemprofil unverändert und der bisherige Tunnel kann bei einem Rollback wieder seinem alten Profil zugewiesen werden.

General settings

Key exchange: Für neue Site-to-Site-Verbindungen IKEv2. IKEv1 nur für eine belegte Legacy-Gegenstelle.
Authentication mode: Existiert nur bei IKEv1. Aggressive Mode wird nicht verwendet, weil Authentisierungsinformationen weniger geschützt übertragen werden.
Key negotiation tries: Sophos empfiehlt 0. Bei einer VPN-Failover-Gruppe setzt SFOS den effektiven Wert jedoch auf 3.
Re-key connection: Aktivieren, damit vor Ablauf neue Phase-1- und Phase-2-Schlüssel ausgehandelt werden. SFOS unterstützt nur zeitbasiertes Rekeying.
Use strict profile: Aktivieren, wenn die Peer-Proposals genau bekannt sind. Dann bietet SFOS nur die konfigurierten Parameter an. Bei Providerprofilen zuerst deren Vorgabe prüfen; das offizielle AWS-Beispiel verwendet die Option beispielsweise nicht.
Pass data in compressed format: Im Normalfall deaktiviert lassen. Nur aktivieren, wenn der Nutzen und die Unterstützung auf beiden Seiten belegt sind.
SHA2 with 96-bit truncation: Nur für eine dokumentierte Kompatibilitätsanforderung aktivieren, nicht als allgemeine Sicherheitsverbesserung.

Use strict profile reduziert unerwartete Fallbacks und kann bei zu grossen IKE-Proposals helfen. Es ist jedoch kein Haken, der blind in jedem Providerprofil aktiviert wird.

Phase 1

Phase 1 enthält Key life, Re-key margin, Randomize re-keying margin by, DH-Gruppe sowie bis zu drei Paare aus Encryption und Authentication.

SFOS akzeptiert für die Key Life 120 bis 86400 Sekunden, für die Re-key Margin 30 bis 999 Sekunden und für die Randomisierung 0 bis 100 Prozent. Ein formal erlaubter Wert ist nicht automatisch sinnvoll: Die Margin muss deutlich kleiner als die Key Life bleiben und zum Verhalten der Gegenstelle passen.

Nur die tatsächlich benötigten DH-Gruppen und Proposals werden eingetragen. Das bekannte Problem NC-136352 kann auftreten, wenn ein Default-IKEv2-Profil so viele DH-Gruppen anbietet, dass das IKE-Paket grösser als 1'500 Bytes wird. Verwirft eine Zwischenkomponente Fragmente, sendet der Initiator wiederholt, während der Responder nichts sieht. Bei einem bekannten Peer ist eine einzelne bestätigte DH-Gruppe die sauberste Konfiguration.

Phase 2

Phase 2 enthält PFS, Key Life sowie Encryption und Authentication für den Nutztraffic.

PFS erzwingt beim Phase-2-Rekey einen neuen DH-Schlüsselaustausch. Wird ein langfristiger Schlüssel später kompromittiert, sollen ältere aufgezeichnete Sitzungen dadurch nicht mit demselben Schlüsselmaterial entschlüsselt werden können. Deshalb wird PFS aktiviert und passend zur Gegenstelle gewählt. Bei modernen Profilen entspricht die PFS-Gruppe häufig der Phase-1-DH-Gruppe.

Die Phase-2-Key-Life wird kleiner als die Phase-1-Key-Life gewählt. Das führt dazu, dass die Schlüssel für den Nutztraffic häufiger erneuert werden als der IKE-Steuerkanal.

Dead Peer Detection

DPD erkennt eine nicht mehr antwortende Gegenstelle. Es ersetzt weder Gateway Monitoring noch einen echten Anwendungstest.

Filiale oder Initiator: Re-initiate, damit die Firewall nach einem DPD-Timeout sofort einen neuen Aufbau versucht.
Zentrale oder Responder: Disconnect, damit die veraltete Verbindung geschlossen wird. Hold ist eine bewusste Alternative, wenn die Traffic Selectors erhalten bleiben und erst bei neuem Traffic verhandelt werden sollen.
Check peer after every: Prüfintervall in Sekunden.
Wait for response up to: Wirkt nur bei IKEv1. Bei IKEv2 verwendet SFOS den internen IKE-Retransmission-Timeout; der eingetragene Wert verändert dieses Verhalten nicht.

Bei IPsec-Failover-Gruppen deaktiviert SFOS DPD für die zugeordneten Verbindungen und setzt Key negotiation tries auf 3. Dort übernimmt die Gruppenbedingung die Überwachung. Die verlinkte Anleitung erklärt Reihenfolge, Failover Condition und Automatic failback; die Profilansicht allein zeigt nicht das gesamte wirksame Failoververhalten.

Lifetimes und Rekeying richtig einordnen

Key life ist kein Session- oder Idle-Timeout. Sie begrenzt die Lebensdauer einer Security Association. Vor ihrem Ablauf startet innerhalb der Re-key Margin die Aushandlung neuer Schlüssel.

Kürzere Lifetimes erneuern Schlüssel häufiger, verursachen aber mehr Rechenaufwand und mehr Gelegenheiten für Interoperabilitäts- oder Rekey-Fehler. Längere Lifetimes reduzieren diesen Aufwand, verwenden das Schlüsselmaterial jedoch länger. Deshalb ist weder der kürzeste noch der längste erlaubte Wert automatisch die beste Wahl.

NIST nennt 86400 Sekunden für die IKE SA und 28800 Sekunden für die IPsec SA als verbreitete Orientierung. Sophos und Cloud-Provider verwenden je nach Rolle und Plattform andere Werte. Diese Zahlen sind daher kein universelles SFOS-Profil.

Sophos empfiehlt zur Vermeidung von Rekey-Kollisionen:

Die Key Life des Initiators ist kleiner als jene des Responders.
Die Phase-2-Key-Life ist auf beiden Firewalls kleiner als die Phase-1-Key-Life.
Rekeying ist auf mindestens einer Seite aktiviert und bei Drittanbietern ausdrücklich zeitbasiert.

Die Randomisierung verändert die Re-key Margin, nicht die gesamte Key Life. Bei acht Stunden Key Life, zehn Minuten Margin und 20 Prozent Randomisierung beginnt der Rekey laut Sophos zwischen 7 Stunden 48 Minuten und 7 Stunden 52 Minuten.

Für Provider werden deren exakte Werte übernommen. Das dokumentierte AWS-Beispiel verwendet auf der Sophos Firewall etwa Phase 1 28000, Re-key Margin 360, Randomisierung 50 und Phase 2 3600 Sekunden. Das ist ein AWS-Beispiel und kein allgemeiner Avanet-Default.

Profil zuweisen und sicher testen

Das neue Profil wird im Wartungsfenster zunächst nur der vorgesehenen Verbindung zugewiesen. Vorher werden Profilname, bisherige Werte und Rollback dokumentiert.

Für Site-to-Site erfolgt die Zuweisung unter:

Site-to-site VPN > IPsec

Remote-Access-IPsec verwendet ebenfalls Profile, hat aber andere Grenzen: Die aktuelle Sophos-Connect-Konfiguration akzeptiert IKEv1-Profile mit deaktiviertem DPD oder Disconnect. Das moderne Site-to-Site-IKEv2-Profil wird deshalb nicht ungeprüft für Remote Access wiederverwendet. Den vollständigen Ablauf beschreibt Sophos Connect auf Sophos Firewall konfigurieren. Der besondere OTP-/Rekey-Fall steht unter Sophos Connect trennt die Verbindung nach rund vier Stunden.

Nach dem Aufbau werden in der Advanced Shell lesend Status und letzte IKE-Meldungen geprüft:

ipsec statusall
tail -n 200 /log/strongswan.log

Danach folgt echter Traffic in beide Richtungen. Die Child-SA-Bytezähler müssen steigen. Der Test wird nach mindestens einem Phase-2-Rekey wiederholt; erst damit sind Lifetimes, PFS und Rekey-Verhalten wirklich geprüft.

Typische Zuordnung von Fehlern:

Tunnel bleibt vollständig down: IKE-Version, Phase-1-Encryption, Authentication, DH, Strict Profile, ID und Peer-Authentisierung prüfen.
NO_PROPOSAL_CHOSEN vor Phase 1: Phase-1-Proposals vergleichen.
Phase 1 steht, Child SA fehlt: Phase-2-Encryption, Authentication, PFS und Traffic Selectors prüfen.
Abbruch nach ähnlicher Laufzeit: Key Life, Re-key Margin, Randomisierung und Initiator-/Responderwerte vergleichen.
Tunnel grün, aber kein Traffic: Nicht zuerst das Profil ändern, sondern Firewall-Regeln, NAT, Routing, Rückweg und Bytezähler prüfen.

Wenn die Änderung Probleme verursacht, wird der Verbindung das dokumentierte vorherige Profil wieder zugewiesen. Dienste, Datenbanken oder Advanced-Shell-Konfigurationen müssen für einen normalen Profil-Rollback nicht verändert werden.