none
Ports / Proxy für RDS Gateway RRS feed

  • Frage

  • Hallo und schönen Abend Zusammen,

    mich würde interessieren ob ich bei einem Zugriff über das RDS Gateway von Windows 2012R2 , außer dem Port 443, noch irgendwelche anderen offenen Ports benötige?

    Unglücklicherweise steht im internen Netz auch noch ein Proxy im "Weg", ich habe keinerlei Einfluss auf Firewall und Proxy, daher der Ansatz alles über 443 zu "tunneln".

    Hab ich das richitg verstanden oder bin ich auf dem Holzweg? 

    EDIT:

    Hab das jetzt mal gebaut, von meinem Netz aus kann ich das Remotegateway erreichen und die Sitzung aufbauen.

    Dann hab auf der Firewall nur noch http, https und dns zugelassen, RDG Seite geht auf ich kann den freigeben RDP Desktop starten, passwort abfragen dann bleibt hängen Verbindung wird initiert.

    Im Firewall Log sehe ich das mein Client auf die interen IP des Terminalserver (192.168.112.10) mit port 3389 zugreifen möchte. HIer geht es dann nicht weiter. Muss ich in meiner RDS konfiguration waas ändern? Scheinbar baut er ja Verbindung auf, nutzt aber dann den "flaschen" Port.

    Vielleicht habt Ihr ja Tip

    Beste Grüße

    Michael Sörgel


    Freitag, 1. Mai 2015 15:48

Antworten

  • Hallo,

    Anscheinend, nach den Screenshots, nutzt er das RDGW. Allerdings kann es immer noch sein, dass der Client den RDGW bei lokalen Adressen umgeht.

    Am einfachsten kann man das sehen wenn du auf dem entsprechenden Server mal die Konfig checkst, oder du dich mal mit einem anderen Browser an der RDWeb Seite anmeldest, dort die RDP Datei aufmachst (Editor) und dir dort anschaust was dort drin steht.

    Es gibt in der .rdp Datei eine Zeile "gatewayusagemethod:i:", der Wert dort muss 1 sein, wenn eine 2 drinsteht wird der RDGW innerhalb der Domäne umgangen und die RemoteApp Konfig auf dem Server ist nicht korrekt.


    freundliche Grüße Thomas

    Montag, 4. Mai 2015 08:19

Alle Antworten

  • So wie das aussieht, verwendest du beim Verbinden kein Gateway, sondern der Client versucht sich direkt zu connecten, da ja 3389 protokolliert wird.

    Der RDGW und die Sessionhosts müssen schon miteinander kommunizieren können, RDP und WMI. Aber von aussen Verbindest du dich auf das RDGW:443, der Authentifiziert dich und baut eine Session via 3389 zu dem Sessionhost auf, dein Client zeigt dir alles an. Der RDGW fungiert quasi als Reverseproxy, alles über 443.


    freundliche Grüße Thomas

    Samstag, 2. Mai 2015 20:38
  • Hallo  Thomas,

    danke für die Antwort. Hmm irgenwas hab ich dann falsch gemacht.

    Habe mich and ie Anleitung gehalten:

    https://msfreaks.wordpress.com/2013/12/09/windows-2012-r2-remote-desktop-services-part-1/

    nur ohne den SQL da ich probleme hatte den auf dem DC zu installieren was nicht supported ist, und iene 3. Maschine wollte ich nciht aufmachen (wenns notwendig ist dann kann ich aber tun ist eh alles auf nem Hyper-V).

    Zeritfikat hab ich mir erst mal 30 Tage Test geholt das klappt auch.

    Kann die URL aufrufen und den Remote Desktop starten von aus der Webseite nur dann benutzte er den Port 3389, Idee was ich da umstellen muss?

    Ok er meckert dann noch mla wegen dem Zertifikat, da steht der "faksche" Name in der GDGW Konfig - kann ich nicht abändern.

    Vielen Dank für euere Hilfe!

    Beste Grüße

    Michael Sörgel

    Sonntag, 3. Mai 2015 18:20
  • Hallo,

    Anscheinend, nach den Screenshots, nutzt er das RDGW. Allerdings kann es immer noch sein, dass der Client den RDGW bei lokalen Adressen umgeht.

    Am einfachsten kann man das sehen wenn du auf dem entsprechenden Server mal die Konfig checkst, oder du dich mal mit einem anderen Browser an der RDWeb Seite anmeldest, dort die RDP Datei aufmachst (Editor) und dir dort anschaust was dort drin steht.

    Es gibt in der .rdp Datei eine Zeile "gatewayusagemethod:i:", der Wert dort muss 1 sein, wenn eine 2 drinsteht wird der RDGW innerhalb der Domäne umgangen und die RemoteApp Konfig auf dem Server ist nicht korrekt.


    freundliche Grüße Thomas

    Montag, 4. Mai 2015 08:19
  • Hi Thomas,

    das wars! Danke jetzt scheint zu klappen - werde jetzt versucehn ausdem Produktivnetz heraus zuzugreifen, hoffe klappt. Andernfalls hässlich, da es ein großer Organisatorischer Aufwand sein wird Änderunen an der Firewal/Proxy anzufordern.

    Danke und beste Grüße!

    Michael Sörgel

    Montag, 4. Mai 2015 13:02