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 Testflow und ein unabhängiger Managementzugang dokumentiert. Die vorhandenen Werte lassen sich getrennt abfragen:

show vpn conn-remove-on-failover
show vpn conn-remove-tunnel-up
show vpn ipsec-performance
show vpn configuration

show vpn ipsec-performance zeigt unter anderem die Workqueue- und Replay-Werte. show vpn configuration ist für die aktuelle L2TP-/PPTP-Konfiguration relevant. Falls ein Wert in der Ausgabe des eingesetzten Builds nicht erscheint, wird er nicht aus einem vermuteten Default abgeleitet. Dann gehören Konfigurationsbackup und Sophos Support in den Change, bevor eine globale Advanced-Einstellung verändert wird.

Der Rückweg besteht immer aus dem tatsächlich gelesenen Ausgangswert. default ist für diese VPN-Befehle kein allgemein dokumentierter Rollback und wird deshalb nicht auf Verdacht verwendet.

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. Neue Konfigurationen verwenden seit SFOS 19.0 standardmässig disable; migrierte Systeme können einen älteren Wert behalten.

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

Sophos änderte diese Defaults in SFOS 19.0 für neue Konfigurationen, um Flapping von Nicht-TCP-Verbindungen beim Auf- und Abbau von IPsec-Tunneln zu reduzieren. Die Änderung wurde bei Upgrades und Migrationen bewusst nicht pauschal übernommen. Für SFOS 22 zählt deshalb die aktuelle Geräteausgabe, nicht der angenommene Auslieferungswert.

Bei HA ist zusätzlich zu beachten, dass Sophos Firewall VPN- und Nicht-TCP-Sessions nicht als normale weitergeleitete TCP-Sessions auf den Peer übernimmt. Die beiden conn-remove-*-Schalter ersetzen weder das HA-Design noch einen kontrollierten Failovertest.

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.

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.

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 Schwellwert, 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.

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. Die Option ist daher kein Ersatz für funktionierendes DNS, sinnvolle TTLs oder erreichbare Resolver. Vor dem Einschalten werden Auflösungszeit, aktuelle A-/AAAA-Antwort, 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. Ohne den beschriebenen Charon-Fall bleibt die Einstellung deaktiviert.

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.

Die aktuelle Konfiguration wird zuerst mit show vpn configuration gelesen. 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.

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.

Kontrolliert testen und zurückrollen

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 Tunnelstatus, Child SA, Byte-Zähler, strongswan.log, charon.log, CPU und Packet Loss; bei Sessionbereinigung kommen VoIP-, DNS- und andere UDP-Flows hinzu.

Ein erfolgreicher Ping ist keine vollständige Abnahme. Mindestens ein bestehender Flow, eine neue Verbindung, beide Traffic-Richtungen und ein kontrollierter Negativtest werden geprüft. Danach wird der Zielzustand erneut mit dem passenden show vpn ...-Befehl gelesen.

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

Sollte ipsec-max-workqueue-items für mehr VPN-Durchsatz auf 10240 gesetzt werden?

Nein. Der Maximalwert ist keine Best Practice. Ein grösserer Queue-Wert kann Last nur anders puffern und behebt viele häufige Durchsatzursachen nicht. Zuerst werden Latenz, Packet Loss, MTU/MSS, Einzel- gegen Mehrfachstreams, CPU, Profil und Acceleration gemessen. Die Workqueue wird nur bei passender Diagnose und mit Rollback geändert.

Kann Anti-Replay deaktiviert werden, wenn Pakete ausser Reihenfolge eintreffen?

SFOS akzeptiert zwar die Fenstergrösse 0, damit geht aber der Anti-Replay-Schutz verloren. Zuerst werden Paketumordnung, parallele Pfade und der benötigte Fensterwert nachgewiesen. Eine Deaktivierung ist kein normaler Troubleshooting-Schritt und gehört nur in einen isolierten Supporttest.

Hilft use-resolved-ip-address bei jedem FQDN-basierten IPsec-Tunnel?

Nein. Sophos grenzt die Option auf viele Site-to-Site-Tunnel mit langsamer DNS-Auflösung und möglichem charon-Thread-Lock ein. Der FQDN muss bereits aufgelöst sein. Für einzelne stabile Tunnel oder als Ersatz für fehlerhaftes DNS bleibt der Schalter aus.