Benefits of Using Public Cloud Gateways over Private Cloud Gateways

Introduction:  

This document aims to clarify the distinctions between the two types of remote Desktop Gateways utilized within Workspot.  

  1. Private Cloud Gateways. 

  1. Public Cloud Gateways. 

The Gateways are Windows server machines with a Remote Desktop Gateway role installed to ensure secure access to the Workspot Cloud desktops and applications over the internet.  

Both Private and Public cloud functionality is the same, to provide a secure connection. However, the major differentiator between the two is Observability and management and Workspot Integrated HA (High Availability) feature. 

Private Cloud Gateways: 

A Private cloud gateway also referred to as the Standalone Gateway server, requires manual end-to-end configuration. At a high-level the below steps need to be followed by an administrator to build a private gateway server: 

  • Deploy a Windows server OS.  

  • Install Remote Desktop Gateway roles. 

  • Join the Domain 

  • Install a valid certificate based on the Workspot Control Gateway URI. 

  • Configure Connection and Resource authorization policies. 

  • In case an IDP (Identity Provider) solution is required, manually install, and configure.  

  • Need to register to public DNS manually. 

  • Add the Gateway to the Control 

  • Set the firewall rules to access the gateway over the Internet. 

Reference link: Manually Configure a Gateway Server 

Public Cloud Gateways:  

Public Cloud Gateways are also commonly known as Workspot Managed Gateways. Gateways deployed in a cluster (a group of one or more identical servers) for high availability also allows ease of manageability. At present these Gateways are only supported on Cloud platforms like Azure, GCP & AWS. 

At a high-level, the below steps need to be done by an administrator to build a public gateway server from Control: 

  • Create a Cloud gateway Cluster from the Control 

  • Select & fill required details as per the need in the new cloud gateway cluster page. 

  • Click on Create and provide the required details and credentials.  

  • Click OK, the rest of the things will be taken care of by the Workspot Control and Agent.  

Please note: If the customer uses their own certificate on gateway, it must be installed manually and need to create a record with a Public DNS authority.  

This is how the public cloud deployment is taken care of by the Workspot Control and Agent: 

  • Cluster and Gateway entries will be made in the Control. 

  • Control will deploy Windows Server based on image selection in the selected region and network.  

  • Control will execute the script to download Workspot Agent and the required files. 

  • Agent will get installed and start communicating with the Workspot Control 

  • Agent takes care of certificate installation.  

  • Later Agent takes care of the following.  

  • Install Gateway roles. 

  • Configure Connection and Resource authorization policies. 

  • For AAD (Azure Active Directory) gateway or IDP solution, the Agent takes care of the configuration.  

  • Install the certificate (Default option - Daas20.net selected) 

  • Configure Redirection policy. 

  • OS Hardening 

  • Etc. 

  • Control also takes care of configuring Azure NSG (Network Security Group) and GCP/AWS security system rules required for connection. 

  • Once an Administrator changes the gateway status from Setup to Enable from the Control, during this step Control creates a record of Gateway URI on Public DNS. 

Refer for more details: Managed Gateways (Gateway Clusters)

Benefits of the Public Cloud Gateways:   

One of the primary distinctions between the Private and Public cloud gateways lies in the Workspot gateway Agent. Public Cloud gateways have a Workspot gateway agent installed, which helps in monitoring and management as we will be doing operational activities.  

N* Can be highly available through the Network appliance Load balancer at layer 4.