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:
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.
RDP-Verbindung zu den Servern funktioniert. Gleiche Einstellungen, gleiche GPO.
Hat Microsoft bei Windows 11 beim RDP mal wieder irgendwas kaputt gemacht?
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: 21.11.2024 um 16:11 Uhr
15 Kommentare
Neuester Kommentar
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!!
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!!
Eventuell mal UDP deaktivieren, wobei das eigentlich erst im Laufe der Verbindung Probleme macht:
https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policie ...
https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policie ...
Zitat von @anteNope:
Bei ESET gab es aber eine kleine aber wichtige Änderung beim letzten Update (v11.1).
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
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.
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.