Resources

Arrow Image

Blog & News

Arrow Image

Using AWS Firewall with an Autodeployed SGA

Using AWS Firewall with an Autodeployed SGA

Nutanix Frame® Desktop-as-a-Service (DaaS) has long supported private network workloads via the implementation of a Streaming Gateway Appliance (SGA). On public cloud infrastructure, this capability can be automatically deployed upon account creation. As a part of this process, the Frame platform creates a Network Address Translation (NAT) Gateway to ensure that the workloads have a way to communicate back to the Frame control plane residing on the Internet. When deployed, this NAT GW does not provide network administrators the ability to control or restrict the outbound web traffic of the workloads. By combining an autodeployed SGA with Amazon® Web Service's (AWS) Network Firewall solution, a network administrator can get fine grained control of the outbound web traffic for Frame-managed workloads and still allow them to contact the Frame control plane. This blog will demonstrate how this can be done.

News & Blog

WRITTEN BY

TABLE OF CONTENT

Generalized Auto-Deployed SGA Architecture

Generalized Auto Deployed SGA Architecture

Generalized Auto Deployed SGA Architecture

The above diagram depicts a generalized network architecture for the Auto Deployed SGA Frame account. The Frame workloads (in the VPC on the left) have only private, non-publicly-routable IP addresses and do not have direct access to the public Internet. Inbound session traffic flows through the SGA and is locked down to only allow the Frame session traffic through. The outbound traffic is routed through an AWS Internet Gateway with NAT. This is required for the workloads to communicate with the Frame control plane for command and control information. It is this VPC (the Frame Workload VPC) where adding that AWS Firewall to control outbound traffic can provide additional security by limiting traffic to only approved DNS domains.

AWS Network Firewall

For details on how the AWS firewall works, it is best to look at the documentation AWS provides. The specific use case that we are interested in is documented here, and the architecture drawing is referenced here for discussion.

AWS Firewall between NAT and Internet GW

AWS Firewall between NAT and Internet GW

This architecture has a "Customer subnet" and a "NAT gateway subnet" that closely mirrors the Frame Workload subnet and the NAT GW in our generalized architecture above. Inserting a “Firewall Subnet” between the NAT GW and the Internet GW will allow us to take advantage of the stateful features of the AWS Firewall. The rest of the blog will go through the steps to do this.

Private Workload VPC

To begin, I created a Frame account with an Autodeployed SGA. The Workload VPC CIDR I chose was 10.100.0.0/18, and it created a VPC with a subnet per Availability zone (the Frame default behavior) and ended up with the following setup. (Note: I am not including the SGA VPC and peer to simplify the drawing).

Private Networking Workload VPC

Private Networking Workload VPC

To implement the AWS Firewall as described above, I will need to create a Firewall Subnet and change the route tables to put it between the NAT Subnet and the IGW. The target architecture after creating the Firewall subnet will end up looking like this.

Private Networking with AWS Firewall

Private Networking with AWS Firewall

Create Subnet and AWS Firewall Endpoint

A 10.100.0.32/21 subnet in the same availability zone as the NAT (in my case, us-west-2d) must be created first.

Create a subnet for the Firewall

Create a subnet for the Firewall

Next, we can create a Firewall and place its endpoint in that subnet. For now, I left the policy blank so we can update that later.

Create a subnet for the Firewall

Create a subnet for the Firewall

##Update Routing The next step is to update the routing and "insert" the AWS Firewall between the NAT GW and the Internet GW (as shown in the AWS FW figure above). To do this, three tables need to be updated or created:

  1. The NAT GW Route Table needs to have the default route moved to the FW.
  2. The FW subnet (which by default uses the main route table) will need to have a new route table created to forward traffic to the Internet GW.
  3. The IGW will have to have its own route table created and associated via an “edge association” that sends traffic destined for the NAT subnet back through the FW.

Update NAT Route Table

As deployed by the Frame Backplane, the NAT GW subnet's route table will point the default, 0.0.0.0/0, route to the Internet GW. This route will need to be updated as shown below. Note that the Firewall endpoint will show up in "Gateway Load Balancer Endpoint."

Search under Gateway Load Balancer Endpoint

Search under Gateway Load Balancer Endpoint

Updated NAT GW Route Table

Updated NAT GW Route Table

Create a FW Subnet Route Table

Now, follow the Create Route Table workflow to create a route table that has the SGA Route (through the peer), the local route, and the default route pointed to the Internet Gateway.

Create FW Subnet Route Table

Create FW Subnet Route Table

After creation of the FW subnet route table, use the "Subnet Associations" tab to associate your new table with the Firewall subnet.

Create the Internet Gateway Route Table

Follow the Create Route Table workflow to create a route table that has a route setup for the NAT GW's subnet (10.100.24.0/21 in may case). This route table will route the return traffic from the Internet Gateway to the Firewall.

Create Internet Gateway Route Table

Create Internet Gateway Route Table

This time, after creating the route table, use the "Edge Associations" tab to associate this route table with the Internet Gateway.

Configuring the AWS Firewall

Now that the routing is set up, it is time to add the rule groups to the firewall to allow web traffic to the Frame control plane domains. To do this, I first set up a stateless rule that passes all web traffic to the stateful rule groups. Then, I create a stateful rule group to allow the traffic to specific domains.

Create a Stateless Rule Group

In my example, I set capacity to 10 since it is a pretty simple rule and then created one for HTTPS.

Rule for Https

Rule for Https

It is important to change the action to "Forward to stateful rule groups".

Set forward to stateful rule groups

Set forward to stateful rule groups

I created a second rule to forward all other traffic to the stateful rule groups where it will be blocked.

Final stateless rule group

Final stateless rule group

Create a Stateful Rule Group

The next step is to create a stateful rule group to you specify the domains where web traffic is allowed. Since this rule is more complicated, I allocated a capacity of 50 to the rule group. I also added google.com to make it easier to confirm that the rule works on the Frame Account.

Create Stateful Rule Group

Create Stateful Rule Group

Setup the Firewall Policy

Finally, we will attach these rule groups to the blank policy we set up when the firewall was created. I also changed the Default Action for fragmented packets to "Forward to stateful rule groups."

Firewall Policy Configuration

Firewall Policy Configuration

Testing

To test, simply attempt to start a session on the Frame account. The session should start normally, and if you open a web browser, you should be able to bring up www.google.com but other domains will not work.

Troubleshooting

AWS includes some monitoring and logging tools that can be helpful to determine why something might not be working as expected. To enable logging, go to the "firewall details" table in the Firewall page and choose to "edit" the logging options.

Firewall details

Firewall details

From there, you can select to log alerts to an existing Cloudwatch Log group, or you can use the create log group button to create a new log group.

Firewall log configuration

Firewall log configuration

The Firewall logs can now be viewed in AWS Cloudwatch and if a connection is denied for some reason, it will be displayed in the Firewall logs.

This customization does limit the Frame control plane's ability to automate some network functions and the customer should assume that future networking upgrades will need to be done by the customer's networking team.

Conclusion

Combining Frame private networking with the built-in AWS firewall can provide a flexible way for organizations to limit internet access from the private Frame workloads while still allowing users to connect to Frame sessions from anywhere on the internet.

About the Author

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!