RDP über VPN nach Internet-Trennung und -wiederaufbau nicht mehr möglich

Es gibt 21 Antworten in diesem Thema. Der letzte Beitrag () ist von VaporiZed.

    RDP über VPN nach Internet-Trennung und -wiederaufbau nicht mehr möglich

    Hallo zusammen.

    Ich habe folgende Situation:
    • ich habe ein fernes Netzwerk mit Fritz!Box, bei dem ein Fritz-VPN eingerichtet ist
    • einen hiesigen Arbeitsplatz mit einer Anbindung an eine eigene Fritz!Box, der per Fritz!Fernwartung erfolgreich eine Verbindung zu der anderen Fritz!Box und so zu dem Ziel-Netzwerk aufbauen kann
    • ich kann über den Zugriff auf die Ziel-Fritz!Box sehen, dass der von mir zu erreichende PC gelistet und online ist und eine eigene IP4-Adresse hat (fix zugewiesen)
    • monatelang konnte ich bis heute morgen fast immer* den gewünschten Zielcomputer über die windowsinterne App »Remotedesktopverbindung« (RDP) erreichen, sodass ich auf diesen Zugriff hatte, so als ob ich direkt lokal an dem PC sitzen/arbeiten würde
    • heute morgen gab es eine Trennung der Internetverbindung, wahrscheinlich wieder der Klassiker, dass sie automatisch routinemäßig getrennt wird, »um einer Zwangstrennung durch den Internetanbieter zuvorzukommen«
    • seitdem (und zahlreicher Neuverbindungsversuche meinerseits) funktioniert die RDP nicht mehr. Den Ziel-PC kann ich nicht erfolgreich anpingen (ich weiß nicht, ob das relevant ist), ich habe hier bei mir keine IP4-Adresse, sondern DS-Lite (ich bekomm derzeit nix anderes zugewiesen, weiß aber auch nicht, ob das relevant ist, weil ja die VPN-Verbindung weiterhin klappt und ich den Ziel-PC über die Ziel-Fritz!Box sehe)
    • Ich kann über den Dateiexplorer auch nicht mehr auf Verzeichnisse des Ziel-PCs zugreifen, was bisher auch immer ging
    Was kann ich tun oder was übersehe ich?

    * Wenn bei laufender RDP ein Verbindungsverlust eintrat, musste ich manuell den VPN-User am Ziel-PC abmelden, manchmal auch den Ziel-PC neustarten, da die Sitzung offiziell fortbestand und eine weitere Verbindung nicht erlaubt ist. Dies habe ich gestern insofern (hoffentlich) verbessert, dass ich über gpedit.msc (Editor für lokale Gruppenrichtlinien) eingestellt habe, dass nach Verbindungsverlust/Trennung die Session automatisch nach einer Minute beendet wird.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Fangen wir mal einfach an:
    Benutzt du die IP-Adresse oder den Hostnamen für die RDP-Verbindung?
    Wenn Hostname: was sagt nslookup rdp-machine-name?
    Kannst du die remote Fritzbox via Ping (IP-Adresse) erreichen?
    Kann man in der lokalen Fritzbox die aktuellen Routen auslesen?
    Wenn ja, ist dort die Route zu dem Remote-Netz hinterlegt und geht über die VPN-Verbindung?

    VaporiZed schrieb:

    Den Ziel-PC kann ich nicht erfolgreich anpingen

    Das ist nicht maßgeblich. Bei Windows ist der Ping standardmäßig deaktiviert. Ist eine Sicherheitsfunktion. Kann man wieder einschalten, aber nunja.

    VaporiZed schrieb:

    »um einer Zwangstrennung durch den Internetanbieter zuvorzukommen«

    Dazu vielleicht noch: das ist ganz wichtig und richtig. Allerdings kannst du in der Fritz!Box einstellen, wann das passiert. Ich habe das für 0400 eingestellt, damit es mich nicht nervt.
    Die Zwangstrennung dient, den IP-Pool auszugleichen. Es gibt (immer noch) zu wenig IPv4 Adressen, somit findet in den meisten Ländern eine Zwangstrennung statt, außer du hast eine statische IP (Geschäftskundenvertrag, bspw.).

    VaporiZed schrieb:

    Ich kann über den Dateiexplorer auch nicht mehr auf Verzeichnisse des Ziel-PCs zugreifen, was bisher auch immer ging


    Deutet für mich daraufhin, dass der SMB-Dienst nicht mehr (richtig) läuft.

    Wenn der PC aber noch aktiv ist, könntest du schauen, ob du ihn erreichen kannst: tracert <IP>.
    Ansonsten finde ich den Fehler sehr interessant. Dein Gateway scheint ja ordnungsgemäß zu funktionieren.
    Quellcode lizensiert unter CC by SA 2.0 (Creative Commons Share-Alike)

    Meine Firma: Procyon Systems
    Meine Privatwebseite: SimonC.eu

    Bitte nicht wundern, wenn meine Aktivitäten im Forum etwas langsamer sind, ich baue gerade mein Nebengewerbe zum Vollgewerbe aus.
    Ich versuche auf euch zurückzukommen :)

    kurze Rückmeldung: die RDP-Verbindung erfolgt nicht per Ziel-PC-Namen, sondern per IP4-Adresse.
    Den Rest Deiner Frage versuche ich morgen zu beantworten, @slice
    @siycah: fehlende Ping-Relevanz: hatte ich vermutet, danke für die Aufklärung
    Zwangstrennungseinstellung werd ich morgen vornehmen
    Habe den Ziel-PC nochmals vorhin neu gestartet und gesehen, dass ich jetzt darauf zugreifen kann. Ob allerdings sich nun im Verlauf des Tages was hier fernab vom Ziel was Relevantes geändert hat oder ob der Neustart des Ziel-PCs die vorübergehende Lösung war, weiß ich nicht. Wird sicherlich nicht das letzte Mal gewesen sein, dass ich das Problem habe. Ich bleibe dran.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Angaben, wenn die Verbindung erfolgreich ist:

    slice schrieb:

    Kannst du die remote Fritzbox via Ping (IP-Adresse) erreichen?
    Ja, ich kann die andere Fritz!Box und den Ziel-PC erfolgreich anpingen. Den Ziel-PC konnte ich im Szenario von Post#1 nicht anpingen, aber die andere Fritz!Box per Web-UI erreichen. Ob Ping ging, weiß ich nicht, ich vermute, dass dies geklappt hätte.

    slice schrieb:

    Kann man in der lokalen Fritzbox die aktuellen Routen auslesen? Wenn ja, ist dort die Route zu dem Remote-Netz hinterlegt und geht über die VPN-Verbindung?
    Hab ich noch nicht gefunden, wo ich das einsehen kann, ich recherchiere weiter. Oder Ihr verratet es mir :D
    @siycah: Die Trennung erfolgt laut meine Fritz!Box zwischen 3 und 4 Uhr - per default. Dass es entsprechend Post#1 um 9 eine Trennung gab, war also ungewöhnlich.
    Den Dateiexplorer kann ich bei erfolgreicher Verbindung nutzen, also in die Addressleiste \\IP_des_Ziel-PCs\EinFreigegebenesVerzeichnis, Enter drücken, etwas Geduld haben, ggf. Zugangsdaten des VPN-Users eingeben, fertig.
    tracert <IP> funktioniert zum Ziel-PC bei bestehender Verbindung problemlos.

    Die Gegendaten folgen, wenn es mal wieder zu einem Verbindungsabbruch kommt, könnte also (hoffentlich) etwas dauern.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    VaporiZed schrieb:

    Dass es entsprechend Post#1 um 9 eine Trennung gab, war also ungewöhnlich.

    Ich würde es nicht pauschal ausschließen, dass das durch den Anbieter erfolgt ist. Ich meine da gibt's in den Protokollen bestimmte Kontrollnachrichten, worüber der Anbieter einen erneuten Verbindungsaufbau erzwingen kann.

    VaporiZed schrieb:

    tracert <IP> funktioniert zum Ziel-PC bei bestehender Verbindung problemlos.

    Genau so sollte es auch sein. Ich gehe aktuell stark davon aus, dass bei dem Remote-PC wegen einer nicht sauber geschlossenen Verbindung der SMB-Dienst verreckt ist. Vor allem wenn ein älterer Standard eingestellt ist, sind noch einige Bugs in den Diensten.

    Halte uns auf dem Laufenden, ich finde das super spannend
    Quellcode lizensiert unter CC by SA 2.0 (Creative Commons Share-Alike)

    Meine Firma: Procyon Systems
    Meine Privatwebseite: SimonC.eu

    Bitte nicht wundern, wenn meine Aktivitäten im Forum etwas langsamer sind, ich baue gerade mein Nebengewerbe zum Vollgewerbe aus.
    Ich versuche auf euch zurückzukommen :)

    VaporiZed schrieb:

    Den Ziel-PC konnte ich im Szenario von Post#1 nicht anpingen, aber die andere Fritz!Box per Web-UI erreichen.

    Na das ist doch immerhin etwas? Heißt die VPN-Verbindung an für sich wird wieder erfolgreich hergestellt.

    Das mit tracert ist eine gute Idee, ich würde zusätzlich auf dem remote Host auch mal ins Event Log schauen, wenn der Fehler auftritt (falls du das irgendwie hinbekommst).

    Argh. Das Problem kam schneller zurück als erwartet, obwohl es keine Trennung der beiden Fritz!Boxen gab. Die andere FB ist über die öffentliche IP4 und die netzwerkinterne anpingbar. Der Ziel-PC ist jetzt nicht über seine interne Netzwerk-IP anpingbar. tracert lieferte einen Erfolgsversuch und zahlreiche Misserfolge. Da der Ziel-PC für das Netzwerk relevant ist (meine Apps liegen z.B. drauf), hätte man mir schon berichtet, wenn er netzwerkintern nicht erreichbar gewesen wäre. Der Ziel-PC ist also an, online und zumindest netzwerkintern erreichbar. :cursing:
    In die EventLogs am Ziel-PC schaue ich, wenn ich wieder vor Ort bin.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Kannst du bitte den Output von ​tracert hier reinschreiben?
    Wenn das über ein VPN geht, dann dürften das ja nur ein paar Hops sein.

    Ab der Remote-FB nur noch einer, wenn ich dich richtig verstanden habe.
    Quellcode lizensiert unter CC by SA 2.0 (Creative Commons Share-Alike)

    Meine Firma: Procyon Systems
    Meine Privatwebseite: SimonC.eu

    Bitte nicht wundern, wenn meine Aktivitäten im Forum etwas langsamer sind, ich baue gerade mein Nebengewerbe zum Vollgewerbe aus.
    Ich versuche auf euch zurückzukommen :)

    Die IPSec Implementation von AVM in der FRITZ!Box ist immernoch ziemlich verbuggt. Wenn eine Trennung unfreiwillig erfolgt, droppt der manchmal einfach ungewohlt Pakete bzw. die automatische Neuverbindung erfolgt nicht immer gut (Erst nach Neustart beider Seiten). Das Problem kenn ich.

    Was ich dir als alternative mal empfehle zu versuchen, seit FRITZ!OS 7.58 (oder so), gibt es in der FRITZ!Box auch die Möglichkeit den Tunnel per Wireguard aufzubauen. Vielleicht versuchst du das einfach mal. (Außerdem ist Wireguard weitaus Ressourcenschonender als IPSec)

    @siycah:

    Quellcode

    1. Routenverfolgung zu [IP-Adresse] über maximal 30 Hops
    3. 1 28 ms 30 ms 26 ms [IP-Adresse]
    4. 2 * * * Zeitüberschreitung der Anforderung.
    5. 3 * * * Zeitüberschreitung der Anforderung.
    6. 4 * * * Zeitüberschreitung der Anforderung.
    7. 5 * * * Zeitüberschreitung der Anforderung.
    8. 6 * * * Zeitüberschreitung der Anforderung.
    9. 7 * * * Zeitüberschreitung der Anforderung.
    10. 8 * * * Zeitüberschreitung der Anforderung.
    11. 9 * * * Zeitüberschreitung der Anforderung.
    12. 10 * * * Zeitüberschreitung der Anforderung.
    13. 11 * * * Zeitüberschreitung der Anforderung.


    ##########

    Jetzt hatte ich 2 tracert-Bestätigungen, gleich danach (weil ich das Kopieren vergessen hatte), wieder nicht.
    @ManuelSoftware: Vielen Dank. Mit Wireguard ist die Verbindung beim ersten Mal wie gewünscht. Trotz der komischen, gerade genannten tracert-Situation. Aber auch dort werde ich weiter beobachten.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „VaporiZed“ ()

    Das ist sehr interessant. Mit WireGuard habe ich bisher keine Erfahrungen gemacht, scheint soweit aber auch ein gutes Tool zu sein. Bisher habe ich immer direkt auf dem Server SoftEther verwendet, oder die eigebauten MS-Tools.
    Quellcode lizensiert unter CC by SA 2.0 (Creative Commons Share-Alike)

    Meine Firma: Procyon Systems
    Meine Privatwebseite: SimonC.eu

    Bitte nicht wundern, wenn meine Aktivitäten im Forum etwas langsamer sind, ich baue gerade mein Nebengewerbe zum Vollgewerbe aus.
    Ich versuche auf euch zurückzukommen :)

    WireGuard ist zwar moderner und schneller wie Tests zeigen, aber ich würde das alte OpenVPN Protokoll bevorzugen. Ich nutze ausschliesslich OpenVPN, habe aber keine Probleme was Geschwindigkeit und Latenz angeht. Ich lege Wert auf Privatsphäre, die ist mit WireGuard nicht unbedingt garantiert. Sicher ist das wenn man wie NordVPN Double NAT mit WireGuard verwendet, evtl. auch mit anderen Modifizierungen. Wenn euch Privatsphäre wichtig ist, schaut wie die Fritz das implementiert hat, wenn WireGuard genutzt werden soll warum auch immer.

    Hier hat das jemand gut beschrieben, muss ich ja nicht wiederholen.
    reddit.com/r/WireGuard/comment…cally_explain_wireguards/
    Zitat von mir 2023:
    Was interessiert mich Rechtschreibung? Der Compiler wird meckern wenn nötig :D

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „DTF“ ()

    @DTF Genau deswegen nutze ich SoftEther - basiert auf OpenVPN, ist aber viel benutzerfreundlicher. Auch für mich als Admin :D
    Quellcode lizensiert unter CC by SA 2.0 (Creative Commons Share-Alike)

    Meine Firma: Procyon Systems
    Meine Privatwebseite: SimonC.eu

    Bitte nicht wundern, wenn meine Aktivitäten im Forum etwas langsamer sind, ich baue gerade mein Nebengewerbe zum Vollgewerbe aus.
    Ich versuche auf euch zurückzukommen :)

    @DTF Ja Privatsphäre nicht zu verwechseln mit Sicherheit ;)

    Und wenn es sich um ein ausschließlich privat genutztes Netzwerk handelt, spielt das denk ich weniger die Rolle.

    Wie in deinem Reddit auch schön beschrieben:

    WireGuard is highly secure, but it’s not designed with privacy in mind.
    At time of writing, the biggest privacy weakness that WireGuard has is how it assigns IP addresses. When you connect to a VPN service using OpenVPN or IKEv2, you’re assigned a different IP address each time. WireGuard instead gives you the same IP address each time. This is faster, but it means the VPN server must keep logs of your real IP address and connection timestamps.
    For VPN services with a focus on user privacy and anonymity, this makes WireGuard a relatively poor protocol to use out of the box.


    Und OpenVPN wird von der FRITZ!Box nicht unterstützt mal so als Anmerkung am Rande.

    Jo, in dem Kontext, von dem wir hier sprechen ist der Punkt völlig irrelevant und so ganz am Rande erwähnt:
    Ein VPN bringt niemals mehr Privatsphäre, es "verschiebt" alles nur zu einem anderen Punkt (der eventuell weniger Daten loggt aber, das weiß man nie).
    Ok, dein ISP sieht nicht, das du eine Pornoseite aufrufst, dafür aber der Betreiber des VPN.

    PS: Auch bei OpenVPN kannst du statische IP-Adressen konfigurieren :)

    @VaporiZed Interessanter trace, bei mir im Netz sind das gerade mal Hops (lokaler Router, remote Router/VPN-Server, Ziel-Client)

    slice schrieb:

    Ok, dein ISP sieht nicht, das du eine Pornoseite aufrufst, dafür aber der Betreiber des VPN.


    Hab ich weniger ein Problem mit als beim ISP(ISP-Werbetracking netzpolitik.org/2023/trustpid-…s-werbetracking-ist-frei/), soll zwar opt-in sein, aber wer weiss, oder wer weiss obs nicht doch zum opt-out wird ohne das man es mitbekommt. ich denke meinem VPN Anbieter kann ich trauen, der ist sogar Diskless(Komplett RAM Basiert). In erster Linie verwende ich VPN + verschiedene Browser um es google und anderen Datenkraken zu erschweren mich zu "Röntgen", die haben also diverse Profile von mir. Den Browser je nach Thema, dazu ein Paar Addons in den Browsern und noch mehr. Aber ich mach da jetzt keinen Roman draus, das geht jetzt zu sehr Richtung Offtopic.
    Zitat von mir 2023:
    Was interessiert mich Rechtschreibung? Der Compiler wird meckern wenn nötig :D

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „DTF“ ()

    @slice: Wie meinst Du das, »sind das gerade mal Hops«? Bei mir doch auch: drei Stellen: zum lokalen Router, zum Fernrouter, zum Ziel-PC. Oder blick ich da was nicht?
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Ups, da fehlt in dem Satz die "drei".
    Dein trace in Post #11 zeigt 11 hops, hier mal meine Ausgabe zu meinem remote Host:

    Quellcode

    1. >tracert -d dev-env.example.com
    3. Tracing route to dev-env.example.com [10.10.10.4]
    4. over a maximum of 30 hops:
    6. 1 <1 ms 5 ms <1 ms 192.168.1.1
    7. 2 37 ms 37 ms 37 ms 10.10.11.1
    8. 3 37 ms 37 ms 37 ms 10.10.10.4
    10. Trace complete.


    @DTF Die Provider behaupten viel, wissen/prüfen kann man das aber nie.
    Ich wollte mit dem Post auch nur erwähnen, das mit einem VPN das Problem nur verschoben wird.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „slice“ ()

    VaporiZed schrieb:

    drei Stellen:


    1 funktionierenden Hop sehe ich bei dir.

    ganze vorne die Hop-Nummer, die 3 Zeitwerte stehen für die RTT(Round-Trip-Time). Device->Router, Router->NächsterKnoten und zurück.

    Bei dir also
    Device->Router 28 ms
    Router->[IP-Adresse] 30 ms, [IP-Adresse] = deine Zensierte IP
    [IP-Adresse]->Device 26 ms

    Siehe hier: ;)
    learn.microsoft.com/de-de/wind…/windows-commands/tracert
    Zitat von mir 2023:
    Was interessiert mich Rechtschreibung? Der Compiler wird meckern wenn nötig :D

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „DTF“ ()

Facebook
Telefonspende