Ein VPN-Abbruch nach ziemlich genau 60 Minuten spricht eher für einen festen Zeitgeber als für schwaches WLAN oder eine zufällige Leitungsstörung. Prüfe zuerst im VPN-Protokoll, ob nach 3.600 Sekunden eine Sitzungslaufzeit, eine IKE-/IPsec-Neuaushandlung oder ein Leerlauf-Timeout abläuft. Tritt die Trennung auch über LAN auf, liegt die Ursache wahrscheinlich in der VPN-, Router-, Firewall- oder Serverkonfiguration. Ändere nicht mehrere Zeitwerte gleichzeitig und setze den Router nicht vorschnell zurück.
Keepalive-Pakete helfen vor allem dann, wenn eine Firewall oder NAT-Zuordnung eine vermeintlich inaktive Verbindung entfernt. Scheitert dagegen regelmäßig die Erneuerung von Schlüsseln oder Sicherheitszuordnungen, muss die Aushandlung zwischen VPN-Client und Gegenstelle untersucht werden. Ein höherer Timeout kaschiert diesen Fehler lediglich.
Warum die exakten 60 Minuten ein wichtiger Hinweis sind
Zufällige Funkstörungen, kurze Unterbrechungen des Internetanschlusses und überlastete Geräte halten sich normalerweise nicht an einen minutengenauen Rhythmus. Wiederholt sich der Ausfall nach derselben Laufzeit, ist häufig einer dieser Zeitgeber beteiligt:
- Die VPN-Gegenstelle begrenzt die maximale Sitzungsdauer.
- Eine inaktive Sitzung wird nach einem Idle-Timeout beendet.
- Eine Firewall oder ein Router löscht eine NAT-Zuordnung nach einer festen Frist.
- Bei IPsec läuft eine Security Association ab und die Neuaushandlung scheitert.
- Der VPN-Client erkennt wegen ausbleibender Antworten eine tote Gegenstelle.
- Ein übergeordnetes Anmelde- oder Zugriffssystem verlangt nach einer Stunde eine erneute Authentifizierung.
Entscheidend ist die Unterscheidung zwischen Leerlauf und Gesamtlaufzeit. Bricht das VPN nur ab, wenn längere Zeit keine Daten übertragen werden, passt das zu einem Idle- oder NAT-Timeout. Endet die Verbindung auch während eines Downloads, einer aktiven Remotesitzung oder fortlaufender Datenübertragung nach 60 Minuten, sind Sitzungsgrenze, Rekey oder erneute Anmeldung wahrscheinlicher.
Mit drei Gegenproben die Fehlerklasse bestimmen
- Miss die Laufzeit. Verbinde das VPN neu und notiere Start sowie Abbruch. Wiederhole den Versuch mindestens zweimal. Liegt die Abweichung nur bei wenigen Sekunden, spricht das deutlich für einen Timer.
- Erzeuge während eines Versuchs regelmäßig Datenverkehr. Nutze dafür eine erlaubte Verbindung zu einem internen Ziel oder eine gewöhnliche Anwendung über den Tunnel. Bleibt das VPN dadurch bestehen, sind Idle-Timeout oder eine ablaufende NAT-Zuordnung naheliegend. Bricht es trotzdem ab, suche bei maximaler Sitzungsdauer, Rekey oder Authentifizierung weiter.
- Teste einmal über LAN und, falls möglich, über einen anderen Internetzugang. Scheitert nur WLAN, untersuche die Funkverbindung. Scheitert dasselbe VPN über verschiedene Zugänge nach derselben Laufzeit, rücken Client und VPN-Server in den Mittelpunkt. Tritt es nur an einem Router auf, sind dessen NAT-, Firewall- oder VPN-Einstellungen verdächtig.
Beobachte gleichzeitig, ob der gesamte Internetzugang ausfällt. Bleiben normale Webseiten erreichbar und nur interne VPN-Ziele verschwinden, ist der WAN-Anschluss wahrscheinlich nicht die Ursache. Verliert der Router zur gleichen Sekunde seine Internetverbindung, muss zuerst die Anschluss- oder Einwahlseite untersucht werden.
Protokolle vor jeder Änderung auswerten
Die aussagekräftigsten Einträge stehen unmittelbar vor und nach der Trennung. Öffne die Status- oder Diagnoseansicht des VPN-Clients, des Routers und – sofern du sie verwaltest – der VPN-Gegenstelle. Suche nicht nur nach dem Wort Fehler, sondern auch nach Hinweisen auf Ablauf, Neuaushandlung und fehlende Antworten.
Hilfreiche Suchbegriffe sind je nach VPN-Technik etwa:
- timeout, idle, session expired oder maximum session
- rekey, reauth, renegotiation oder lifetime
- dead peer, DPD, peer not responding oder keepalive
- authentication failed, token expired oder login required
- delete SA, proposal mismatch oder negotiation failed
- network changed, interface down oder route removed
Die genaue Formulierung hängt von Software, Router und Protokoll ab. Notiere Zeitstempel, Verbindungsdauer, Fehlerphase und die letzten Meldungen. Ein Eintrag wie abgelaufene Sitzung weist in eine andere Richtung als eine fehlgeschlagene Schlüsselerneuerung.
Timeout und Keepalive richtig auseinanderhalten
Ein Timeout legt fest, wie lange ein Gerät auf Aktivität, eine Antwort oder das Ende einer Phase wartet. Ein Keepalive erzeugt oder erwartet dagegen in regelmäßigen Abständen ein Lebenszeichen. Beide Einstellungen hängen zusammen, erfüllen aber nicht dieselbe Aufgabe.
Idle-Timeout
Der Idle-Timeout beendet eine VPN-Sitzung nach einer Phase ohne erkannten Nutzdatenverkehr. Ein Keepalive kann diese Inaktivität je nach System verhindern. Manche VPN-Gateways unterscheiden jedoch zwischen technischen Lebenszeichen und echtem Nutzdatenverkehr. In diesem Fall hält ein Keepalive zwar die NAT-Zuordnung offen, setzt aber den serverseitigen Idle-Zähler nicht zurück.
Keepalive-Intervall und Ausfallgrenze
Bei manchen VPN-Clients gibt es zwei Werte: ein Intervall für Prüfpakete und eine Frist, nach der die Verbindung ohne Antwort als ausgefallen gilt. Das Intervall muss kürzer sein als der NAT- oder Firewall-Timeout auf dem Übertragungsweg. Ein extrem kurzes Intervall erzeugt unnötigen Verkehr und kann bei mobilen Geräten den Energieverbrauch erhöhen.
Maximale Sitzungsdauer
Eine maximale Sitzungsdauer ist eine bewusste Begrenzung. Sie lässt sich nicht zuverlässig mit Keepalive umgehen. Wird eine erneute Anmeldung verlangt, muss der Client diese unterstützen oder der zuständige Administrator die Richtlinie prüfen. Eine Sicherheitsvorgabe sollte nicht allein zur Beseitigung einer Unterbrechung aufgehoben werden.
IPsec: Rekey nach 3.600 Sekunden besonders genau prüfen
Bei IPsec werden Sicherheitsparameter und Schlüssel nicht unbegrenzt verwendet. Nach einer festgelegten Lebensdauer erfolgt normalerweise eine Erneuerung, ohne dass der Tunnel merklich ausfällt. Ein Abbruch nahe 3.600 Sekunden kann deshalb auf eine fehlgeschlagene Neuaushandlung hinweisen.
Prüfe in den Protokollen, ob unmittelbar vor dem Ausfall ein Rekey oder eine erneute IKE-Authentifizierung beginnt. Häufige Fehlerklassen sind nicht übereinstimmende Vorschläge, eine nicht erreichbare Gegenstelle, geänderte öffentliche Adressen oder Probleme bei der erneuten Authentifizierung. Die Lebensdauer allein ist nicht automatisch falsch.
Gehe bei einer selbst verwalteten IPsec-Verbindung in dieser Reihenfolge vor:
- Vergleiche die Zeitstempel von Verbindungsaufbau, Rekey-Versuch und Trennung.
- Prüfe, ob beide Seiten kompatible Verschlüsselungs-, Integritäts- und Schlüsselaustauschparameter anbieten.
- Kontrolliere, ob die erneute Aushandlung durch Firewallregeln oder NAT behindert wird.
- Stelle sicher, dass Zertifikate, Identitäten und Anmeldedaten bei der Erneuerung weiterhin gültig sind.
- Ändere Lebensdauern nur abgestimmt auf beiden Seiten und dokumentiere den Ausgangswert.
Unterschiedliche Laufzeiten müssen nicht in jeder Implementierung zwangsläufig zum Abbruch führen, weil die beteiligten Systeme normalerweise eine Erneuerung aushandeln. Scheitert dieser Vorgang, ist das Protokoll der bessere Ansatzpunkt als das bloße Verlängern auf einen sehr hohen Wert.
OpenVPN und andere sitzungsorientierte VPNs
Bei OpenVPN können Lebenszeichen erkennen, ob die Gegenstelle noch erreichbar ist, und bei ausbleibenden Antworten einen Neustart der Verbindung auslösen. Zusätzlich kann eine zeitgesteuerte TLS-Neuaushandlung stattfinden. Zeigt das Protokoll nach einer Stunde einen TLS-, Zertifikats- oder Authentifizierungsfehler, löst ein häufigeres Keepalive den Kern des Problems nicht.
Suche in der Client-Konfiguration oder Verwaltungsoberfläche nach Bezeichnungen wie Keepalive, Ping-Intervall, Ping-Restart, Renegotiation, Session Timeout oder Inactivity Timeout. Die Namen und zulässigen Werte unterscheiden sich. Bei einem bereitgestellten Firmenprofil solltest du keine Direktiven eigenmächtig überschreiben, weil serverseitige Vorgaben und Sicherheitsrichtlinien Vorrang haben können.
Trennt der Tunnel ausschließlich im Leerlauf, aktiviere eine vom Betreiber vorgesehene Keepalive-Funktion oder passe deren Intervall an die Infrastruktur an. Erfolgt der Ausfall auch unter Last, untersuche die Neuaushandlung und die Gültigkeit der Anmeldung.
WireGuard: Keepalive dient vor allem der NAT-Erreichbarkeit
WireGuard benötigt im Leerlauf nicht zwingend fortlaufenden Datenverkehr. Hinter NAT kann eine Zuordnung jedoch verschwinden, sodass eine von außen kommende Gegenstelle den Peer vorübergehend nicht erreicht. Ein dauerhaftes Keepalive kann für den Peer hinter NAT sinnvoll sein, wenn eingehende Erreichbarkeit während längerer Ruhephasen gebraucht wird.
Bei einer Trennung exakt nach einer Stunde sollte dennoch geprüft werden, was tatsächlich ausfällt. WireGuard arbeitet verbindungslos; manche Oberflächen stellen einen Tunnel bereits dann als inaktiv dar, wenn längere Zeit kein erfolgreicher Handshake oder Datenverkehr beobachtet wurde. Prüfe daher:
- Steigt der Zähler für gesendete Daten, während empfangene Daten stehen bleiben?
- Wird nach ausgehendem Datenverkehr wieder ein Handshake aufgebaut?
- Verschwindet nur eine Route oder wird die gesamte Schnittstelle deaktiviert?
- Beendet eine übergeordnete App, Firewall oder Zugriffsplattform die Sitzung?
Ein Keepalive löst keine falschen Schlüssel, unpassenden Routen oder abgelaufenen Zugang einer zusätzlichen Anmeldeplattform. Es ist hier gezielt ein Mittel gegen geschlossene NAT-Zuordnungen, kein allgemeines Reparaturwerkzeug.
Wo die passenden Einstellungen zu finden sind
Menünamen sind hersteller- und softwareabhängig. Suche in der jeweiligen Oberfläche anhand der Funktion, statt Anleitungen für ein anderes Gerät zu übertragen.
- VPN-Client: Verbindungsprofil, erweiterte Optionen, Transport, Verbindungserhaltung, Neuverbindung oder Protokollierung.
- Router mit VPN-Client: VPN, Fernzugang, Netzwerktunnel, Verbindungsdetails oder erweiterte Profileinstellungen.
- VPN-Server: Benutzer- oder Gruppenrichtlinie, Sitzungsverwaltung, Idle-Timeout, maximale Sitzungsdauer, Rekey oder Authentifizierung.
- Firewall: Sitzungs-, UDP-, TCP- oder NAT-Timeouts. Globale Änderungen können viele Anwendungen betreffen und sollten nur mit bekanntem Ausgangswert erfolgen.
- Betriebssystem: Netzwerk- und VPN-Einstellungen, Eigenschaften des Profils, Ereignisanzeige, Systemprotokoll oder Diagnosebericht.
Bei einem verwalteten Firmen-VPN liegen wichtige Werte häufig ausschließlich auf der Gegenstelle. Dann sind Startzeit, exakte Abbruchzeit, verwendeter Internetzugang und ein bereinigter Protokollauszug die nützlichsten Angaben für den Administrator. Entferne vor der Weitergabe private Schlüssel, Kennwörter, vollständige öffentliche Adressen und andere Zugangsdaten.
Änderungen kontrolliert testen
Lege vor Eingriffen eine Sicherung der Router- oder VPN-Konfiguration an, sofern das System diese Möglichkeit bietet. Verändere anschließend nur einen Parameter. Sonst bleibt unklar, ob Keepalive, Timeout oder eine zufällige Neuverbindung den Erfolg verursacht hat.
- Dokumentiere Ausgangswerte und das bisherige Abbruchintervall.
- Passe nur die Einstellung an, für die das Protokoll oder der Leerlauftest einen Hinweis liefert.
- Baue den Tunnel vollständig neu auf.
- Teste länger als die bisherige Grenze, einmal mit regelmäßiger Nutzung und einmal mit Leerlauf.
- Kontrolliere Protokoll, Handshake, Datenzähler und Erreichbarkeit interner Ziele.
- Bleibt der Fehler bestehen, stelle den Ausgangswert wieder her und untersuche den nächsten Zweig.
Als Erfolg gilt nicht nur eine grüne Statusanzeige. Interne Namen müssen auflösbar sein, erlaubte Ziele müssen antworten und der vorgesehene Datenverkehr muss tatsächlich durch den Tunnel laufen. Andernfalls kann die VPN-Oberfläche verbunden anzeigen, obwohl Route, DNS oder Authentifizierung bereits nicht mehr funktionieren.
Welche Maßnahmen zum jeweiligen Ergebnis passen
- Nur Leerlauf führt zum Abbruch: Idle-Richtlinie, NAT-Timeout und vorgesehene Keepalive-Funktion prüfen.
- Aktiver Datenverkehr ändert nichts: maximale Sitzungsdauer, Rekey, erneute Authentifizierung und Tokenlaufzeit untersuchen.
- Nur ein Router ist betroffen: Routerprotokoll, NAT-Verhalten, Firewall und Firmwarestatus prüfen; keine globalen Timeout-Werte ohne Sicherung ändern.
- Nur WLAN ist betroffen: VPN zunächst beiseitelassen und Funkabbrüche, Energiesparen sowie den Wechsel zwischen Zugangspunkten untersuchen.
- Alle Internetverbindungen brechen gleichzeitig ab: WAN-, Leitungs- oder Einwahlereignisse haben Vorrang vor VPN-Parametern.
- Nur interne Namen fallen aus: VPN-DNS und Routen prüfen, denn der Tunnel kann weiterhin bestehen.
Ein Werksreset ist für einen reproduzierbaren 60-Minuten-Fehler normalerweise kein sinnvoller früher Schritt. Dabei können Zugangsdaten, Telefonie, Portfreigaben, eigene DNS-Vorgaben und VPN-Profile verloren gehen, ohne dass eine serverseitige Sitzungsgrenze verschwindet.
Häufige Fragen zum VPN-Abbruch nach 60 Minuten
Kann ein VPN-Reset am Router den Abbruch nach genau 60 Minuten beheben?
Ein Neustart oder Reset kann eine vorübergehende Fehlfunktion beseitigen, entfernt aber keine fest konfigurierte Sitzungsdauer auf der VPN-Gegenstelle. Sichere zuerst die Router- und VPN-Einstellungen und prüfe die Protokolle, bevor du zurücksetzt. Ein Werksreset sollte nur der letzte Schritt sein, weil dabei unter anderem Zugangsdaten, Portfreigaben und eigene DNS-Einstellungen verloren gehen können.
Warum bleibt das VPN trotz Keepalive nach einer Stunde getrennt?
Keepalive hält vor allem NAT-Zuordnungen offen und meldet der Gegenstelle, dass der Tunnel noch erreichbar ist. Eine maximale Sitzungsdauer, eine ablaufende Security Association oder eine erneute Authentifizierung wird dadurch nicht verhindert. Suche im Protokoll deshalb gezielt nach Hinweisen auf Rekey, Reauthentifizierung, Sitzungsablauf oder abgelaufene Zugangstoken.
Was bedeutet es, wenn nur interne Namen nach einer Stunde nicht mehr aufgelöst werden?
Dann kann der VPN-Tunnel weiterhin bestehen, während die zugehörige VPN-DNS-Konfiguration oder die Route zum internen DNS-Server nicht mehr funktioniert. Prüfe, ob interne Ziele per IP-Adresse noch erreichbar sind und ob der VPN-Client weiterhin die vorgesehenen DNS-Server verwendet. Funktionieren IP-Ziele, aber keine internen Namen, liegt der nächste Prüfschritt bei DNS und nicht beim WLAN.
Wie lässt sich feststellen, ob der Router oder der VPN-Server die Trennung verursacht?
Teste denselben VPN-Zugang über LAN und, wenn möglich, über einen anderen Internetzugang. Tritt der Abbruch unabhängig vom Router und jeweils nach derselben Laufzeit auf, sind Client, Gegenstelle oder eine zentrale Zugriffsrichtlinie wahrscheinlicher. Bleibt der Fehler auf einen Router beschränkt, vergleiche dessen Ereignisprotokoll und VPN- beziehungsweise Firewall-Einstellungen mit einem funktionierenden Zugang.
Welche Informationen sollte ich bei einem verwalteten Firmen-VPN weitergeben?
Nützlich sind mindestens Startzeit, exakte Abbruchzeit, gemessene Sitzungsdauer, verwendeter Internetzugang und die letzten relevanten Protokollmeldungen vor der Trennung. Ergänze, ob während des Abbruchs Datenverkehr lief und ob normale Webseiten weiterhin erreichbar waren. Entferne vor der Weitergabe Passwörter, private Schlüssel, vollständige öffentliche Adressen und andere vertrauliche Zugangsdaten.
