Streaming Gateway Appliance on Public Cloud or non-AHV Infrastructure¶
The Nutanix Frame Streaming Gateway Appliance (SGA) is a secure reverse proxy that supports the Frame Remoting Protocol (FRP). The SGA allows organizations to securely grant users access to virtualized applications and/or desktops without requiring a VPN. This guide is intended for customers who wish to install and configure the SGA in public cloud or non-AHV (e.g., ESXi) infrastructure.
Note
For customers who are using public cloud infrastructure, they can avoid the manual deployment of the SGA and use the Create Frame Account with Private Networking and SGA feature to automatically provision a Frame account with private networking and SGA. Refer to the documentation for further details. You must manually deploy an SGA if you wish to leverage the same SGA VM(s) for more than one Frame account or you wish to use an existing load balancer.
Note
Before an SGA can be deployed, the customer must have an established Frame customer or organization entity with a registered public cloud account or AHV Cloud Account, plans to deploy the SGA in a DMZ network on public cloud or non-AHV infrastructure, and has at least one existing Frame account already created.
SGA Network Architecture¶
To deploy an SGA, the company’s network must allow Internet traffic to reach the SGA VM in the DMZ on tcp/443 (HTTPS and Secure WebSockets) and from the SGA VM to the network containing the Frame-managed workloads (e.g., Sandbox, production pools, Utility Servers). The SGA VM or VMs (if high-availability is required) are assumed to be deployed in a DMZ which is separate from the workload network. This is illustrated in the following diagram for public cloud infrastructure:

Please consult the network protocol and port summary for SGA in Public Cloud with Private Networking to ensure that network routing requirements are satisfied before continuing.
Prerequisites¶
The following prerequisites must be met before starting SGA installation and configuration on public cloud or non-AHV infrastructure:
You have a working Frame account with at least one production pool of VMs in a workload network (e.g., VPC, VNET, or VLAN). The workload network has a non-overlapping CIDR block for routing between the SGA network and the workload network.
You have have configured the SGA network with a non-overlapping CIDR block.
Download the
nginx.conf.j2
andgen_proxy_config.py
.
Overview¶
Setting up a Streaming Gateway Appliance on a Frame account consists of 6 major steps to be performed by the customer. A 7th step is performed by Nutanix Support to finalize the setup.
Define the subdomain name (e.g., sga.company.com) and corresponding public IP address for the SGA. |
|
Obtain the SGA public key certificate. |
|
If no DMZ network exists, create a separate DMZ network with a non-overlapping DMZ CIDR block for the SGA VM(s). |
|
Create and configure the SGA VM(s) in the DMZ network. |
|
Configure the firewall (including NAT if required) and routing to enable HTTPS requests from the Internet to reach the SGA VM(s) in the DMZ network, and traffic originating from the SGA VM(s) to reach the workload network containing the Frame-managed workloads. |
|
Add the SGA subdomain as a wildcard DNS entry with the corresponding public IP address to the public DNS server. |
|
Nutanix Support configures the Frame Platform entry for the SGA subdomain for the Frame account. |
Additional Information¶
Installation and Configuration¶
Step 1: Define the SGA subdomain and corresponding public IP address
End users’ browsers must be able to reach the SGA from the Internet. Since the SGA will be deployed behind your organization’s firewall, the end users’ HTTPS requests and Secure WebSocket connections (for streaming) must be able to resolve to a public IP address on the your organization’s firewall. From that public IP address on your organization’s firewall, the request would need to be forwarded to the private IP address of the SGA and then from the SGA to the workload VMs.
Each Frame-managed workload VM will have an FQDN based the SGA subdomain. Consequently, the SGA subdomain will need to be configured as a wildcard DNS A record. For example, a company would need to make sure that:
*.sga.company.com
resolves to the public IP of the SGA.The public IP address of the SGA is network address-translated to the private IP address of the SGA by the firewall.
Step 2: Obtain an SGA public key certificate
Generate the wildcard SSL certificate signing request and corresponding private key for the subdomain chosen in the previous step. If this SGA is intended for use in a production environment, please obtain a public wildcard certificate or Subject Alternate Name (SAN) certificate from the certificate authority of your choice. If the SGA is to be used for testing or a proof of concept environment, a free public wildcard certificate can be obtained from LetsEncrypt
Warning
Be aware that free Let’s Encrypt certificates have a ninety-day lifetimes.
The SSL certificate must match the DNS subdomain record. For example, if the wildcard SSL certificate is *.sga.company.com
, then the DNS subdomain A record must be *.sga.company.com
(and not company.com
).
Step 3: Create the DMZ network
If a DMZ network does not exist, then create a network (e.g., VPC, VNET, or VLAN) that will contain the SGA VM(s). The CIDR block must not overlap with the Frame workload network CIDR block (and any other CIDR blocks that traffic is to route to).
Note
The CIDR must be between /18 and /24
Step 4: SGA VM Creation
Follow the setup tasks below to configure the Streaming Gateway Appliance.
Step |
Description |
Details |
|
---|---|---|---|
1 |
Create a CentOS Virtual Machine: |
For public cloud infrastructure, CentOS images can be obtained from AWS, Azure or Google Cloud Platform Marketplace/Store. Be sure to accept the CentOS 7.x User Agreement, if required by the public IaaS provider, before provisioning the CentOS virtual machine. |
|
2 |
Enable SSH access: |
Customer enables SSH access in the CentOS VM in order to reach the SGA console. Consult with AWS, Azure, or GCP documentation on how to enable SSH access to the CentOS VM. |
|
3 |
Upload files: |
Upload the following files into the CentOS VM in the /home/<user> directory:
|
|
4 |
Install epel-release, nginx, python, iptables and jinja: |
Execute the following commands on the command line:
|
|
5 |
Configure NGINX: |
Execute the following commands on the command line to configure NGINX.
|
|
6 |
Disable SELinux: |
Edit /etc/sysconfig/selinux to disable SELinux.
|
|
7 |
Configure SGA: |
Execute the following two commands to configure SGA and restart NGINX. Make sure that the CIDR corresponds to the Frame account network CIDR.
|
Step 5: Configure Routing to the Workload VMs via the SGA
To ensure external users can reach the SGA and therefore the workload VMs in the private network, verify the following:
The firewall should be configured to forward port 443 from your SGA public IP address to the SGA private IP address.
The network that contains the SGA must forward port 443 from the SGA to the workload network.
Step 6: Add SGA subdomain and associated public IP address in public DNS
Create an address (A) record in your public Domain Name Server associating your SGA subdomain with your SGA public IP address.

Step 7: Submit a Support Case
To associate your Frame account(s) with your SGA, submit a support case through the Nutanix Support Portal. Provide the following information in the support ticket:
Customer name
Organization name
Account name(s)
Wildcard subdomain
SGA public IP address
SGA Sizing Recommendations¶
Organizations can start with a VM configuration of 2 vCPUs and 4 GB RAM for the SGA. A 2 vCPU VM is able to process ~1 Gbps bandwidth of Frame Remoting Protocol data. Nutanix recommends a sizing target of 500 Mbps per 2 vCPUs to allow users to burst their bandwidth consumption.
The total number of concurrent users for the 500 Mbps bandwidth per 2 vCPU budget is dependent on the bandwidth consumed for the Frame sessions. Bandwidth consumption may be estimated based on user workload profiles:
1 Mbps per Frame session for office productivity applications, CPU-only VMs, under 30 fps, 2K or less monitors
5 Mbps per Frame session for CAD applications, GPU-backed VMs, up to 60 fps, 2K or less monitors
10 Mbps or greater per Frame session for video editing/animation/sustained playback, GPU-backed VMs, up to 60 fps, 2K or less monitors
In an office productivity use case, for example, where CPU-only VMs are used with standard 1920 x 1080 displays, the default (2 vCPU, 4 GB RAM) VM configuration could support 500 concurrent users. For 1,000 concurrent users, the same organization would need to leverage at least a 4 vCPU, 8 GB RAM VM. An 8 vCPU, 16 GB RAM VM could support 2,000 concurrent users for this use case.
SGA High-Availability¶

The SGA can be configured for redundancy using a L2 to L4 load balancing solution. The recommended solution is comprised of two (2) Load Balancers, physical or virtual, creating a single inbound load balancer virtual IP address (LBVIP) balancing two (2) Streaming Gateway Appliances. The load balancing solution must have the following configured:
SSL Passthrough
Persistent Traffic to LBVIP1 or LBVIP2
Wildcard DNS entry to LBVIP
User Flow Example:
A Frame user logs in to the Frame Platform via their normal method. When the user clicks the desktop or application requested, Frame Platform directs the user’s browser to an FQDN based on the SGA subdomain, as configured by Nutanix Frame Support, for the Frame account.
For example, if the subdomain was sga.company.com
and the workload VM had a private IP address of 10.2.1.3, the workload FQDN would be 10-2-1-3.sga.company.com
. This FQDN points to the inbound LBVIP and the Application Load Balancer decides which SGA to send the traffic to.
SGA for Multiple Frame Accounts¶
An SGA can configured to serve as the reverse proxy for multiple Frame accounts. Use the steps below to configure your SGA for multiple Frame accounts:
Configure the memory and vCPU using the SGA sizing recommendations above on your SGA to account for scaling up.
Log in to the SGA as: nutanix, nutanix/4u
SSH into your SGA or use the AHV console to navigate to
/etc/nginx
andcp
yournginx.conf
tonginx.conf.bck
Verify that from a networking perspective, you can ping/reach/route to the Frame workloads in the other networks or subnets from the SGA. Do not continue until you confirm your SGA can reach the additional account workload networks.
Execute the following command as root on the SGA VM:
cd /usr/local/bin && ./gen_proxy_config.py --domain sga.company.com --cidr 10.0.1.0/24 10.0.2.0/24 > /etc/nginx/nginx.conf systemctl restart nginxNote
The command line syntax above assumes that you have Python in your path and the latest gen_proxy_config.py downloaded.
Submit a support ticket. Follow the instructions in Step 7 in the Installation and Configuration section of this guide.
Troubleshooting¶
Troubleshooting the SGA should be started by assessing the public side of the solution, then moving to the SGA command line interface (CLI) to assess traffic flow from the SGA to the Frame workload VMs.

From the public Internet, verify the following to isolate the issue between user’s browser and the SGA VM:
Wildcard DNS points to the same FQDN as the Wildcard Certificate
Example: *.sga.company.com
Check the SGA certificate chain validates properly.
<Trusted, Intermediate, Server Certificate>
Is the SGA reachable at
https://<anyhost>.sga.company.com>/index.html
?You should receive an HTTP Internal Server Error 500.
To verify that HTTPS/Secure WebSocket traffic is working properly from the SGA to the Frame workload VMs, login to the SGA and:
Verify nginx is running:
sudo systemctl status nginx
Determine if SGA can reach the Frame Guest Agent by executing the following steps:
Acquire the local IP address of the Sandbox VM.
Go to Frame Dashboard and start a session on the Sandbox.
Within 120 seconds after starting the session, execute on the Linux command line in the SGA VM the following:
curl -k https://IP_OF_WORKLOAD/
The reason for executing this sequence of steps is that Frame Guest Agent actively listens on port 443 only while Frame Guest Agent is waiting for a user to connect to the workload VM after the user’s browser has been redirected to the designated workload VM.