Go-Global Deployments
Large-scale GO-Global deployments often extend far beyond Farm Hosts and Farm Managers. In enterprise environments, they typically operate alongside numerous supporting systems designed to enhance performance, reliability, and security. These systems — including firewalls, load balancers, web application firewalls (WAFs), reverse proxies, and monitoring tools — ensure that GO-Global applications remain accessible, resilient, and compliant with organizational standards.
This article provides detailed guidance on configuring GO-Global to function effectively within complex IT infrastructures that include such components. It explains how GO-Global interacts with each system, outlines configuration best practices, and highlights key considerations for administrators managing large-scale or cloud-based deployments.
Perimeter Firewall
When a GO-Global deployment is accessible from the internet, a perimeter firewall is generally the first line of defense against intrusions. Perimeter firewalls are typically configured to allow incoming connections on TCP port 443, which is the standard port for secure HTTPS/TLS traffic.
Since port 443 is the standard port for secure traffic, and since it is the port that is open on most corporate (client) firewalls, GO-Global clients that connect over the internet are typically configured to connect to port 443 instead of GO-Global’s standard port, 491. This is done by either adding the port in the URL (e.g., &port=443) or specifying the port in GO-Global’s logon.html page.
Web Application Firewall (WAF)
A Web Application Firewall (WAF) analyzes incoming HTTP requests to identify and block malicious requests. WAFs can also route traffic to different backend servers based on information in HTTP requests, but this is not their primary function. Their primary function is to provide security and protect against attacks such as distributed denial of service (DDoS) attacks.
Examples of WAFs include Cloudflare WAF, AWS WAF (Amazon Web Services), Azure Web Application Firewall, F5 Advanced WAF, Imperva WAF, Akamai Kona Site Defender, Fortinet FortiWeb, Barracuda WAF, and Radware WAF.
To analyze HTTPS traffic, WAFs must terminate the TLS so they can decrypt the requests. When TLS is terminated by a WAF, GO-Global’s tls parameter must be added to the client’s URL or it must be specified in GO-Global’s logon.html page.
Another consideration for GO-Global traffic is WAFs cannot analyze GO-Global’s proprietary RXP protocol. Therefore, when communication between a GO-Global client and host passes through a WAF, it must either be wrapped in HTTP requests by configuring GO-Global to use a Websocket, or the WAF’s data analysis features must be disabled for the GO-Global traffic.
All version 6.3.3 and later GO-Global clients support WebSockets. In GO-Global versions 6.3.2 and earlier, however, only the GO-Global Web App supports WebSockets. AppController, GO-Global’s native client, does not support WebSockets in version 6.3.2 and earlier.
If AppController version 6.3.2 or earlier is used with a WAF, the environment must be configured so the WAF does not inspect AppController’s traffic. This can be done, for example, by providing another endpoint (public address) for AppController connections that do not use the WAF, or by configuring AppController to connect on a different port and configuring the WAF to pass traffic on this port without inspecting it.
Reverse Proxy
Like WAFs, reverse proxies analyze incoming HTTP requests. Reverse proxies have some security features, but unlike WAFs, the primary function of reverse proxies is traffic management, not security. For example, reverse proxies are often used when multiple web applications and services are provided from the same public endpoint. They route incoming requests for different applications to their respective application servers. They can also be used as a load balancer for GO-Global Farm Hosts.
Examples of reverse proxies include, Nginx, Apache HTTP Server, HAProxy, Traefik, and Cloudflare. The AWS Application Load Balancer and Azure Application Gateway have various functions, one of which includes serving as a reverse proxy.
Like WAFs, reverse proxies must terminate the TLS so they can analyze incoming HTTP requests. As with WAFs, when TLS is terminated by a reverse proxy, GO-Global’s tls parameter must be added to the client’s URL or it must be specified in GO-Global’s logon.html page.
Like WAFs, reverse proxies cannot analyze GO-Global’s proprietary RapidX Protocol (RXP). Therefore, as with a WAF, when communication between a GO-Global client and host passes through a reverse proxy, it must either be wrapped in HTTP requests by configuring GO-Global to use a WebSocket, or the reverse proxy’s data analysis features must be disabled for the GO-Global traffic.
And as with a WAF, if AppController version 6.3.2 or earlier is used with a reverse proxy, the environment must be configured so the WAF does not inspect AppController’s traffic. This can be done, for example, by providing another endpoint (public address) for AppController connections that do not use the reverse proxy, or by configuring AppController to connect on a different port and configuring the reverse proxy to pass traffic on this port without inspecting it.
Web Server
GO-Global Hosts have an integrated web server that can host the GO-Global Web App and its supporting HTML and JavaScript files. When GO-Global’s integrated web server is used, HTTP requests for GO-Global’s web files are forwarded to GO-Global Farm Hosts on the internal network.
In internet deployments, however, there are security benefits to hosting GO-Global’s web files on a third-party web server located in the DMZ. Examples of third-party web servers include Apache HTTP Server, Nginx, and Microsoft IIS (Internet Information Services).
When a third-party web server is used, GO-Global’s Web App and associated files must be installed on the web server, either via the Host installer or by copying the contents of GO-Global’s Web directory to the web server.
While most third-party web servers have functionality to handle WebSocket connections, WebSocket connections are generally handled by a dedicated load balancer or reverse proxy. Administrators can configure WAFs and reverse proxies to route GO-Global’s HTTP requests to a web server and to route WebSocket connections to GO-Global Farm Hosts or to a load balancer.
Alternatively, when a WAF or reverse proxy is not used, administrators can create a different endpoint (address or port) for GO-Global’s WebSocket connections and specify this endpoint via the host and/or port parameters in the client’s URL or GO-Global’s logon.html page.
Network Load Balancer
When more than one Farm Host is needed, a load balancer is required to distribute user connections between the hosts. The load balancer can be a reverse proxy or a network load balancer.
In environments where multiple applications are accessed via a single internet endpoint, the perimeter firewall will typically forward connections to a reverse proxy (optionally via a WAF). The reverse proxy can then either forward the connections directly to Farm Hosts (balancing the load), or it can forward the connections indirectly to the hosts via a network load balancer.
Alternatively, in environments where GO-Global is the only application accessed via the internet endpoint, the perimeter firewall can forward connections on port 443 directly to a network load balancer. From there, the load balancer selects a Farm Host and forwards the connection to the Farm Host on the port specified in the Admin Console.
Unlike reverse proxies, network load balancers do not inspect traffic and route it based on the content of the data. They generally route traffic based on variables such as the destination port and source IP address. Examples of load balancers that can operate at layer 4 and route TCP connections (TLS is terminated at GO-Global hosts) are HAProxy, Azure load balancer, and AWS Network Load Balancer.
Some network load balancers can terminate TLS at the load balancer. If the load balancer is configured to terminate TLS, GO-Global’s tls parameter must be added to the client’s URL, or it must be specified in GO-Global’s logon.html page.
When a load balancer terminates TLS, it can optionally re-encrypt the data that it transmits to Farm Hosts. If the Farm Hosts are configured to use the TLS protocol, the load balancer must be configured to re-encrypt the data that it sends to Farm Hosts. Conversely, if the load balancer does not re-encrypt the data, GO-Global’s Protocol must be set to TCP and Encryption must be set to None.
When a network load balancer does not terminate TLS, it passes the data through to Farm Hosts without decrypting and re-encrypting it. In this configuration, the TLS protocol must be enabled on Farm Hosts, and the tls parameter must not be specified in the client URL or logon.html page.
Back-End Firewall
A back-end firewall may be used to limit access to Farm Hosts to specific front-end systems. For example, if reverse proxies are used to route connections to Farm Hosts, a back-end firewall may be configured to only allow the reverse proxies to connect to the Farm Hosts. In this example, the back-end firewall must be configured to allow the reverse proxies to connect to the Farm Hosts on the port specified in the Admin Console under Tools | Host Options | Security | Port (491, by default), and traffic must be allowed in both directions.
If the applications running on Farm Hosts must access the internet, then the back-end firewall must be configured to allow this access.
GO-Global Farm Hosts do not require access to the internet. If, however, GO-Global is activated using a cloud license, the APS on Farm Managers must be able to connect to portal.graphon.com and cloud.graphon.com on port 443.
Domain Controller
In the majority of deployments, Farm Hosts are members of a Microsoft Active Directory (AD) domain. In this environment, it is essential for Farm Hosts to maintain communication with their domain controllers. This connectivity enables them to authenticate accounts, retrieve user information and settings, load Roaming Profiles, and enforce Group Policies. In OpenID Connect deployments, customers are often required to configure constrained delegation on the AD computer objects of Farm Hosts.
Administration Firewall
An administration firewall may be used to limit users’ ability to access administration systems such as domain controllers and Farm Managers from Farm Hosts. For example, an administration firewall can be used to prevent users running applications on Farm Hosts from attempting to connect to domain controllers and Farm Managers using Remote Desktop.
If an administration firewall exists between Farm Hosts and Farm Managers, the firewall must allow Farm Hosts to connect to the Farm Managers on the port specified in the Admin Console under Tools | Host Options | Security | Port (491, by default), and traffic must be allowed in both directions.
If an administration firewall exists between Farm Hosts and domain controllers, the firewall must be configured to all communication on the ports that Windows uses to communicate between domain controllers and domain members. Refer to Microsoft’s documentation for this information.
Identity Provider
When OpenID Connect Authentication is used, Farm Hosts must be able to open connections to the identity provider via the Token URL specified in the Admin Console under Tools | Host Options | Authentication | Configure OpenID Connect Settings | Token URL.
Auto-Scaling Infrastructure
Cloud Service Providers (CSPs) such as Amazon Web Services (AWS), Microsoft Azure, Oracle Cloud, and Google Cloud (GCP) provide features that can be used to automatically start and stop Farm Hosts as the load rises and falls. When using these features, administrators generally create a base (“gold”) image of a Farm Host that can be replicated as needed to support the users connecting to the system.
Farm Host images have GO-Global installed and configured, as well as any applications that users will run on the Farm Hosts. Administrators typically automate the building of these images using a combination of PowerShell scripts and infrastructure code developed using an Infrastructure as Code (IaC) tool such as Terraform.
See Automating the Configuration of GO-Global on how GO-Global can be installed and configured programmatically.
Farm Host images typically have the addresses of their Farm Manager and Failover Farm Manager stored in the image. This makes scaling out (adding hosts to a farm) straightforward. When new host instances are started, they automatically connect to the Farm Manager, and the CSP’s auto-scaling feature generally takes care of adding the new instance into the load balancer’s target group.
Farm Hosts obtain licenses from their Farm Managers, so no licensing configuration is required when a new Farm Host instance starts. When sessions start on a Farm Host, the host checks out license seats from the Farm Manager. Generally, one seat is consumed for each concurrent session.
Scaling in (removing hosts from a farm) is generally a little more complicated than scaling out. This is because it is usually desirable to wait to shut down a Farm Host instance until all sessions running on it have been closed. Taking a Farm Host Offline describes how to do this.
When a Farm Host stops, the host’s connection to the Farm Manager is broken. When this happens, the Farm Manager automatically releases any seats that were in use on the host. As such, there is no risk that seats will be consumed by hosts that no longer exist. Nothing needs to be done to clear hosts that have been shut down; this is done automatically.
With GO-Global, the best metric to control auto-scaling is generally the number of running sessions. The number of sessions running on a host or a farm can be obtained, respectively from a Farm Host or Farm Manager via GO-Global’s Performance Counters or via GO-Global’s Get-GGSessions PowerShell function.
Availability Zones and Regions
To provide high availability, Cloud Service Providers (CSPs) support multi-datacenter deployments via availability zones and regions. Availability zones are one or more datacenters located within the same geographical region. CSP regions are geographical areas containing one or more availability zones. CSP Fault Domains, also known as availability groups, are fault tolerant resources located in physically separate parts of a single datacenter.
GO-Global supports deployments across multiple availability zones. The availability zones in which GO-Global is deployed may be located within the same CSP region or in different CSP regions.
Within a CSP region, GO-Global is generally deployed across at least two availability zones, with the primary Farm Manager running in one availability zone, and the failover Farm Manager running in a different availability zone. The Farm Hosts may run in any number of availability zones within the region, but they must be able to connect to both the primary Farm Manager and the failover Farm Manager.
When high availability across CSP regions is needed, or when users are located around the world, GO-Global may be deployed in multiple CSP regions with a DNS load-balancer such as AWS’s Route 53 routing client connections across the regions. The DNS load balancer can then be configured to support active-active or active-passive failover, as needed.
Monitoring and Observability Tools
Monitoring and observability tools are used to monitor the health of GO-Global deployments and raise alerts when issues arise. GO-Global provides several features that these tools can use to monitor GO-Global.
Most observability tools have features for ingesting log files. GO-Global’s log files are in HTML format, by default, which most observability tools do not support. Therefore, GO-Global must generally be configured to record its log files in text format when its logs will be ingested by an observability tool.
In addition to its log files, GO-Global records events in the Windows Application log. The events that GO-Global records in the Windows Application log include session starts and stops, user sign ins, and application starts and stops.
To support monitoring of Farm Hosts and Farm Managers, GO-Global provides a healthCheck request. The healthCheck request can be used to determine if the Application Publishing Service is running on a Farm Host or Farm Manager and, optionally, if the system is able to create a session. Load balancers, for example, can use the healthCheck request to check the health of Farm Hosts in their target group.
Systems that send healthCheck requests must be registered with each target Farm Host or Farm Manager. Specifically, the IP address of the system sending the request must be listed in CIDR format in the APIWhiteList property in the target system’s HostProperties.xml file.
In addition to these tools, GO-Global’s PowerShell API can be used to obtain detailed runtime information from Farm Hosts and Farm Managers. For example, the Get-GGSessions function returns information about the sessions running on a Farm Host or Farm Manager.
Conclusion
Deploying GO-Global in a large-scale or cloud-integrated environment requires careful coordination between multiple infrastructure components. By correctly configuring elements such as firewalls, load balancers, reverse proxies, and monitoring systems, administrators can achieve a secure, scalable, and high-performing GO-Global environment that delivers a seamless user experience.
Whether implemented on-premises, in the cloud, or across hybrid architectures, the principles described in this article ensure that GO-Global operates efficiently within modern enterprise networks — maintaining reliability, flexibility, and control at every layer of deployment.
Are you an ISV exploring cloud-based application delivery? Contact us to learn how GO-Global can help you streamline software access for your end users. Or download a free trial to test it yourself.
