Remotedesktop funktioniert nur im eigenen Subnetz?

Moin zusammen,

ich verzweifel hier gerade etwas ...

Bei meinen Kunden habe ich eine GPO definiert die RDP aktiviert und den Port in der Firewall öffnet. Das funktioniert soweit auch wunderbar, bislang ...

Heute ist mir aufgefallen, dass zu manchen PC keine Verbindung via RDP möglich ist. Die GPO wird angewendet, RDP ist aktiviert, Firewall geöffnet. Trotzdem keine Antwort auf eine RDP-Anfrage.

Die Lösung hierfür war wie folgt:

* HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
* HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services

Wenn der Schlüssel fDenyTSConnections den Wert 0 hat, ist RDP aktiviert.
Wenn der Schlüssel fDenyTSConnections den Wert 1, ist RDP deaktiviert.

Interessanter Weise stand der erste Wert auf 1, aber nicht bei allen sondern nur man manchen PCs. ¯\_(ツ)_/¯
Ich kann jetzt vom lokalen Subnetz wieder auf alle PCs via RDP zugreifen! 😎

So nun gibt es auch ein paar Leute die im Homeoffice sind und via WireGuard auf ihren PC via RDP zugreifen wollen.

Tunnel wird aufgebaut
Ping an den/die Rechner funktioniert
RDP-Verbindung schlägt jedoch fehl

RDP-Verbindung zu den Servern funktioniert. Gleiche Einstellungen, gleiche GPO.
Hat Microsoft bei Windows 11 beim RDP mal wieder irgendwas kaputt gemacht?

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

Content-ID: 668469

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

Ausgedruckt am: 03.10.2024 um 06:10 Uhr

14 Kommentare

Neuester Kommentar

War es evtl nur in einem der drei Firewall Profile, wo der Port geöffnet wurde?

Selbst mit komplett deaktivierter Firewall funktionieren nur Verbindungen die aus dem eigenen Subnetz kommen ...

Hallo,

dann muss ich jetzt mal die "Edge-Ausnahme" für die Firewallregel in den Raum werfen.

cya

Standardgateway am Client und
Firewall/Routing im Router
stimmen?

Zitat von @gammelobst:
dann muss ich jetzt mal die "Edge-Ausnahme" für die Firewallregel in den Raum werfen.

Das habe ich auch schon probiert. Keine Änderung. Sollte aber bei deaktivierter Firewall keine Auswirkungen haben ...

Zitat von @NordicMike:
Standardgateway am Client und
Firewall/Routing im Router
stimmen?

Auch das habe ich geprüft. Die erreichbaren Server haben die gleiche Konfiguration.

IPv6 aktiv? Hat ja immer Vorang wenn du per Hostnamen drauf zugreifst statt mit einer dedizierten v4 IP.
In der Firewall (wenn aktiv) muss man natürlich auch die Absender IPs ("Remote Adresse") freigeben oder zu mindestens statt "Beliebig" die dedizierten Absender IP Netze ("Diese IP-Adressen") angeben. (Hier am Beispiel ICMP/Ping)

Andere Option ist ggf. ein Regelwerk oder Accessliste des Routers o. Firewall der diese Netze routet und Port 3389 aus Fremdnetzen ggf. blockiert. Wireshark ist hier, wie immer, dein bester Freund!!

Er schrieb dass es auch bei deaktivierter Firewall so wäre.

Eventuell mal UDP deaktivieren, wobei das eigentlich erst im Laufe der Verbindung Probleme macht:
https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policie ...

Subnetmask ist aber korrekt?

Auch mit falscher SNM klappt es im gleichen Netz. Von anderen sieht es dann schon anders aus... So etwas triviales vlt. ?

Ursache gefunden 😑
Bei Windows ist alles okay, auch die Einstellungen, GPO und alles andere.

Bei ESET gab es aber eine kleine aber wichtige Änderung beim letzten Update (v11.1).
Beim IDS werden nun RDS-Verbindungen geblockt! Im Standard steht das auf "Sichere Zone" und es gibt diverse Presets ...

Und ja das betrifft auch Produkte bei denen keine Firewall enthalten ist. Der IDS reicht ...
Ist zudem der erste Kunden bei dem die neuste Version drauf ist.

Zitat von @anteNope:

Bei ESET gab es aber eine kleine aber wichtige Änderung beim letzten Update (v11.1).

Mal wieder ESET. Letztens hat ein ESET-Update davidfx gekillt. Erst deinstallieren von ESET hat geholfen.

lks

Wenn ein deinstallieren von Eset ausreicht, hat er David Dateien in Quarantäne gesteckt. Das kann mit jedem Antivirus passieren. In solchen Fällen dann die David Ordner vom Scan ausschließen.

Zitat von @NordicMike:

Wenn ein deinstallieren von Eset ausreicht, hat er David Dateien in Quarantäne gesteckt. Das kann mit jedem Antivirus passieren. In solchen Fällen dann die David Ordner vom Scan ausschließen.

Ach nee. Was glaubst Du, was in den Ausnahmen drinstand. Jedenfalls wurde der David Service Layer nach kurzer Zeit immer er wieder beendet. Auch der behelfsmäßige "Fix", den Dienst bei Fehler sofort wieder zu starten, hat kaum geholfen, weil ihn irgendwas gekillt hat. In Eset waren überhaupt keine Meldungen, das er was böses gefunden hätte. Meine Vermutung ist, daß eset irgendwelche hooks im Windows verstellt hat und daß das einen Fehler im Service layer verursacht hat und der Dienst auf eine exception lief, die nicht abgefangen wurde,

Und auch wenn das prinzipiell bei jeden Schlangenöl auftreten kann, so ist mir aufgefallen, daß in meinem "Dunstkreis" eset besonders oft trifft

lks

Ps: eset Deaktivieren selbst hat nicht geholfen. Es ist nur nach langer Ursachensuche in den logs aufgefallen, daß der Servicelayer von David ab dem Zeitpunkt gesponnen hat, ab dem ein eset ein Update eingespielt hat.