Ein VPN-Ausfall liegt fast immer an einem von vier Punkten: blockierter Port (UDP 500/4500, TCP 443), falsches Protokoll (IKEv2, OpenVPN, WireGuard), abgelaufene Zugangsdaten oder eine Firewall, die den Tunnel abwürgt. Prüfen Sie zuerst die Internetverbindung ohne VPN, dann Protokoll und Server, danach lokale Sicherheits-Software.
Symptome
- Client bleibt bei „Verbinde…“ hängen und läuft in einen Timeout
- Verbindung baut sich auf, trennt aber nach wenigen Sekunden wieder
- Tunnel steht, aber es fließen keine Daten (kein Ping, kein DNS)
- Fehlermeldungen wie „Authentication failed“, „TLS handshake failed“, Error 809/812/691
- VPN läuft im Mobilfunk, scheitert aber im Firmen- oder Hotel-WLAN
Häufige Ursachen
Blockierte VPN-Ports beim ISP oder im Gast-WLAN
Viele öffentliche Netze und einige Provider filtern UDP 500/4500 (IKEv2), UDP 1194 (OpenVPN) oder GRE (PPTP). Der Client versucht zu handshaken, bekommt aber keine Antwort.
Falsches oder veraltetes Tunnel-Protokoll
Ältere Profile mit PPTP, L2TP oder SSTP scheitern an modernen Firewalls oder werden vom Server nicht mehr angenommen. IKEv2, OpenVPN (UDP) und WireGuard sind der aktuelle Standard.
Lokale Firewall, Antivirus oder DNS-Filter
Endpoint-Security-Suiten wie Windows Defender Firewall, Bitdefender oder Kaspersky blockieren gelegentlich den TAP-/WireGuard-Adapter oder unterbrechen den TLS-Handshake per HTTPS-Inspection.
Abgelaufene Zertifikate oder Zugangsdaten
Läuft das Server- oder Client-Zertifikat ab, quittiert der Tunnel mit „TLS handshake failed“ oder „certificate verify failed“. Bei RADIUS-Auth reicht ein geänderter AD-Passwort.
MTU-Fehler und doppeltes NAT
Hinter Carrier-Grade-NAT oder mit einer MTU über 1500 fragmentieren die Pakete. Der Tunnel steht, Nutzdaten kommen aber nicht durch. Sichtbar an „Ping ja, HTTPS nein“.
Schritt-für-Schritt-Lösung
- Internetverbindung ohne VPN gegenprüfen
Trennen Sie den VPN-Client vollständig und öffnen Sie zwei Referenzseiten sowie einen Speedtest. Läuft das Netz instabil oder unter 5 Mbit/s, ist das die Wurzel. Testen Sie zum Vergleich denselben VPN-Zugang über den Mobilfunk-Hotspot Ihres Handys. - Zugangsdaten, Zertifikat und MFA verifizieren
Melden Sie sich mit denselben Credentials am Firmen-Webportal oder Outlook Web an. Läuft das nicht, ist das AD- oder RADIUS-Konto gesperrt bzw. das Passwort abgelaufen. Bei zertifikatsbasiertem VPN das Ablaufdatum im Zertifikatspeicher (certmgr.msc) prüfen und ein neues Profil vom Admin ziehen. - Tunnel-Protokoll und Server wechseln
Schalten Sie im Client von IKEv2 auf OpenVPN (UDP), notfalls auf OpenVPN TCP 443 – dieser Port passiert praktisch jede Firewall. Wählen Sie zusätzlich einen anderen Serverstandort, falls der ursprüngliche überlastet oder offline ist. - Firewall, Antivirus und Web-Filter kurz deaktivieren
Beenden Sie testweise Drittanbieter-Security und lassen Sie in der Windows-Firewall die Regeln für den VPN-Client sowie UDP 500, 4500, 1194 zu. Verbindet sich das VPN danach, legen Sie eine dauerhafte Ausnahme an, statt die Firewall komplett auszuschalten. - VPN-Adapter und Netzwerkstack zurücksetzen
Deinstallieren Sie den virtuellen Adapter (TAP-Windows, WireGuard Tunnel) im Geräte-Manager und installieren Sie den Client neu. Danach in einer Admin-Konsole: netsh int ip reset, netsh winsock reset, ipconfig /flushdns. Rechner neu starten. Damit sind hängende Routen und DNS-Reste weg. - DNS- und MTU-Probleme gezielt eingrenzen
Nach dem Verbinden ping 8.8.8.8 gegen ping google.com testen. Klappt nur die IP, ist der interne DNS-Server im VPN-Profil falsch. Bei fragmentierten Paketen die Tunnel-MTU in der Client-Konfiguration auf 1400 (OpenVPN: mssfix 1360) setzen. - Logs auswerten und Ticket öffnen
Öffnen Sie das Client-Log (OpenVPN: openvpn.log, WireGuard: Ereignisanzeige, Windows RAS: Error 8xx). Suchen Sie nach der ersten Fehlerzeile, nicht nach der letzten. Diese Zeile plus Zeitstempel gehört ins Ticket an Ihr IT-Team, damit die Server- und Firewall-Logs korreliert werden können.
Häufige VPN-Fehlercodes und passende Sofortmaßnahmen
| Fehlercode / Meldung | Bedeutung | Erste Maßnahme |
|---|---|---|
| Error 809 | NAT-T oder UDP 500/4500 blockiert | Auf IKEv2 mit NAT-Traversal umstellen oder Router-Port freigeben |
| Error 691 | Zugangsdaten abgelehnt | Passwort im AD prüfen, Konto entsperren, MFA-Token neu koppeln |
| Error 812 | Serverseitige Auth-Policy verweigert | RADIUS/NPS-Regel und Gruppenmitgliedschaft prüfen |
| TLS handshake failed | Zertifikat abgelaufen oder Zeit falsch | Systemzeit synchronisieren, Zertifikat erneuern |
| Auth OK, kein Traffic | Routing- oder DNS-Push fehlt | Split-Tunnel-Regeln und interne DNS-Server im Profil kontrollieren |
| Verbindung nach 30–60 s weg | Idle-Timeout oder Keepalive fehlt | keepalive 10 60 in OpenVPN setzen, DPD in IKEv2 aktivieren |
So beugen Sie vor
- VPN-Client und Betriebssystem monatlich patchen, veraltete Protokolle wie PPTP deaktivieren
- Zertifikatslaufzeiten überwachen und Client-Profile 30 Tage vor Ablauf erneuern
- Split-Tunneling nur für unkritische Dienste erlauben, sensible Ziele im Full-Tunnel halten
- Zweiten Server-Endpoint im Profil hinterlegen, damit ein Ausfall automatisch umschwenkt
Häufige Fragen
Warum funktioniert mein VPN im Café, aber nicht im Firmen-WLAN?
Unternehmens- und Gastnetze setzen häufig eine Deep-Packet-Inspection-Firewall ein, die UDP-Tunnel erkennt und verwirft. Wechseln Sie im Client auf OpenVPN oder SSTP über TCP 443, weil dieser Port für HTTPS ohnehin offen sein muss. Bleibt es blockiert, liegt eine bewusste Richtlinie des Netzbetreibers vor, die nur der dortige Admin aufheben kann.
Wie erkenne ich, ob mein Internetanbieter das VPN drosselt oder blockiert?
Führen Sie denselben Verbindungsversuch einmal im Heimnetz und einmal über den Handy-Hotspot durch. Klappt es im Mobilfunk sofort und im Festnetz gar nicht, deutet das auf ein ISP-seitiges Filtering hin. Ein zweiter Indikator: OpenVPN über UDP 1194 scheitert, TCP 443 funktioniert – klassisches Zeichen für Port-Blocking.
Reicht ein Client-Neustart oder muss ich immer den Rechner neu starten?
Für kurzfristige Hänger genügt es meist, den VPN-Dienst zu beenden und neu zu starten (Dienste-Konsole oder Task-Manager). Bleiben Routen oder der virtuelle Adapter hängen, hilft nur ein Neustart des Systems, weil der Netzwerkstack sonst die alten Einträge behält. Nach jeder Client-Neuinstallation ist ein Reboot ohnehin Pflicht.