22.12.2023, aktualisiert um 20:16:25 Uhr

4451

RDP Zugriff auf Windows Server über VPN Wireguard

Guten Tag,

folgend Situation, ich möchte einen Windows-Server (2019) hinter einen MikroTik über VPN erreichen können. MikroTik ist direkt im RZ und über eine öffentliche IP zu erreichen.

VPN Verbindung (WireGuard) zu dem MikroTik klappt problemlos - Ping/ Winbox etc. alles kein Problem.

Ich kann aber NICHT von meinem PC auf den Windows Server zugreifen - weder RDP/ noch Ping - Ping zwischen MikroTik und Windows-Server klappt natürlich.

Wenn ich einen Torch auf das WireGuard-Interface des MikroTiks mache, sehe ich auch das die Pakete korrekt geroutet werden, bekomme aber KEINE Antwort vom Windows-Server.

Testweise eingerichtete Dest-Nat Verbindung per RDP über die öffentliche IP auf den Server klappen sofort.

Inzwischen vermute ich, dass der Windows-Server die Anfrage des PC`s über den VPN blockt. Kann das sein? Wie kann ich das feststellen/ beheben? Kenn mich da leider mit Windows nicht so aus.

Hier nochmal das Szenario:

Windows-Server (192.168.3.10) <-> MikroTik Router (192.168.3.1 | WG: 10.80.0.1 | 185.x.x.x) <-> PC (WG 10.80.0.2)

---

identische Konfigurationen mit diversen Linux-Servern hinter dem MIkrotik klappen problemlos. Steh da gerade echt auf dem Schlauch.

Herzlichen Dank & Ruhige Weihnachtstage!

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 5454815216

Url: https://administrator.de/contentid/5454815216

Ausgedruckt am: 15.11.2024 um 01:11 Uhr

16 Kommentare

Neuester Kommentar

Windows Firewall blocktt per Default ICMP / SMB etc. für ihm fremde Subnetze ... In den Firewall-regeln des Winblows freischalten in der Regel unter "Bereich => Remote IP Address" "Any" oder das WG Subnetz zusätzlich eintragen ...

# für ICMP und SMB kombiniert für alle Subnetze freischalten (AKA Datei- und Druckerfreigabe)
Get-NetFirewallRule -Group '@FirewallAPI.dll,-28502' -Direction Inbound | Get-NetFirewallAddressFilter | Set-NetFirewallAddressFilter -RemoteAddress Any  

Pj.

Zitat von @dirkschwarz:
identische Konfigurationen mit diversen Linux-Servern hinter dem MIkrotik klappen problemlos. Steh da gerade echt auf dem Schlauch.

Wenn die Konfiguration wirklich identisch wäre würde es auch mit Windows funktionieren, ich tippe ebenfalls auf die Windows Firewall.

/Thomas

@10138557388

dort komme ich mit den erweiterten Firewall-Einstellungen hin - richtig?

Noch eine Frage: muss ich das für jede Regel machen oder kann ich einen Netzwerkbereich (WG) grundsätzlich zum "internen" vertrauenswürdigen Netz hinzufügen?

Danke!

Zitat von @dirkschwarz:
dort komme ich mit den erweiterten Firewall-Einstellungen hin - richtig?

🙈

Noch eine Frage: muss ich das für jede Regel machen oder kann ich einen Netzwerkbereich (WG) grundsätzlich zum "internen" vertrauenswürdigen Netz hinzufügen?

Überall wo es eingeschränkt ist. Eigenes Subnetz ist nunmal eigenes Subnetz.
Der Mikrotik sollte mit seiner Firewall primäre regeln wer wohin darf.

Für ICMP (Ping) ist es z.B. HIER beschrieben.

wenn ich alles richtig verstanden habe - hier alle drei Remote Desktop Einstellungen für Domain, öffentlich aktivieren - richtig?

was ich aber nicht verstehe:

hier ist doch der ping ipv4 für alle, auch öffentlich, erlaubt....

Zitat von @dirkschwarz:

wenn ich alles richtig verstanden habe - hier alle drei Remote Desktop Einstellungen für Domain, öffentlich aktivieren - richtig?

Natürlich nur für das Netzwerk-Profil was gerade aktiv ist für dein Netz!

hier ist doch der ping ipv4 für alle, auch öffentlich, erlaubt....

Quatsch, das Alle ist das Netzwerk-Profil nicht das es von überall erlaubt ist, dazu musst du den Eintrag öffnen und unter Bereich anpassen!

mmmh -steht aber doch eigentlich auf "beliebige IP-Adressen"

Prüfe welches Profil du nutzt, dementsprechend muss auch die entsprechende Regel aktiv sein jede Regel hat ein zugeordnetes Profil ...

Im Zweifelsfall Firewall temp. ganz deakt. dann siehst du das es an der FW des Servers liegt wenn es dann klappt.

Bei den Remote Einstellungen die Einstellung "nur lokales Netzwerk" entfernen und auf deinem Router den RDP Port auf die IP deines Remote Servers umlenken.
So sollte es funktionieren.

Zitat von @A.Mehrl:
und auf deinem Router den RDP Port auf die IP deines Remote Servers umlenken.

Ohne RD Gateway und 2FA machen das nur noch Dummies die sich ihr Netzwerk verseuchen und den Server unbrauchbar machen wollen...

Da meine Serverfarm (mittlerweile die 3te) seit 1995 einwandfrei läuft, nie kompromittiert wurde, mach ich doch was richtig. Es gibt verschiedenste Möglichkeiten Systeme zu schützen. Nebenbei läuft mein Gateway auf dem RDP Server.
Außerdem dachte ich er will mal die Funktionalität seines Terminalservers testen und wenn er mal erreichbar ist das System wieder abzuschotten.

Zitat von @A.Mehrl:
Außerdem dachte ich er will mal die Funktionalität seines Terminalservers testen und wenn er mal erreichbar ist das System wieder abzuschotten.

Das hatte er bereits, stand im Eingangspost:

Testweise eingerichtete Dest-Nat Verbindung per RDP über die öffentliche IP auf den Server klappen sofort.

Sorry, habe ich überlesen.

so, falls es jemanden interessiert...

nachdem ich alles versucht habe - nichts hat zum Erfolg geführt - habe ich einen neuen Wireguard Klienten angelegt. Das wars - alles klappt wie gewünscht. Das Netzwerk hinter dem Wireguard Server ist problemlos zu erreichen.

Nochmal zur Klarheit - mit den "alten peers" lies sich problemlos eine WireGuard Verbindung herstellen, ein Zugriff auf den Router war problemlos möglich, nur das Netzwerk dahinter war "tot". Falls mal jemand dieses Problem hat - einfach mal eine neue Peer erstellen und testen.

Wunder der Computertechnik - wie soll man darauf kommen?!

Noch einen schönen Abend & Danke für die Hilfe!