Fallstudie 01 — VPN & Routing
Das VPN, das zufällig ausfiel — und niemand wusste warum
Zufällige Verbindungsabbrüche, keine klaren Logs, Hersteller-Support fand keinen Fehler. Die eigentliche Ursache waren drei separate Faktoren, die erst in Kombination kritisch wurden.
Ausgangslage
VPN vorhanden, moderne Firewall, keine offensichtlichen Fehler. Dennoch wurden Benutzer ständig und ohne erkennbares Muster getrennt. Die Logs zeigten keinen eindeutigen Fehler. Der Hersteller-Support fand nichts. Das Problem bestand über Wochen hinweg fort.
Der Kunde hatte gezielt in aktuelle Firewall-Hardware investiert, um die VPN-Stabilität zu verbessern. Die Verbindungsabbrüche traten dennoch weiterhin auf. Die wachsende Frustration — bei den Endbenutzern und der internen IT — erzeugte Druck, Hardware auszutauschen, die möglicherweise gar nicht das Problem war.
Was tatsächlich geschah
Die Untersuchung ergab drei separate Probleme, die gleichzeitig auftraten. Jedes für sich war beherrschbar. Zusammen erzeugten sie ein Ausfallmuster, das von außen zufällig wirkte, aber strukturell deterministisch war.
- Asymmetrisches Routing — inkonsistente Verkehrspfade abhängig von Last und Zeitpunkt bedeuteten, dass Rückpakete andere Wege nahmen als ausgehende Pakete
- MTU-Diskrepanzen verursachten stille Paketfragmentierung mitten in einer Sitzung — Pakete wurden still verworfen statt korrekt fragmentiert
- Firewall-Sitzungstabellen brachen unter bestimmten Verkehrsbedingungen zusammen — die Stateful Inspection verlor bei Last den Überblick über etablierte Sitzungen
- Jeder Faktor für sich harmlos — zusammen erzeugten sie systemische Instabilität, die von außen zufällig wirkte
Das Problem mit dem asymmetrischen Routing war besonders subtil. Bei niedriger Last folgten Pakete typischerweise konsistenten Pfaden. Bei höherer Last verschoben sich Routing-Entscheidungen — und die Firewall, ausgelegt auf Stateful Inspection, verlor den Überblick über etablierte Sitzungen, wenn der Rückverkehr an einem unerwarteten Interface ankam.
Warum Standard-Diagnosen es nicht erkannten
Jede einzelne Komponente bestand ihre eigene Diagnose. Die Firewall meldete gesunde Sitzungstabellen. Das Routing sah von jedem Punkt der Topologie korrekt aus. MTU-Probleme waren in der durchschnittlichen Paketanalyse nicht sichtbar, da die Fragmentierung still erfolgte — Pakete wurden verworfen, ohne offensichtliche Fehler zu erzeugen.
Was FM-NetSec Nordic unternahm
- Routing-Logik neu aufgebaut, um deterministische Verkehrspfade zu erzwingen — und damit die Bedingungen zu beseitigen, unter denen asymmetrisches Routing auftreten konnte
- MTU- und MSS-Behandlung über alle relevanten Schnittstellen hinweg korrigiert — korrekte Fragmentierung statt stiller Verwerfung sichergestellt
- Firewall-Sitzungsverhalten unter variierenden Lastbedingungen stabilisiert — Sitzungstabellenparameter an die tatsächlichen Verkehrsmuster angepasst
Ergebnis
- Keine zufälligen Verbindungsabbrüche mehr nach der Behebung
- VPN-bezogene Support-Tickets drastisch reduziert
- Vorhersehbare, stabile Konnektivität über alle Standorte hinweg
„Wenn Ihr VPN 'zufällig ausfällt', liegt das fast nie am VPN."
Die Hardware war nicht das Problem. Die VPN-Software war nicht das Problem. Das Problem lag in der umgebenden Infrastruktur — in den Routing-Entscheidungen, der MTU-Konfiguration und dem Stateful-Firewall-Verhalten unter realer Last. Ein Hardware-Tausch hätte nichts verändert.
Fragen zu diesem Fall
Was verursachte die VPN-Verbindungsabbrüche?
Drei gleichzeitige Probleme: Asymmetrisches Routing, das sich unter Last verschob, eine MTU/MSS-Fehlanpassung, die stille Paketverluste verursachte, und das Verhalten der Stateful-Firewall, die Sessions verlor, wenn Return-Traffic auf einem unerwarteten Interface ankam. Jedes Problem war einzeln handhabbar – zusammen erzeugten sie Ausfälle, die zufällig wirkten.
Warum haben Standarddiagnosen das Problem nicht gefunden?
Jede Komponente bestand ihre eigene Diagnose isoliert. Die Firewall meldete gesunde Session-Tabellen. Das Routing sah von jedem einzelnen Punkt korrekt aus. MTU-Probleme waren in der durchschnittlichen Paketanalyse nicht sichtbar. Das Fehlermuster wurde erst durch gleichzeitige Analyse über mehrere Schichten unter realen Traffic-Bedingungen sichtbar.
Hätte ein Hardware-Austausch das Problem gelöst?
Nein – und es hätte nichts verändert. Die Hardware funktionierte wie konzipiert. Das Problem lag in der umgebenden Infrastruktur: Routing-Logik, MTU-Konfiguration und Firewall-Session-Tracking unter asymmetrischen Traffic-Pfaden.
Was lässt sich aus diesem Fall lernen?
Mehrfaktorprobleme zeigen sich selten bei Standarddiagnosen. Der richtige Ansatz ist die methodische Analyse über alle relevanten Schichten gleichzeitig – nicht die sequenzielle Eliminierung einzelner Komponenten, die jeweils isoliert gesund erscheinen.
