WindowsServer19: nach Juni 22 Patchday kein NAT + RDP über VPN möglich

  • Zwei Änderungen gab es gestern, ich sollte den vServer powercyclen lt. netcup und es war Patchday. Auf dem Server läuft Windows Server. Seit dem besteht das Problem.

    Wenn ich mich über die VNC-Console verbinde, sehe ich, dass die Verbindung weiterhin als privat markiert ist, aber auch Internet bereitstellen würde, was, denke ich, nicht richtig ist.

    Ich habe auf beiden Systemen gleichzeitig die Windows Firewall deaktiviert, an ihr liegt es nicht.

    Die WG Verbindung selbst steht und ich leite darüber Traffic von zu Hause aus, also dass dieser Traffic die public WAN-IP des VPS nutzt.

    Ping geht ebenfalls.


    Capture.PNG

    Any thoughts?

  • Zur hilfreichsten Antwort springen
  • Ob die Wireguard Verbindung Internetzugang anzeigt, hängt davon ab, welche Routen du darüber leitest. Wenn die Default Route aufs VPN zeigt, dann gibt es dort auch Internet.


    Die WG Verbindung selbst steht und ich leite darüber Traffic von zu Hause aus, also dass dieser Traffic die public WAN-IP des VPS nutzt.

    Das machst du echt mit einem WIndows Server? Oh Mann. Das würde ich mir 2x überlegen.

  • frank_m Tut sie halt nicht. Das lief auch alles bestens bis gestern, da kamen leider Patchday und netcup powercycle zusammen... Kann mir wer sagen, was wahrscheinlich passiert, wenn netcup einem zu einem Powercycle auffordert?


    PS: Auch OpenVPN macht jetzt Probleme, d.h. ich komme nur noch per VNC-Console rauf, kein RDP mehr. OpenVPN will erst gar keine Verbindung mehr herstellen. Entweder ein Windows Bug oder netcup hat was eingeschlichen.

  • Netcup ändert nur was am KVM Backend. Das hat auf deine Netzwerkverbindungen und Dienste in der VM keinen Einfluss. Wenn es da Probleme gibt, dann durch den Patchday. Ich persönlich vermute allerdings eher Konfigurationsfehler.


    Tut sie halt nicht.

    Dann würde ich da an deiner Stelle noch mal genauer draufgucken. Die Anzeige ist kein Zufall.


    Du musst Schritt für Schritt analysieren: Netzwerkverbindung, VPN Tunnel, RDP Service. Alles noch da, wo es hingehört?

  • Dann würde ich da an deiner Stelle noch mal genauer draufgucken. Die Anzeige ist kein Zufall.

    Inzwischen steht dort "no network access". Ich kann ohne Probleme pingen als auch meinen Traffic von zu Hause über den Wireguard-Tunnel durch den Windows Server dann ins Internet NATen.

    D.H. hier macht nur RDP Probleme.

    OpenVPN allerdings funktioniert gar nicht mehr richtig, das Bild bleibt einfach weiß, keine Log-Einträge, nichts.

    Vielleicht hat ja MS die NAT-Funktionalität in WinServer gestern irgendwie beschädigt?


    Du zumindest meinst, netcup kann es eher nicht gewesen sein...

  • Als Gedankenanstoß: Wireguard hat auch seine Tücken; bisweilen kann es vorkommen, dass länger laufende Rechner nach Abbau einer Verbindung über einen Wireguard-Tunnel diese irgendwann nicht mehr aufbauen können. Ein Neustart des lokalen Wireguard-Diensts kann das korrigieren, muss aber nicht. Einzige reproduzierbare „sofortige“ Lösung war bislang das Durchstarten aller beteiligter Hostrechner (selbst, wenn das ausschließlich Linux mit aktuellen 5.15.x-LTS-Kerneln betrifft).

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Mit Windows Anzeigen "no network access", "internet access", usw. kann ich leider nichts anfangen.



    Manuell:

    -> Verifzieren der Internetverbindung von Client und Server

    -> Verifzieren von ICMP/ping Konnektivität zwischen Client und Server von Client und Server

    -> Verifzieren von geöffneten Ports am Server

    -> Verfizieren von Firewall Aktivität am Server

    -> Verfizieren von Port-Erreichbarkeit von Client zum Server

    -> Netzwerkmitschnitt (tcpdump o.ä.) von Client und Server

  • Inzwischen steht dort "no network access".

    Und was hast du geändert?


    ch kann ohne Probleme pingen als auch meinen Traffic von zu Hause über den Wireguard-Tunnel durch den Windows Server dann ins Internet NATen.

    Ok. Damit ist Netcup dann auch raus, denn der Netzzugriff funktioniert ja offensichtlich.


    D.H. hier macht nur RDP Probleme.

    Dann musst du dort analysieren, woran es liegt. Läuft der Service, ist der Port offen, lauscht er auf dem richtigen Interface?


    OpenVPN allerdings funktioniert gar nicht mehr richtig, das Bild bleibt einfach weiß, keine Log-Einträge, nichts.

    Welches Bild? RDP?


    Vielleicht hat ja MS die NAT-Funktionalität in WinServer gestern kaputt gemacht?

    Oben hast du geschrieben, dass NAT funktioniert. Und für RDP brauchst du kein NAT.

  • Da du eben auch den Patchday erwähnst:


    Läuft denn überhaupt der Dienst?

    Bist du in den Einstellungen dafür überhaupt noch zugelassen bzw. ist es noch aktiviert?

    Hast du es denn mal über die öffentliche Netzwerkschnittstelle probiert?

    Sind noch andere Dienste erreichbar über den Tunnel?

    Meldet die Ereignisanzeige was?

  • Also die Dienste scheinen bei mir zu laufen, wo guckt man da genau nach im EventViewer?

    RDP aufs WAN könnte ich tatsächlich auch mal probieren.

    Andere Dienste betreibe ich nicht, wüsste daher nicht, was ich da gucken sollte.

    123.PNG


    frank_m Stimmt, NAT geht ja. Ich hatte aber die Rolle zuvor deinstalliert und da ging dann auch OpenVPN und RDP, sprich, vielleicht hat MS da irgendwas trotzdem verbockt...


    Wobei gerade lädt nicht mal der FF... die 2 Gigs RAM im kleinsten Paket sind natürlich nicht hilfreich.

  • Und was hast du geändert?

    Nichts. Jetzt gerade den VPS wieder neugestartet und es steht wieder "Internet Access" da, was Blödsinn ist. Der Wireguardtunnel endet bei mir at home an meiner pfSense und vom VPS ist eingehend gar nichts erlaubt, dementsprechend kann da auch kein Internet Access sein für den VPS...


    So von außen komm ich mit RDP auch nicht rauf, also endlich mal sicheres RDP unter Windows... :P

    • Hilfreichste Antwort

    Ich habe jetzt mal "Routing and Remote Access" deaktiviert und sowohl der FF startet, als auch RDP über WAN und WG ist möglich. D.h. in der Rolle scheint seit gestern das Problem zu liegen! Ich "brauche" nur das NAT und habe daher auch alles andere nicht angefasst, aber das scheint jetzt so nicht mehr zu funktionieren.


    Schuld ist der Patchday, wenn ich NATe, fangen die Probleme an, dann bricht die RDP-Verbindung ab und kann anschließend nicht mehr aufgebaut werden. Deaktiviere ich o.g. Rolle, läuft wieder "alles".

  • Heißt der Dienst wirklich "Routing and Remote Access"? Welche Windows Server Version verwendest du? Bekommt die noch Support?


    Schuld ist der Patchday,

    Das wage ich zu bezweifeln. Ich vermute eher eine falsche Konfiguration. Die von dir beschriebenen Probleme sind typisch für falsche Routen, überschneidende Subnetze usw. Da würde ich zunächst anfangen.

  • BobDig

    Hat einen Beitrag als hilfreichste Antwort ausgewählt.
  • BobDig

    Hat den Titel des Themas von „Seit gestern ist bei mir kein RDP mehr möglich über Wireguard - Windows Server auf VPS“ zu „WindowsServer19: nach Juni 22 Patchday kein NAT + RDP über VPN möglich“ geändert.
  • Es wäre nicht das erste Mal, dass ein Update einen Konfigurationsfehler aufdeckt, der vorher nicht auffiel. Aber bitte, du musst mit der Einschränkung leben.


    Vielleicht eine gute Gelegenheit, das Setup als ganzes noch mal zu überdenken.

  • frank_m Da ich keine Kenntnisse von Linux habe und auch nicht in der IT arbeite, sehe ich da schwarz. Warum ich einen Konfigurationsfehler ausschließe, das Ganze wird mittels eines Assistenten in Windows eingerichtet.


    Aber klar, wer sich einigermaßen auskennt, für den ist das 'n Klacks, das in Linux einzurichten und sicher die schlauere Wahl.

  • Es ist ein Irrtum, zu glauben, ein Windows Server sei leichter einzurichten, als ein Linux Server. Das Gegenteil ist der Fall, Windows ist erheblich komplexer und fordert Größenordnungen mehr Einarbeitungszeit, als Linux, um es sicher und funktional hinzubekommen. Wenn dein Argument wirklich ist, dass du dich in der IT nicht auskennst, dann ist ein Windows Server das letzte, womit du anfangen solltest. Das gilt insbesondere für Themen wie Routing und Firewall.

  • Die Firewall ist ja die gleiche wie in der Pro Version, von daher bin ich dann wohl bestens "eingearbeitet" als jahrelanger Windows Nutzer. Und Routing betreibe ich nicht wirklich, außer halt den besagten Assistenten zu nutzen, was erst seit letztem Patchday zu einem Problem geführt hat.


    Aber gut, glaub weiter was Du möchtest, eine Zweck erfüllt das Gelaber hier ja eh nicht mehr. Abo ist auch raus, also viel Spaß noch.


    PS: Ich nutze zu Hause sogar Hyper-V... 8o