#Server 2016 remote desktop port redirect install#
Our first step is to install RD Gateway role. In the internal firewall it’s not so bad because it’s just from the Remote Desktop Gateway to all of these ports. The idea is that very few ports need to be opened up in the external firewall because we want to make as small a hole as possible for the client to come in. So a lot of ports have to be opened up in those firewalls for the communication to go back and forth. If you’re using RADIUS or RADIUS Accounting, you need ports 1812 or 1813. Port 21 –> for FTP to contact the CRL, unless you’re using HTTP for the CRL
RDP 3389 –> so that the RD Gateway can forward RDP packets from the client TCP & UDP 389 –> which supports LDAP, which is also used to talk to Active Directory to authenticate the user. TCP 135 –> RPC Endpoint Mapper so we can communicate with Active Directory. TCP 88 –> for Kerberos, which is the Active Directory Authentication protocol. On your internal firewall you need to open up: UDP 3391 –> When using Server 2012 and above you also have to open up this port which allows the transport to create that connection. TCP 443 –> to allow HTTPS traffic to the RD Gateway. On the external firewall you have to open up: You also have to open up a number of firewall ports. The requirements for an RD Gateway, first of all, it must be joined to the domain because it has to authenticate and authorize corporate domain users and resources.
And then once it’s connected to the connection broker it gets passed along to the Remote Desktop Session Host, but remember RD Gateway remains the middle-man. Now the RD Gateway always continues to proxy a communication, so that communication comes in over HTTPS, the RD Gateway strips away the HTTPS and then makes the connection to the connection broker using the Remote Desktop Protocol, and that proxying continues to happen for the entire conversation. Because UDP is used to set up the transport, you’re going to have to open up a UDP port in the external firewall so that you can get the connection made to the RD Gateway. The Gateway sits in the middle, so historically the idea was that all the traffic going between the Gateway and the client is done using HTTPS SSL, which means we only have to open port 443 in the external firewall. Then, once all that’s been verified, the Remote Desktop Gateway passes the connection to the Remote Desktop Connection Broker, which in turn connects the client to the Remote Desktop Session Host. They are authenticated by the Gateway, and the Gateway makes sure that they have permissions to access internal resources. The external user connects to the Remote Desktop Gateway. So when we deploy Remote Desktop Gateway, this is a server that sits usually in a DMZ or a perimeter network that acts as a middle-man.
Remote Desktop Gateway is a very important component of the RDS deployment, because if we go with a traditional remote desktop scenario, the external user would connect through the firewall to the connection broker, which would then pass them on to the Remote Desktop Session Host, which means the first place the user gets challenged for credentials is at the Remote Desktop Session Host, at which point they’re well inside the company network.
0 kommentar(er)
