Resources

Arrow Image

Blog & News

Arrow Image

Bring Your Own Azure Network to Frame

Bring Your Own Azure Network to Frame

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.

News & Blog

WRITTEN BY

David Horvath

Senior Solutions Architect

June 30, 2021

TABLE OF CONTENT

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:

  1. 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).
  2. The Virtual Network ID of the Azure VNet you are deploying to.
  3. 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.

Figure 1. BYO Networking Virtual Network
Figure 1. BYO Networking Virtual Network

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.

Figure 2. Create a resource group
Figure 2. Create a resource group

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.

Figure 3. Create a subnet in a Virtual Network
Figure 3. Create a subnet in a Virtual Network

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.

Figure 4. Create a Bastion Host
Figure 4. Create a Bastion Host

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.

Figure 5. Frame Workload Security Group
Figure 5. Frame Workload Security Group

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.

Figure 6. Add network security group to the subnet
Figure 6. Add network security group to the subnet

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.

Figure 7. Create Virtual Machine Dialog
Figure 7. Create Virtual Machine Dialog

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.

Figure 8. Networking dialog
Figure 8. Networking dialog

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.

Figure 9. Updated RDP Rule
Figure 9. Updated RDP Rule

NAT Gateway

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.

Figure 10. NAT Gateway dialog
Figure 10. NAT Gateway dialog
Figure 11. New Outbound IP for NAT Gateway
Figure 11. New Outbound IP for NAT Gateway
Figure 12. Associated with the Private subnet
Figure 12. Associated with the Private subnet

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.

Figure 13. Frame Account Creation
Figure 13. Frame Account Creation

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.

Figure 14. Frame Sandbox Configuration
Figure 14. Frame Sandbox Configuration

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.

Figure 15. Connect to the RDP host via Bastion
Figure 15. Connect to the RDP host via Bastion

Once you are in the Bastion you can start a session in the sandbox and use the Frame Account as you would normally.

Figure 16. Frame session running on private network
Figure 16. Frame session running on private network

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 13.66.22.106.

Conclusion

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).

About the Author

Dizzion

Dizzion was founded in 2011 with a visionary mission to redefine the way the world works.

In an era of legacy Virtual Desktop Infrastructure (VDI), Dizzion set out to challenge the status quo by making it simple for all customers to transform their workspace experience. By building a powerful automation and services platform on top of the VMware stack, Dizzion delivered virtual desktops as a service before Desktop as a Service (DaaS) even existed.

David Horvath

Senior Solutions Architect

William Wong is the VP of Service Delivery for Dizzion, responsible for service delivery (professional and managed services), solutions architecture, and support. He works actively with customers to transform their business and operations leveraging DaaS in a hybrid and multi-cloud world. Before joining Dizzion as part of the Frame spinout from Nutanix, William was Head of Enterprise Solutions at Frame and following Nutanix's acquisition of Frame in 2018, Director of Solutions Architecture (Frame) at Nutanix. Prior to his work in DaaS, William led the development and adoption of innovative Internet software solutions and services, including Internet-based credit card and check processing and eCommerce platforms. William spent over 30 years at Cancer Commons, NetDeposit, Hewlett-Packard, VeriFone, and multiple Internet, payment, and eCommerce startups in executive management, program management, engineering management, and executive advisory positions. William received his B.S., M.S., and Ph.D. in Electrical Engineering from Stanford University.

More about the author

Subscribe to our newsletter

Register for our newsletter now to unlock the full potential of Dizzion's Resource Library. Don't miss out on the latest industry insights – sign up today!