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.

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.

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

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.

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.

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.

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

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.

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. 

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.

It is important to change the action to “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.

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.

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

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.

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. 

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.

David Horvath is a Senior Solutions Architect with Nutanix Frame. He has been a part of the Frame team for almost 5 years and prior to that spent 20 years consulting on various Information Technology projects with the US Intelligence Community.

_{© 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.}