Anschluss ist geoeffnet - Fehler nach VPN-Abbruch in Win7
Hallo allerseits,
vielleicht kennt jemand eine Lösung für folgendes Problem. Ich wähle mich per VPN in unser Firmennetz. Nach einer Weile bricht die VPN-Verbindung aus unbekannten Gründen ab, und ab dann geht gar kein Internetzugriff mehr. Jeder Versuch, diese oder eine andere VPN-Verbindung erneut aufzubauen führt zur Fehlermeldung "Anschluss ist geöffnet".
Der VPN-Verbindungsabbruch ist gar nicht das Problem, das passiert sehr selten und damit kann ich leben. Nervig ist allerdings, dass danach überhaupt kein Internet mehr geht und ich keine Ahnung habe, wie ich diesen Status wieder loswerde.
Was kann da machen? Gibt es da sowas ähnliches wie einen iisreset, der einfach die Netzverbindungen alle zurücksetzt und "bei null" beginnt?
Für alle Vorschläge dankbar,
viennacalling
vielleicht kennt jemand eine Lösung für folgendes Problem. Ich wähle mich per VPN in unser Firmennetz. Nach einer Weile bricht die VPN-Verbindung aus unbekannten Gründen ab, und ab dann geht gar kein Internetzugriff mehr. Jeder Versuch, diese oder eine andere VPN-Verbindung erneut aufzubauen führt zur Fehlermeldung "Anschluss ist geöffnet".
Der VPN-Verbindungsabbruch ist gar nicht das Problem, das passiert sehr selten und damit kann ich leben. Nervig ist allerdings, dass danach überhaupt kein Internet mehr geht und ich keine Ahnung habe, wie ich diesen Status wieder loswerde.
Was kann da machen? Gibt es da sowas ähnliches wie einen iisreset, der einfach die Netzverbindungen alle zurücksetzt und "bei null" beginnt?
Für alle Vorschläge dankbar,
viennacalling
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 206307
Url: https://administrator.de/contentid/206307
Ausgedruckt am: 22.11.2024 um 09:11 Uhr
6 Kommentare
Neuester Kommentar
Die Fehlerbeschreibung ist leider sehr oberflächlich und laienhaft. Eine wirkliche Hilfe ist damit fast unmöglich.
Minimal solltest du uns wenigstens schildern WELCHES VPN Protokoll du verwendest (Ipsec, PPTP, SSL, L2TP usw.) und ob du einen Win bordeigenen Client benutzt oder einen 3rd Party Client ?
Ohne diese Informationen bleibt uns wie immer hier nur die allseits bekannte Kristallkugel
Minimal solltest du uns wenigstens schildern WELCHES VPN Protokoll du verwendest (Ipsec, PPTP, SSL, L2TP usw.) und ob du einen Win bordeigenen Client benutzt oder einen 3rd Party Client ?
Ohne diese Informationen bleibt uns wie immer hier nur die allseits bekannte Kristallkugel
Das ist vermutlich ein Client Problem oder auch Router Problem sofern du einen NAT Router vor dem Server betreibst. Hast du den Client im Setup dediziert auf PPTP gesetzt ? Der sollte NICHT auf "Auto" stehen.
Dieses Tutorial beschreibt die Details dazu:
VPNs einrichten mit PPTP
Dein Control Session auf TCP 1723 bricht ab, deshalb kommt die PPTP Verbindung nicht zustande !
Du kannst das ganz leicht testen. Wenn dieser Blocking Zustand anhält einfach mal den Router kaltstarten. Sollte es danach problemlos funktionieren hat dein Router ein GRE Sessionproblem !
Besser ist es immer ohne NAT Forwarding zu arbeiten also PPTP auf dem Router oder Firewall selber zu terminieren !
Dieses Tutorial beschreibt die Details dazu:
VPNs einrichten mit PPTP
Dein Control Session auf TCP 1723 bricht ab, deshalb kommt die PPTP Verbindung nicht zustande !
- Hast du vor dem Server noch einen NAT Router (Adress Translation) ?
- Stimmen dort die Port Forwardings wie im Tutorial oben beschrieben ?
- Kann es sein das mehrere PPTP Clients über den Port Forwarding Zugang (NAT Router vor Server) zugreifen ?
Du kannst das ganz leicht testen. Wenn dieser Blocking Zustand anhält einfach mal den Router kaltstarten. Sollte es danach problemlos funktionieren hat dein Router ein GRE Sessionproblem !
Besser ist es immer ohne NAT Forwarding zu arbeiten also PPTP auf dem Router oder Firewall selber zu terminieren !
Nun dann holen wir mal aus und erklären dir die Grundlagen des Netzwerkens...
Der Router vor deinem VPN Server hat eine aktive NAT (Network Adress Translation) Firewall. Falls du nicht weisst was NAT ist siehe hier:
http://de.wikipedia.org/wiki/Network_Address_Translation
Es ist also vollkommen unmöglich von außen (Internet) den VPN Server hinterm NAT Router mit einem Client zu erreichen, denn das verhindert erfolgreich die NAT Firewall des Routers.
Ist ja auch sinnvoll und gewollt so bei allen DSL oder Internet Routern.
Folglich also muss in diesem Router vor dem Server zwingend ein Port Forwarding (Port Weiterleitung) der PPTP Protokolle auf die interne, lokale IP Adresse des Servers eingetragen sein, damit ein PPTP Client von außen den internen VPN Server erreichen kann !
Ohne diese Port Weiterleitung wäre das logischerweise technisch unmöglich !
Folglich steht also in dem Router eine konfigurierte Weiterleitung der beiden PPTP Ports:
Soweit verstanden ?
Wenn dieser Router nun das GRE Protokoll, was keinerlei Ports intern hat wie TCP oder UDP Protokolle, nicht mit einem Session Handling behandeln kann brechen primäre GRE Sessions ab sofern weitere eingehen am Router.
Der Router blockt daraufhin mit einer gewissen Timeout Zeit alle weiteren eingehenden GRE Sessions.
Eigentlich kann man das ganz einfach verstehen wenn man sich einmal die grundlegenden Mechanismen eines VPN Zugriffs hinter einem NAT Router vor Augen führt !
Klar sollte sein das der Server hinter dem Router immer eine feste statische IP Adresse hat damit die Port Forwardings nicht ins Leere laufen !
Auch klar ist das dein Router eine feste öffentliche IP Adresse vom Provider haben muss, denn diese IP ist IMMER die Ziel IP Adresse des PPTP Clients. Klar, denn der Router leitet diese eingehende Session ja an den Server weiter.
Wenn du keine feste öffentliche Provider IP bekommst musst du zwingend mit DynDNS Diensten wie noip.com usw. auf dem Router arbeiten so das du zu wechselnden DSL IPs immer einen festen Hostnamen hast.
Das ist dir aber vermutlich auch selber klar...hoffentlich ?!
Was also genau verstehst du daran nicht ? Ist doch eigentlich alles ganz logisch.
Wie gesagt das betrachtet eine mögliche Fehlerquelle im Router. Es ist aber auch möglich das der Client eine Macke hat (interne Firewall). Beim Server eher unwahrscheinlich.
Hilfreich ist auch ein Sniffern des PPTP Sessionaufbaus mit dem Wireshark Sniffer. Der zeigt dir meist auch sofort wo es kneift.
Der Router vor deinem VPN Server hat eine aktive NAT (Network Adress Translation) Firewall. Falls du nicht weisst was NAT ist siehe hier:
http://de.wikipedia.org/wiki/Network_Address_Translation
Es ist also vollkommen unmöglich von außen (Internet) den VPN Server hinterm NAT Router mit einem Client zu erreichen, denn das verhindert erfolgreich die NAT Firewall des Routers.
Ist ja auch sinnvoll und gewollt so bei allen DSL oder Internet Routern.
Folglich also muss in diesem Router vor dem Server zwingend ein Port Forwarding (Port Weiterleitung) der PPTP Protokolle auf die interne, lokale IP Adresse des Servers eingetragen sein, damit ein PPTP Client von außen den internen VPN Server erreichen kann !
Ohne diese Port Weiterleitung wäre das logischerweise technisch unmöglich !
Folglich steht also in dem Router eine konfigurierte Weiterleitung der beiden PPTP Ports:
- TCP 1723 (Controll Port)
- GRE (IP Protokoll 47 und Tunnel in dem die Produktivdaten verschlüsselt übertragen werden)
Soweit verstanden ?
Wenn dieser Router nun das GRE Protokoll, was keinerlei Ports intern hat wie TCP oder UDP Protokolle, nicht mit einem Session Handling behandeln kann brechen primäre GRE Sessions ab sofern weitere eingehen am Router.
Der Router blockt daraufhin mit einer gewissen Timeout Zeit alle weiteren eingehenden GRE Sessions.
Eigentlich kann man das ganz einfach verstehen wenn man sich einmal die grundlegenden Mechanismen eines VPN Zugriffs hinter einem NAT Router vor Augen führt !
Klar sollte sein das der Server hinter dem Router immer eine feste statische IP Adresse hat damit die Port Forwardings nicht ins Leere laufen !
Auch klar ist das dein Router eine feste öffentliche IP Adresse vom Provider haben muss, denn diese IP ist IMMER die Ziel IP Adresse des PPTP Clients. Klar, denn der Router leitet diese eingehende Session ja an den Server weiter.
Wenn du keine feste öffentliche Provider IP bekommst musst du zwingend mit DynDNS Diensten wie noip.com usw. auf dem Router arbeiten so das du zu wechselnden DSL IPs immer einen festen Hostnamen hast.
Das ist dir aber vermutlich auch selber klar...hoffentlich ?!
Was also genau verstehst du daran nicht ? Ist doch eigentlich alles ganz logisch.
Wie gesagt das betrachtet eine mögliche Fehlerquelle im Router. Es ist aber auch möglich das der Client eine Macke hat (interne Firewall). Beim Server eher unwahrscheinlich.
Hilfreich ist auch ein Sniffern des PPTP Sessionaufbaus mit dem Wireshark Sniffer. Der zeigt dir meist auch sofort wo es kneift.