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 mit denen der Gegenstelle überein, wird der Tunnel nicht aufgebaut oder fällt erst bei einem 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 der Gruppe 19 (ecp256) für DH und PFS ein moderner Avanet-Ausgangspunkt. Das ist weder ein Sophos-Default noch eine allgemeine Herstellervorgabe; die Anforderungen der Gegenstelle haben 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. Vor jeder Änderung prüft man deshalb, welchen Verbindungen das Profil zugewiesen ist. Statt ein gemeinsam genutztes System- oder Produktionsprofil direkt zu ändern, wird es geklont und zunächst nur mit der vorgesehenen Verbindung getestet.

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 SAs, also die 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. Protokollbedingt kann sich ein PFS- oder Rekey-Problem je nach Gegenstelle erst zeigen, wenn die Child SA mit CREATE_CHILD_SA erneuert wird. Avanet empfiehlt deshalb, bei der Abnahme mindestens einen Phase-2-Rekey zu beobachten.

Parameter mit der Gegenstelle abstimmen

Vor der Konfiguration stimmt man die Werte schriftlich mit der Administration der Gegenstelle ab. 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 Einschränkungen des Providers 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. Nicht benötigte Proposals erschweren die Abstimmung und können IKE-Pakete unnötig vergrössern. Die konkrete SFOS-Auswirkung des bekannten Problems NC-136352 folgt bei den Phase-1-Feldern.

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. Sie zeigen bewusst nur die Proposal- und Funktionsauswahl, kein vollständiges Profil: Lifetimes, Re-key Margin, DPD-Intervall und DPD-Aktion richten sich nach der Gegenstelle und der Rolle als Initiator oder Responder.

Modernes Profil für kontrollierte Gegenstellen

Wenn beide Seiten aktuelle Verfahren unterstützen:

Key exchange: IKEv2
Phase 1: AES256GCM16, 19 (ecp256)
Phase 2: AES256GCM16, 19 (ecp256)
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 in SFOS kein zusätzlicher Authentication-Algorithmus wie SHA2 ausgewählt.

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.

Die Gruppe 19 (ecp256) verwendet eine elliptische Kurve. Avanet bevorzugt sie für kontrollierte aktuelle Gegenstellen gegenüber den älteren MODP-Gruppen. AES128GCM16 ist ebenfalls ein aktuelles Verfahren. Welche Kombination zulässig ist, richtet sich nach der Kryptovorgabe und der schwächsten Komponente des Profils.

Kompatibilitätsprofil ohne AES-GCM oder ECP-Gruppe

Unterstützt die Gegenstelle AES-GCM nicht oder unterstützt sie keine ECP-Gruppe, verwendet Avanet diese häufiger unterstützte Kombination als Kompatibilitätsausgangspunkt:

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

Im Gegensatz zu den AES-GCM-Einträgen wird bei AES256 in SFOS der separate Authentication-Algorithmus SHA2 256 konfiguriert. DH14 und PFS14 sind eine Avanet-Kompatibilitätswahl, nicht die bevorzugte moderne Variante, wenn beide Gegenstellen die Gruppe 19 (ecp256) unterstützen.

Für neue Profile vermeiden

DES wird in SFOS 22 nicht als unterstützter IPsec-Algorithmus aufgeführt. IKEv1, Aggressive Mode, 3DES, Blowfish, MD5, SHA1 sowie die DH-Gruppen 1, 2 und 5 sind zwar weiterhin auswählbar, sollten für neue Profile jedoch nicht 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.

Die dokumentierte Auswahl in SFOS 22 und 23 hängt von IKE-Version und Phase ab:

• AES128GCM16, AES192GCM16 und AES256GCM16: in IKEv2 Phase 1 sowie in Phase 2 beider IKE-Versionen, nicht in IKEv1 Phase 1.
• AES128GMAC, AES192GMAC und AES256GMAC: nur in Phase 2 beider IKE-Versionen, nicht in Phase 1.
• TwoFish und Serpent: in Phase 1 und Phase 2 von IKEv1, nicht von IKEv2.

Dies sind auswählbare Algorithmen, keine fest an bestimmte DH-Gruppen oder Hashverfahren gebundenen Kombinationen und keine Empfehlung für neue Profile.

Legacy-Abweichungen werden mit Grund, betroffener Gegenstelle, Risiko, verantwortlicher Person 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 bei einem Rollback lässt sich der Verbindung ihr bisheriges Profil wieder zuweisen.

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 laut Sophos im Klartext übertragen werden.
• Key negotiation tries: Das Feld bestimmt die Anzahl der Versuche, den Schlüsselaustausch für den Tunnel auszuhandeln, bevor die Firewall aufhört. 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. Wird die Option deaktiviert, startet die lokale Firewall keinen Rekey, kann aber weiterhin auf Rekey-Anfragen der Gegenstelle antworten. Die Gegenstelle muss dann die Erneuerung initiieren; Rekeying bleibt auf mindestens einer Seite aktiviert.
• 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: Avanet lässt die Option im Normalfall deaktiviert. Man aktiviert sie nur, wenn die Gegenstelle IPComp unterstützt und der geringere Bandbreitenbedarf den zusätzlichen Komplexitätsfaktor rechtfertigt.
• SHA2 with 96-bit truncation: Avanet aktiviert die verkürzten HMAC-Werte nur für eine dokumentierte Kompatibilitätsanforderung, nicht als allgemeine Sicherheitsverbesserung.

Use strict profile schliesst nicht konfigurierte System-Defaultwerte vom IKE-Austausch aus 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. Key life und Re-key margin werden hier in Sekunden eingegeben. Im Aggressive Mode lässt sich pro Phase nur eine Encryption/Authentication-Kombination speichern; die Warnung vor diesem Modus gilt weiterhin.

Hier übernimmt man nicht einfach den grössten Wert, den das Eingabefeld akzeptiert. Die Re-key Margin muss deutlich kleiner als die Key Life bleiben und zum Verhalten der Gegenstelle passen; die Randomisierung verändert nur diese Margin.

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 einer bekannten Gegenstelle ist eine einzelne bestätigte DH-Gruppe die eindeutigste und robusteste Konfiguration.

Phase 2

Phase 2 enthält PFS, Key Life sowie Encryption und Authentication für den Nutztraffic. Auch hier sind bis zu drei Encryption/Authentication-Kombinationen möglich. Die eigene Phase-2-Key life wird in Sekunden eingegeben. Die in Phase 1 konfigurierten Rekey-Einstellungen, einschliesslich Margin und Randomisierung, steuern auch das Phase-2-Rekey-Timing; Phase 2 behält jedoch ihre eigene Key Life.

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.

Bei Use PFS group übernimmt Same as phase 1 die in Phase 1 gewählten DH-Gruppen für die Phase-2-Aushandlung. Eine explizite Gruppe legt dagegen die Phase-2-DH-Gruppe direkt fest; None deaktiviert PFS. Die Übernahme derselben Gruppen bedeutet nicht, dass PFS einen anderen numerischen Gruppenwert benötigt.

Sophos empfiehlt, die Phase-2-Key-Life kleiner als die Phase-1-Key-Life zu wählen. 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. Wenn der Phase-2-Tunnel inaktiv war, prüft DPD die Erreichbarkeit der Gegenstelle, bevor Daten gesendet werden.

• Filiale oder Initiator: Re-initiate, damit die Firewall nach einem DPD-Timeout sofort einen neuen Aufbau versucht. Die Anzahl der Versuche für Re-initiate richtet sich nach Key negotiation tries.
• 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 IKEv1 hängt die Anzahl der Prüfungen von der hier eingestellten Antwortzeit ab.

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 SP 800-77r1 empfiehlt 24 Stunden für die IKE SA und 8 Stunden für die IPsec SA. Dies sind herstellerunabhängige NIST-Empfehlungen und keine SFOS-Standardwerte. Sophos und Cloud-Provider verwenden je nach Rolle und Plattform andere Werte.

Sophos empfiehlt zur Vermeidung von Rekey-Kollisionen:

1. Die Key Life des Initiators ist kleiner als jene des Responders.
2. Die Phase-2-Key-Life ist auf beiden Firewalls kleiner als die Phase-1-Key-Life.
3. 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 für Phase 1 eine Key Life von 28000, eine Re-key Margin von 360 und eine Randomisierung von 50 Prozent; für Phase 2 gelten 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.

Profile gelten auch unter Remote access VPN > L2TP. L2TP verwendet Preshared Key oder digitales Zertifikat und unterstützt kein IKEv2. Der moderne Site-to-Site-Ausgangspunkt lässt sich deshalb nicht auf L2TP übertragen.

Nach dem Aufbau verwendet Avanet in der Advanced Shell nur lesende Befehle, um Status und letzte IKE-Meldungen zu prüfen:

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 dieser zusätzliche Avanet-Abnahmeschritt prüft auch Lifetimes, PFS und Rekey-Verhalten.

Typische Zuordnung von Fehlern:

• Tunnel wird gar nicht aufgebaut: 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. Für diesen Rollback sind keine Änderungen in der Advanced Shell erforderlich.