Gateways offer an added layer of security by encrypting all traffic to the servers and making all connections come through port 443 instead of 3389. The gateway also acts as a bouncer by making users authenticate with it before allowing them to proceed into the domain. The gateway has a separate set of policies which dictate who is allowed to access the environment as well as what resources people are allowed to access.
You will need a SSL certificate for the gateway server. Once enabled and configured, connections to the servers will change with a gateway. As previously mentioned, connections will now come in through port 443 to the gateway and authenticate against it first. Once the first layer of authentication is passed, the gateway will then forward the connection to the user session servers inside of the domain through ports tcp 3389 and udp 3391 as needed.
Enabling the Gateway
You can enable the gateway at the provisioning with the following slider:
There's also an option for redundant gateway that is ideal for larger deployments for redundancy purposes (you can use one SSL for both gateways).
If you enable the gateway, you will get a task to upload SSL certificate in .pfx format after the provisioning is finished.
If your deployment is already on cloud, you can enable the Gateway from the Deployment settings.
There are several types of SSL certificates that you can get: wildcards, standards or UCC certificates.
The one we recommend is the wildcard. in the event you already have one, this SSL can be used to protect unlimited* hostnames or first-level subdomains on an entire domain. Another reason we recommend wildcard is that you don't need to know the hostname before purchasing it.
Pro tip: If you own a wildcard SSL for your domain, you can use your own external domain when launching the deployments. The system will automatically create a subdomain with the 3 letter server code that is different for every deployment.
When launching a deployemnt with wildcard SSL for the gateway, don't put subdomain info to the External DNS Name field because the system will create a subdomain automatically. For instance, if your domain is example.com, put it as such. The DNS will be created as abc.example.com.
Standard SSL certificates will only protect a single hostname and you will need to know the hostname before purchasing.
In case you're considering a standard SSL for a gateway deployed in itopia, make sure you request it the following format: xxx.yourexternaldomain where XXX stands for the 3 letter server code of your deployment and it's followed by the external domain you provided when launching the deployement to cloud.
A UCC is a third option (also known as a SAN certificate) and they allow you protect multiple hostnames or different base domains on a single certificate, these are typically more expensive than both standard and wildcard certificates.
You can check here how to enable RD Gateway in itopia
Note: If you don't enable the gateway and you need to encrypt your connection, you'd have to install SSL certificate in every server separately.
Related articles: SSL certificate: .pfx export
*based on vendor specifications.