Introduction
Today, we are witnessing a number of companies building or moving their infrastructure to the public cloud. In one of our previous blogs, my colleague David Horvath explained how you can “Bring Your Own Azure Network to Frame.” With BYO Networking, the Nutanix Frame® DaaS solution provisions Frame-managed workloads in your designated Microsoft Azure® VNet. Access to the workloads in that VNet remains within your private network.
For customers who want their users to access these workloads from the Internet without a VPN, Nutanix provides the Frame Streaming Gateway Appliance (SGA), a secure reverse proxy that supports the Frame Remoting Protocol (FRP) 7 (Secure WebSocket-based) and 8 (WebRTC-based). The SGA allows you to securely grant users access to virtualized applications and/or desktops running in the Azure private VNet without a VPN.
In general, there are two ways to deploy SGAs: (1) manual creation where customers have control over the wildcard subdomain, SGA public IP address, DNS wildcard A record, and SSL certificate lifecycle; and (2) automated deployment where the Frame platform is responsible. In this blog, I am going to walk you through the process of deploying an SGA using the Frame auto-deploy SGA feature in the context of a BYO Azure private network.
Figure 1 below illustrates the architecture of what you will use in this scenario:
Figure 1. Private networking with SGA
Requirements
For setting up Frame Account with Bring Your Own (BYO) Private Networking and using the SGA, you will need to:
- Deploy networking resources in your Azure subscription.
- Have a Frame customer or organization entity with a registered Azure subscription (instructions for attaching your Azure Subscription to your Frame customer or organization entity can be found here).
- Create the new Frame Account with BYO Networking.
- Request SGA auto-deployment from Nutanix Support.
Deploy networking resources in your Azure subscription
To create a Frame account in one of your existing customer-managed Azure VNets, you will need to set up a new Resource Group (RG), Virtual Network (VNet) with one or more subnets, Network Security Group (NSG), and connect that NSG to subnet(s).
RG creation
A resource group is a container that holds related resources for an Azure solution. In our case, we will create RG in West Europe to hold network resources as seen in Figure 2.
Figure 2. Create a Resource Group
VNet and subnet(s) creation
Then, you should create a virtual network in that resource group with one or more subnets—depending on how many Frame accounts you want to have. In Figure 3 below, I created a VNet with a /21 and put a subnet that is /23 inside.
IMPORTANT:
We advise customers to create a separate Azure VNET to contain the Frame workloads. This allows customers to separate and isolate their Frame-related resources from their other Azure resources, allowing customers to report on and apply distinct (if required) security policies to the Frame resources or on the Frame VNET.
When creating a subnet(s) within your VNet for your Frame workloads, make sure that the CIDR block of the subnet is /18 or smaller (e.g., /21, /23, /24 etc.).
Figure 3. Create VNet and Subnet
NSG creation and connecting NSG with workload subnet(s)
Now is the time to create a network security group and attach it to the subnet(s) that will contain the workloads. In Figure 4. I’m creating a NSG with default in-bound and out-bound rules. In Figure 5. I’m attaching that NSG to the Frame-workload subnet.
Figure 4. Create NSG
Figure 5. Connect NSG to Subnet
Create the new Frame account
Once the Azure VNet is configured, I can proceed with the creation of my Frame account, which will be contained in the Azure VNet.
Note: I have already registered my Azure subscription to my Frame organization entity (as noted in Prerequisites #2).
In the “Create Account Dialog,” I choose the correct cloud provider “Azure.” For the region, I chose “West Europe” as I created the Azure resources in that region. Then, I select the “BYO Networking” radio button, as seen below.
I chose the Virtual Network and subnet that I have created, and now I can select my sandbox image and instance type and hit “Next” twice to create my Frame account.
Figure 6. Create Frame Account using BYO Networking
Figure 7. Frame Sandbox configuration
Once the Frame Account creation is finalized, you will notice that a resource group (RG) named “azr-prod-v{vendor_id}-instances-{incrementing_index}” is created in your subscription. In this RG, you will find your Sandbox VM and other Frame workload VMs based on the capacity you specify.
Figure 8. Frame Account Resource Group
Please notice that the VMs will have only private IP addresses and will be accessible only from the internal network. In order to make them accessible from the internet, you will need to submit a request for SGA.
Request for SGA
Congratulations! Your technical part of the job is now done, and you have a Frame account with its workloads in your specified VNet/subnet. Now, let Nutanix support do its magic and create SGA resources under your subscription in an adjacent VNet.
To request the auto-deploy of one or more SGA VMs, please go to https://my.nutanix.com, log in with your credentials, and submit a support request by launching the Support Portal.
Figure 9. Support Portal
The form will look like shown in Figure 9 below.
Figure 10. Support Request
Specify the following information in the support request form:
- Product: Nutanix Frame
- Subject: “Add an SGA to my Frame account”
- Issue: Technical Problem
- Cloud Provider: Azure
- Priority: P3-Normal
- Subscription: Your subscription
- AOS (NOS) Version: Not relevant and can be set to the latest version
- Problem Description: Enter the following details:
- Customer name: e.g., Nutanix-Demo
- Organization name: e.g., Nutanix-Demo-Org01
- Name of account or accounts that you want to connect to SGA(s): e.g., Nutanix-Demo-Acc01
- Frame workload VNet CIDR and subnets CIDR (must be /18 to /24) : e.g., 10.5.0.0/24
- Automatically use the SGA for existing and future Frame accounts in the specified VNet/subnet? e.g., Yes: configure all existing and future accounts to use SGA or No: configure only this specific account to use the SGA
- Number of SGAs to be created (1 or more) : e.g., 1
- SGA VNet CIDR (/24 or /26 is required) : e.g., 192.168.1.0/24
Please make sure that SGA VNet CIDR is not overlapping with Frame-workloads VNet CIDR. By default, Frame will use 172.16.0.0/24 for SGA VNet. If more than one SGA is requested, then an Azure Load Balancer will be provisioned in front of your SGA VMs.
Azure Resources Provisioned
Once the process of SGA enablement is done, you will see the following resource group in your Azure subscription, as shown in Figure 11.
Figure 11. SGA resource group
If you requested one or multiple Frame accounts in the same VNet, peering between the SGA VNet and the Frame workload VNet is done automatically by the Frame platform, as shown below in Figure 12.
Figure 12. Peering between SGA and workload VNet
Frame will create and configure your NSG to allow only mandatory inbound traffic.
Figure 13. NSG rules
If you wish to have multiple Frame accounts in different VNets, please expect notification from our support team to create the VNet peer(s) between the SGA VNet and the remaining Frame workload VNets on your own. Note that the remaining Frame workload VNets must have CIDRs that fall within the Frame Workload VNet CIDR specified in the support ticket.
Conclusion
In this blog, we showed how you could set up a BYON Frame account in Azure and use Streaming Gateway Appliance for secured connection between the end user and the workload VM without need of VPN. The workloads of the Frame account will only have private IP addresses on your private network; therefore, they inherit all the existing network security controls that would be set up on your private network. Users will be directed for that Frame account to the public IP address of the SGA (or the Azure Load Balancer for two or more SGA VMs) to reach the workload VMs.
Bio:
Stefan Gajic is a Solutions Architect with Nutanix Frame who has worked for various global enterprises and IT companies as a system engineer, technical lead, and solutions architect delivering various Information Technology projects mainly focused on multicloud and hybrid environments. Stefan is also a Microsoft Certified Trainer with the ability to properly impart his Azure expert knowledge to others.
© 2022 Nutanix, Inc. All rights reserved. Nutanix, the Nutanix logo and all Nutanix product, feature and service names mentioned herein are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. Other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s). This post may contain links to external websites that are not part of Nutanix.com. Nutanix does not control these sites and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such a site. Certain information contained in this post may relate to or be based on studies, publications, surveys and other data obtained from third-party sources and our own internal estimates and research. While we believe these third-party studies, publications, surveys and other data are reliable as of the date of this post, they have not been independently verified, and we make no representation as to the adequacy, fairness, accuracy, or completeness of any information obtained from third-party sources.
This post may contain express and implied forward-looking statements, which are not historical facts and are instead based on our current expectations, estimates and beliefs. The accuracy of such statements involves risks and uncertainties and depends upon future events, including those that may be beyond our control, and actual results may differ materially and adversely from those anticipated or implied by such statements. Any forward-looking statements included herein speak only as of the date hereof and, except as required by law, we assume no obligation to update or otherwise revise any of such forward-looking statements to reflect subsequent events or circumstances.