Remotedesktopgateway auf anderem Port
Ansprechen eines RDP-Gateways, wenn Port 443 (extern) belegt ist.
Hallo Zusammen,
ich habe eine Frage zur Konfiguration des Remotedesktopgateway.
Folgende Situation:
Mittelgroßes AD-Netz (alle Server W2K8R2) u.a. zwei Hyper-V Server.
Internetanbindung BK (100/5MBit, eine externe IP, leider nur dynamisch) an Securepoint UTM-Firewall.
Externe IP über intranet.firma.de erreichbar.
Es soll (zunächst nur zur Eprobungszwecken) der Remotedesktopgateway eingeführt werden.
Hierfür wurde ein virtueller W2K8R2 exklusiv zur Verfügung gestellt.
Mein erster Ansatz ist nun: Remotedesktopdienste und -Gateway installieren, durchkonfigurieren, und gut.
Die erste Frage anbei: Sitzunghost und Gateway auf gleichem Server möglich?
(Sicherheitsfrage ist bei der Erprobung erst noch sekundär)
Jetzt kommt aber das Problem:
Im Unternehmen wird bereits Exchange mit OWA, etc. eingesetzt.
Die Firewall leitet Port 443 hierfür an den Exchange weiter.
(https://intranet.firma.de/OWA) funktioniert ganz normal)
Da nur eine externe IP verfügbar ist, ist demnach auch nur ein externer 443 verfügbar, der ist aber belegt.
Für diese Eprobung darf die aktuelle Konfiguration nicht geändert werden.
(RDP-Gateway mit auf dem Exchange oder ein ISA davor der per Header weiterleitet ist also nicht möglich)
Der RDP-Gateway muss also irgendwie "extern" von 443 runter.
Meine Überlegungen wären
A: Das gesamte RDP-Gateway-System auf einen anderen, freien Port legen.
B: Nur extern einen anderen Port nehmen und intern durch die Firewall auf 443 des neuen Servers umleiten lassen.
Hat hier jemand Erfahrungen oder Tipps?
(Man müsste ja mindestens den Port im RDP-Client eintragen - geht das?)
Vielen Dank und schöne Grüße,
Jan
P.S.: Was ich bisher gegoogelt habe deutet darauf hin, dass zumindest A nicht geht, direkt einen anderen Port für RDP-Gateway einstellen soll wohl erst in Server 8 kommen
Hallo Zusammen,
ich habe eine Frage zur Konfiguration des Remotedesktopgateway.
Folgende Situation:
Mittelgroßes AD-Netz (alle Server W2K8R2) u.a. zwei Hyper-V Server.
Internetanbindung BK (100/5MBit, eine externe IP, leider nur dynamisch) an Securepoint UTM-Firewall.
Externe IP über intranet.firma.de erreichbar.
Es soll (zunächst nur zur Eprobungszwecken) der Remotedesktopgateway eingeführt werden.
Hierfür wurde ein virtueller W2K8R2 exklusiv zur Verfügung gestellt.
Mein erster Ansatz ist nun: Remotedesktopdienste und -Gateway installieren, durchkonfigurieren, und gut.
Die erste Frage anbei: Sitzunghost und Gateway auf gleichem Server möglich?
(Sicherheitsfrage ist bei der Erprobung erst noch sekundär)
Jetzt kommt aber das Problem:
Im Unternehmen wird bereits Exchange mit OWA, etc. eingesetzt.
Die Firewall leitet Port 443 hierfür an den Exchange weiter.
(https://intranet.firma.de/OWA) funktioniert ganz normal)
Da nur eine externe IP verfügbar ist, ist demnach auch nur ein externer 443 verfügbar, der ist aber belegt.
Für diese Eprobung darf die aktuelle Konfiguration nicht geändert werden.
(RDP-Gateway mit auf dem Exchange oder ein ISA davor der per Header weiterleitet ist also nicht möglich)
Der RDP-Gateway muss also irgendwie "extern" von 443 runter.
Meine Überlegungen wären
A: Das gesamte RDP-Gateway-System auf einen anderen, freien Port legen.
B: Nur extern einen anderen Port nehmen und intern durch die Firewall auf 443 des neuen Servers umleiten lassen.
Hat hier jemand Erfahrungen oder Tipps?
(Man müsste ja mindestens den Port im RDP-Client eintragen - geht das?)
Vielen Dank und schöne Grüße,
Jan
P.S.: Was ich bisher gegoogelt habe deutet darauf hin, dass zumindest A nicht geht, direkt einen anderen Port für RDP-Gateway einstellen soll wohl erst in Server 8 kommen
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 187042
Url: https://administrator.de/forum/remotedesktopgateway-auf-anderem-port-187042.html
Ausgedruckt am: 23.12.2024 um 09:12 Uhr
7 Kommentare
Neuester Kommentar
Naja - dann gibts ja nur die möglichkeit des zweiten Ports... Da hast du natürlich den Spass das du jedem erklären musst wie er sich daran verbindet - und dazu noch die ganzen Script-Kiddys...
Was spricht denn gegen nen VPN? Das Externe darauf zugreiffen sollen ist ja nix ungewöhnliches für VPN (lass mich kurz nachdenken - ich würde fast soweit gehen und sagen dass das genau der SINN eines VPN ist!). Wenn du es Firewalltechnisch jetzt noch etwas klug anstellst - dann darfst du aus dem VPN nur genau einen Server erreichen (dein RDP).
Das mit dem zweiten Programm ist auch falsch - jedes normale System bringt eine VPN-Software mit (sei es MS Windows, Apple iPhone/iPad, Linux, Mac,...). Jetzt brauchst du also nur noch die Verbindung einrichten - und ich denke das nen zweiter Klick (falls du Benutzername/PW speichern lässt) auch für nen DAU verständlich. Und sollte euer externer Dienstleister es nicht schaffen - nun, dann würde ich sagen ist es der falsche Dienstleister.
Für mich führt an einem VPN nix vorbei wenn man interne Server auch externen zugänglich machen soll.. Diverse Angriffe haben gezeigt das es zu oft vorkommt das doch noch ne Lücke da war und schon ist der Server weg...
Was spricht denn gegen nen VPN? Das Externe darauf zugreiffen sollen ist ja nix ungewöhnliches für VPN (lass mich kurz nachdenken - ich würde fast soweit gehen und sagen dass das genau der SINN eines VPN ist!). Wenn du es Firewalltechnisch jetzt noch etwas klug anstellst - dann darfst du aus dem VPN nur genau einen Server erreichen (dein RDP).
Das mit dem zweiten Programm ist auch falsch - jedes normale System bringt eine VPN-Software mit (sei es MS Windows, Apple iPhone/iPad, Linux, Mac,...). Jetzt brauchst du also nur noch die Verbindung einrichten - und ich denke das nen zweiter Klick (falls du Benutzername/PW speichern lässt) auch für nen DAU verständlich. Und sollte euer externer Dienstleister es nicht schaffen - nun, dann würde ich sagen ist es der falsche Dienstleister.
Für mich führt an einem VPN nix vorbei wenn man interne Server auch externen zugänglich machen soll.. Diverse Angriffe haben gezeigt das es zu oft vorkommt das doch noch ne Lücke da war und schon ist der Server weg...
port fuer die dienste in der fw auf 40000+ legen und mit nat umleiten.
danach mit nem nmap scan oder deinem scanner der wall ;) ueberpruefen
am besten in der fw nur die externe- hoffentlich feste ip- freigeben
durch das nat brauchst du keine internen ports aendern
der rdp port kann in der registry fuer den server angepasst werden.
und als client kann man auch einen anderen port angeben.
-nachtrag
wieos port 443? rdp ist normalerweise tcp port 3389
443 ist https...hat nix mit rdp zu tun
danach mit nem nmap scan oder deinem scanner der wall ;) ueberpruefen
am besten in der fw nur die externe- hoffentlich feste ip- freigeben
durch das nat brauchst du keine internen ports aendern
der rdp port kann in der registry fuer den server angepasst werden.
und als client kann man auch einen anderen port angeben.
-nachtrag
wieos port 443? rdp ist normalerweise tcp port 3389
443 ist https...hat nix mit rdp zu tun