Globale VPN-Einstellungen auf Sophos Firewall sicher verwenden

Die Device Console von Sophos Firewall enthält unter set vpn mehrere globale Einstellungen für VPN-Failover, IPsec-Verarbeitung und die Legacy-Protokolle L2TP und PPTP. Sie wirken nicht nur auf die Verbindung, an der gerade gearbeitet wird. Ein ungezielter Test kann andere Tunnel beeinflussen, bestehende Sessions entfernen oder eine Schutzfunktion schwächen.

Kein allgemeines Performance-Rezept: ipsec-max-workqueue-items, das Anti-Replay-Fenster und use-resolved-ip-address werden nicht vorsorglich auf grössere Werte oder enable gesetzt. Sophos bezeichnet diese Optionen als Advanced-Einstellungen, die zu einer konkreten Netzwerkanforderung oder nach Vorgabe des Sophos Supports verwendet werden sollen.

Für normale Tunnelprobleme bleibt zuerst IPsec VPN Troubleshooting massgebend. Dort werden IKE, Child SA, Routing, NAT, Regeln und der echte Paketfluss geprüft. Die hier beschriebenen globalen Schalter kommen erst infrage, wenn das Fehlerbild genau zu ihrer Wirkung passt.

Ausgangszustand vor jeder Änderung sichern

Die Befehle laufen unter 4. Device Console. Vor dem Setzen werden SFOS-Version und Build, Zeitpunkt, betroffene Tunnel, erwarteter Testablauf und ein unabhängiger Managementzugang dokumentiert. Zusätzlich wird ein aktuelles Konfigurationsbackup erstellt. Die verlinkte SFOS-22-CLI-Hilfe dokumentiert für diese Werte nur set vpn, aber keinen Lesebefehl. Vorhandene Änderungsprotokolle und Backups sind lediglich ergänzende Nachweise; sie belegen nicht den derzeit aktiven Wert. Der Sophos Support muss eine Lesemethode für den installierten Build bestätigen. Deren Ausgabe und der dazu passende set vpn-Rollback-Befehl werden vorab dokumentiert. Kann der Support keine Lesemethode bestätigen oder lässt sich der aktive Wert nicht ermitteln, wird abgebrochen und die globale Einstellung nicht geändert.

Die SFOS-22-Hilfe nennt nur für L2TP-MTU, Anti-Replay, Cookie-Schwelle und die aufgelöste Peer-IP einen Default. Auch diese Defaults beweisen nicht, dass das konkrete Gerät noch unverändert konfiguriert ist.

Bei einer kundenspezifischen Konfiguration wird immer der vorab sicher ermittelte Ausgangswert wiederhergestellt. Einen universellen default-Parameter gibt es in der dokumentierten Syntax nicht. Die unten gezeigten Befehle für Standardwerte sind nur passend, wenn die Änderung ausdrücklich zum dokumentierten SFOS-22-Standardwert zurückführen soll; sie dürfen einen absichtlich abweichenden Ausgangswert nicht überschreiben.

Sessions bei Tunnel- und WAN-Wechseln

conn-remove-tunnel-up bestimmt, ob bestehende Verbindungen entfernt werden, wenn ein IPsec-Tunnel aufgebaut wird. Das kann wichtig werden, wenn ein Flow zuerst über einen anderen Pfad gestartet ist und nach dem Tunnelaufbau mit unverändertem Sessionzustand am falschen Pfad festhält. Gleichzeitig kann das Entfernen produktive Sessions unterbrechen. Die SFOS-22-Hilfe dokumentiert für diesen Schalter keinen Default; deshalb wird der vorab sicher ermittelte Wert zurückgesetzt.

set vpn conn-remove-tunnel-up enable
set vpn conn-remove-tunnel-up disable

conn-remove-on-failover steuert die globale Bereinigung beim Failover und Failback. all betrifft alle Verbindungen, non-tcp begrenzt die Bereinigung auf Nicht-TCP-Traffic wie UDP oder ICMP. Der passende Wert ist deshalb keine reine VPN-Entscheidung: VoIP, Videokonferenzen, DNS und andere UDP-Anwendungen müssen im gleichen Testfenster beobachtet werden.

set vpn conn-remove-on-failover all
set vpn conn-remove-on-failover non-tcp

Auch für conn-remove-on-failover nennt die SFOS-22-Hilfe keinen Default. Für den Rückweg wird daher je nach notiertem Ausgangswert exakt set vpn conn-remove-on-failover all oder set vpn conn-remove-on-failover non-tcp ausgeführt.

Bei HA muss die Protokollwirkung getrennt geprüft werden. Laut SFOS-22-HA-Hilfe werden route-based, policy-based und Remote-Access-IPsec-Tunnel bei einem Failover wiederhergestellt. Für Traffic im IPsec-Tunnel unterstützt das HA-Session-Failover stateless Protokolle wie UDP und ICMP, nicht jedoch stateful Protokolle wie TCP. Die beiden conn-remove-*-Schalter ersetzen deshalb weder das HA-Design noch Tests mit je einem bestehenden TCP- und UDP-Flow.

Ähnlich benannte Einstellungen korrekt abgrenzen

Nicht jede globale oder VPN-nahe Option gehört zu set vpn. Vor einem Change muss der Pfad zum Fehlerbild passen:

• IPsec-Profil: Unter System > Profiles > IPsec profiles gelten Use strict profile und Pass data in compressed format für Verbindungen mit diesem Profil. Laut Profilhilfe kann das strikte Profil Handshake-Probleme durch Paketfragmentierung vermeiden; die Kompressionsoption komprimiert den Payload vor der Verschlüsselung. Beides ist weder ein globaler Fragmentierungs- noch ein globaler Performance-Schalter.
• SSL VPN: Remote access VPN > SSL VPN > SSL VPN global settings gilt für alle Remote-Access-SSL-VPN-Policies und fliesst in die .ovpn-Datei ein. Nur dort beträgt Disconnect dead peer after laut SSL-VPN-Hilfe standardmässig 180 Sekunden bei TCP und 100 Sekunden bei UDP; bei UDP ist 60 bis 110 zulässig. Disconnect idle peer after wird in Minuten angegeben, ohne dass diese Hilfeseite einen Default nennt. Diese Werte gelten nicht pauschal für IPsec oder L2TP.
• L2TP-Weboberfläche: Remote access VPN > L2TP > L2TP global settings gilt für alle L2TP-Policies. Dort werden Aktivierung, Lease-Bereich, RADIUS-Leasing, DNS, WINS und Mitglieder festgelegt. Der dokumentierte Pool muss in einem privaten /24- oder kleineren Subnetz liegen und darf höchstens 254 Adressen enthalten. Laut Sophos dürfen sich die L2TP- und PPTP-Adressbereiche nicht mit Remote-Access-IPsec- oder SSL-VPN-Konfigurationen überschneiden. Dass sich L2TP- und PPTP-Bereiche nicht gegenseitig überschneiden dürfen, steht auf dieser Hilfeseite nicht. CLI-Authentifizierung und CLI-MTU unten bleiben L2TP-spezifisch.
• Firewall-weite Werte: set advanced-firewall tcp-est-idle-timeout, udp-timeout, udp-timeout-stream und fragmented-traffic sind keine VPN-Einstellungen. Die SFOS-22-CLI-Hilfe nennt 2700-432000 Sekunden für etablierte TCP-Sessions, je 30-3600 Sekunden für UDP und allow als Default für fragmentierten Traffic. Solche firewallweiten Werte werden nicht geändert, um einen einzelnen Tunnel zu reparieren.

IPsec-Performance und Schutzfunktionen

Die Untergruppe ipsec-performance enthält vier sehr unterschiedliche Funktionen. Der Name verleitet zu Tuningversuchen, obwohl nur eine davon direkt die Grösse einer Arbeitswarteschlange festlegt.

Workqueue nur bei nachgewiesenem Engpass ändern

ipsec-max-workqueue-items akzeptiert Werte von 1024 bis 10240. Die Warteschlange nimmt Arbeit für die IPsec-Verarbeitung auf. Ein grösserer Wert garantiert keinen höheren Durchsatz und behebt weder Packet Loss, MTU-Probleme, schwache Einzelstreams noch eine ausgelastete WAN-Verbindung.

set vpn ipsec-performance ipsec-max-workqueue-items <1024-10240>

Ein Change ist erst sinnvoll, wenn ein reproduzierbarer Lasttest, Systemauslastung und Sophos-Diagnosedaten auf genau diesen Engpass zeigen. Vorher werden MTU und MSS, Latenz, Packet Loss, Verschlüsselungsprofil, IPsec Acceleration und parallele Teststreams getrennt geprüft. Ohne Verbesserung wird der gelesene Ausgangswert wieder gesetzt.

Für ipsec-max-workqueue-items dokumentiert Sophos keinen Default. Der Rollback lautet deshalb set vpn ipsec-performance ipsec-max-workqueue-items <notierter-ausgangswert>.

Anti-Replay-Fenster ist eine Sicherheitsfunktion

IPsec merkt sich innerhalb des Replay-Fensters, welche Pakete bei der Entschlüsselung bereits gesehen wurden. Wiederholte Pakete können so als Replay erkannt und verworfen werden. SFOS 22 erlaubt 0, 32, 64, 128, 256, 512, 1024, 2048 und 4096; der dokumentierte Default ist 1024.

set vpn ipsec-performance anti-replay window-size <wert>

Ein grösseres Fenster kann bei stark umgeordneten Paketen auf parallelen Pfaden relevant sein. Es ist aber kein pauschaler Durchsatzschalter. Der Wert 0 entfernt den Anti-Replay-Schutz und wird nicht als Problemlösung empfohlen. Ein solcher Test gehört in ein isoliertes Wartungsfenster mit ausdrücklicher Sophos-Supportvorgabe und sofort vorbereitetem Rückweg.

Zum dokumentierten Default führt set vpn ipsec-performance anti-replay window-size 1024 zurück. War der Ausgangswert kundenspezifisch, wird stattdessen genau dieser Wert gesetzt.

IKEv2-Cookie-Schwelle schützt vor halboffenen SAs

Cookie-Validierung ist laut Sophos immer aktiv und steht nur für IKEv2 zur Verfügung. cookie_threshold schaltet sie nicht ein oder aus. Überschreitet die Zahl gleichzeitig halboffener IKE SAs den Schwellenwert, fordert der Responder vom Initiator ein Cookie an. Damit wird der Aufbauzustand gegen DoS-Last geschützt. Der dokumentierte Default ist 30.

set vpn ipsec-performance cookie_threshold <zahl>

Ein niedrigerer oder höherer Wert wird nur anhand realer IKE-Last und Supportdiagnose gewählt. Fehlende Child SAs, falsche Proposals oder Authentifizierungsfehler werden dadurch nicht behoben. Für die Abnahme werden neue IKEv2-Verbindungen, strongswan.log, CPU-Auslastung und legitime gleichzeitige Einwahlen beobachtet.

Zum dokumentierten Default führt set vpn ipsec-performance cookie_threshold 30 zurück; eine zuvor notierte kundenspezifische Schwelle wird mit derselben Syntax wiederhergestellt.

Aufgelöste Peer-IP nur beim dokumentierten Charon-Fall verwenden

use-resolved-ip-address ist für viele Site-to-Site-IPsec-Tunnel mit FQDN-Gegenstellen und langsamer DNS-Auflösung vorgesehen. Genau diese Kombination kann laut Sophos zu einem blockierten charon-Thread führen. Bei enable verwendet die Firewall die bereits aufgelöste IP-Adresse statt erneut mit dem Remote-FQDN den Tunnelaufbau zu starten.

set vpn ipsec-performance use-resolved-ip-address enable
set vpn ipsec-performance use-resolved-ip-address disable

Der FQDN muss bereits erfolgreich aufgelöst worden sein. Der dokumentierte Default ist Off; set vpn ipsec-performance use-resolved-ip-address disable stellt ihn wieder her. War enable der notierte Ausgangswert, ist dies stattdessen der kundenspezifische Rollback. Die Option ist kein Ersatz für funktionierendes DNS oder erreichbare Resolver. Vor dem Einschalten werden Auflösungszeit, aufgelöste Peer-IP, Tunnelanzahl und charon.log korreliert. Nach einer DNS- oder Providerumschaltung muss geprüft werden, ob die Firewall die neue Peer-IP im erwarteten Zeitraum verwendet.

L2TP-Kompatibilität, MTU und PPTP

set vpn enthält ausserdem Authentifizierungsprotokolle für L2TP und PPTP sowie die globale L2TP-MTU. Das macht PPTP nicht zu einer sinnvollen Option für neue Umgebungen. PPTP gilt als veraltet und sollte nicht neu eingeführt werden. Auch L2TP Remote Access bleibt eine kontrollierte Kompatibilitätslösung, nicht der bevorzugte Standard für neue verwaltete Clients.

Für L2TP und PPTP stehen ANY, CHAP, MS_CHAPv2 und PAP zur Verfügung:

set vpn l2tp authentication <ANY|CHAP|MS_CHAPv2|PAP>
set vpn pptp authentication <ANY|CHAP|MS_CHAPv2|PAP>

Der Wert wird nicht allein nach dem stärksten Namen gewählt. Client, Authentifizierungsserver und die unter Authentication > Services konfigurierte VPN-Methode müssen dasselbe Protokoll unterstützen. Besonders bei Active Directory kann die tatsächlich unterstützte Kombination vom RADIUS-Pfad abweichen. ANY ist kein Sicherheitsupgrade, sondern erweitert die akzeptierten Verfahren und benötigt deshalb eine bewusste Risikoentscheidung.

Sophos dokumentiert keinen Default für diese beiden CLI-Werte. Der Rollback verwendet daher mit derselben Syntax den vorab notierten Token, beispielsweise set vpn l2tp authentication MS_CHAPv2, wenn genau dies der Ausgangswert war.

Für L2TP lässt sich die MTU von 576 bis 1460 setzen; der dokumentierte Default beträgt 1410:

set vpn l2tp mtu <576-1460>

Die L2TP-MTU verändert keine route-based oder policy-based Site-to-Site-IPsec-Schnittstelle. Sie wird nur bei einem reproduzierbaren L2TP-Fragmentierungsproblem schrittweise verändert. Danach müssen grosse und kleine Transfers, DNS, Authentifizierung und Neuverbindung erneut funktionieren.

set vpn l2tp mtu 1410 führt zum dokumentierten Default zurück. Bei einer absichtlich angepassten Ausgangs-MTU wird stattdessen dieser notierte Wert gesetzt.

Kontrolliert testen und zurückrollen

Zu den vier ausdrücklich dokumentierten SFOS-22-Defaults führen diese Befehle zurück:

set vpn ipsec-performance anti-replay window-size 1024
set vpn ipsec-performance cookie_threshold 30
set vpn ipsec-performance use-resolved-ip-address disable
set vpn l2tp mtu 1410

Für conn-remove-*, ipsec-max-workqueue-items und die beiden Authentifizierungswerte nennt Sophos keinen Default. Eine kundenspezifische Konfiguration wird immer mit dem vor dem Test notierten Wert und derselben set vpn-Syntax wiederhergestellt.

Pro Wartungsfenster wird genau ein globaler Wert verändert. Vor und nach dem Change werden dieselben Tunnel, derselbe Testflow und dieselbe WAN- beziehungsweise HA-Umschaltung verwendet. Bei IPsec zählen Current activities > IPsec connections, Child SA, Byte-Zähler, CPU und Packet Loss; Remote-Access-SSL-VPN-Benutzer erscheinen unter Current activities > Remote users. Die offizielle Logübersicht ordnet IPsec strongswan.log, ipsec_monitor.log und charon.log, SSL VPN sslvpn.log und L2TP l2tpd.log zu. Bei Sessionbereinigung kommen VoIP-, DNS- und andere UDP-Flows hinzu.

Ein erfolgreicher Ping ist keine vollständige Abnahme. Mindestens eine bestehende Verbindung, eine neue Verbindung, beide Datenrichtungen und ein kontrollierter Negativtest werden geprüft. Unter Diagnostics > Packet capture zeigt SFOS unter anderem Ein- und Ausgangsschnittstelle, Regel-ID, Status und Verwerfungsgrund; ein enger Filter auf die anonymisierten Testendpunkte verhindert die Erfassung unnötiger Fremddaten. Nach der Änderung wird der Zielwert mit der vom Support bestätigten Lesemethode geprüft. Ein akzeptierter Befehl und der beobachtete Datenverkehr allein beweisen nicht, welcher globale Wert aktiv ist.

Bleibt die erwartete Verbesserung aus oder entstehen neue Unterbrüche, wird exakt der vor dem Test notierte Wert gesetzt. Anschliessend werden Tunnelstatus und Nutztraffic erneut geprüft. Ohne bekannten Ausgangswert, unabhängigen Managementzugang oder belastbares Fehlerbild wird kein set vpn-Change durchgeführt.

FAQ