As enterprises continue to expand their IT footprint into the public clouds, extending existing private networking infrastructure into the public cloud has become more critical. To address the flexibility that this requires, Nutanix has added a Bring Your Own (BYO) Networking feature to its Frame™ Desktop-as-a-Service (DaaS) solution. In a previous blog, I walked through how to use this feature in the AWS® platform. In this blog, I will walk you through how an environment could be set up in an Azure® cloud infrastructure. Integration between your Frame-managed workloads with an actual private network depends on the specific implementation of your private network.
You can find details on the network requirements for using Frame in a BYO networking scenario at Public Cloud with Private Networking.
Requirements for BYO Networking
Frame DaaS requires the following information to deploy BYO Networking to your Azure implementation:
- A Frame customer or organization with an attached Azure Subscription (instructions for attaching your Azure Subscription to your Frame customer or organization entity can be found here).
- The Virtual Network ID of the Azure VNet you are deploying to.
- The Subnet ID for the subnet in the VNet where the workloads will be deployed (These subnets will need outbound internet access).
Figure 1 below illustrates the network architecture of what I created for this blog.
Create a Resource Group and a Virtual Network
An Azure Resource Group is a convenient way to group resources that work together in Azure. In my case, I created one in the South Central US as seen in Figure 2.
Then you can create a virtual network in that resource group. During that process, you can also create the subnet you will need for the Frame workloads. In Figure 2 above I have one subnet that is a /26 so I created a VNet with a /24 and put that /26 subnet in the VNet.
For testing purposes, it is often handy to have a Bastion Host so that you can access the private network. Go to the “Security” tab to enable the Bastion Host and fill out the form.
Network Security Group
The next step is to create a network security group and attach it to the subnet that the workloads will use. The network security group should allow port 443 (TLS for session traffic) from all private IP addresses. Details on Frame networking can be found here.
1Frame is transitioning to the Frame Guest Agent 8.0. When this transition is completed for a Frame account, inbound traffic on port 8112 will no longer be required.
Once created, the Network Security group can be added to the workload subnet configuration.
Add an RDP Instance
Since I don't have a private network to connect my Virtual Network to, I will deploy an RDP “jump box” behind the bastion I created so that I can confirm the operation of Frame workloads once they are provisioned in the newly created virtual network.
Use the defaults on the Disk Tab. On the networking tab, don't use a public IP and leave the security with the default values. We will fix it later.
Once the VM is created, go to the networking tab and change the RDP rule so that it will only allow traffic from the private network.
You will need a NAT Gateway to make sure that the Frame Workloads have outbound Internet access. So we will create a NAT Gateway and associate it with the private subnets.
Create the New Frame Account
With the Azure private networking setup complete, I now have all the information necessary to set up my Frame BYO Networking account. I have already registered my Azure subscription to my Frame Organization entity (as noted above).
In the “Create Account Dialog,” I choose the correct cloud provider (e.g., Azure) and region (e.g., South Central US) and then select the “BYO Networking” radio button, as seen below.
I chose the VirtualNetwork 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.
Congratulations, You've Made it Through!
That is it! After a few minutes, my Frame account is created and ready to use. Only machines on the private network can connect to Frame sessions, so RDPing into the Bastion, starting up a browser, and logging into Nutanix Console will be required.
Once you are in the Bastion you can start a session in the sandbox and use the Frame Account as you would normally.
In the above screen shot you can see the RDP host via the bastion has the private IP 10.0.100.132. The Firefox browser on the RDP host has a frame session to a machine on that same private network 10.0.100.134 but a public IP that matches the outbound NAT GW 126.96.36.199.
In this blog we showed how you could set up a Bring Your Own Network Frame account in the Azure platform. The workloads of the Frame account will only have IP addresses on your private network and therefore they inherit all the existing network security controls that would be setup on your private network. For external users, connecting in via RDP is probably not the most efficient way to connect. For those users you can either have them connect via an existing VPN solution or through a Frame Streaming Gateway Appliance (SGA).