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.
![](https://cdn.prod.website-files.com/653fe79c68bb383bddf27e84/664dffe19e57715fd248150e_img-blog-generalized-auto-deployed-sga-architecture-dcb334ddcd7718ae30fb5c0a550260ac.png)
WRITTEN BY
TABLE OF CONTENT
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](https://cdn.prod.website-files.com/653fe79c68bb383bddf27e84/66461b4995e2648e9cc4e21b_img-blog-aws-firewall-between-nat-and-internet-gw-18647dd79d8811fe6f553bc52c7177da.png)
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](https://cdn.prod.website-files.com/653fe79c68bb383bddf27e84/66461b49d888ac96683525bb_img-blog-private-networking-workload-vpc-07202d518e4bf0e1d5a33d4223bb738d.png)
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](https://cdn.prod.website-files.com/653fe79c68bb383bddf27e84/66461b4972ef7303e9fe4237_img-blog-private-networking-with-aws-firewall-207bafbc6f9e404b668d2f8442e12149.png)
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](https://cdn.prod.website-files.com/653fe79c68bb383bddf27e84/66461b4ac4490c2d7e1b8578_img-blog-create-subnet-for-firewall-3f1fc5d442d521fd417bd182bc10c603.png)
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](https://cdn.prod.website-files.com/653fe79c68bb383bddf27e84/66461b498043b6d11eaa0b72_img-blog-create-firewall-9cb36c1e669ae83cabbd52855f5690e1.png)
##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:
- The NAT GW Route Table needs to have the default route moved to the FW.
- 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.
- 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](https://cdn.prod.website-files.com/653fe79c68bb383bddf27e84/66461b4969e9e0e8b4216f66_img-blog-search-under-gateway-load-balancer-endpoint-0e37038f06cf55d47cab253b26de9345.png)
![Updated NAT GW Route Table](https://cdn.prod.website-files.com/653fe79c68bb383bddf27e84/66461b4994acea1aa71aed57_img-blog-updated-nat-gw-route-table-978c52694bb96b5329e6fc1668d889be.png)
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](https://cdn.prod.website-files.com/653fe79c68bb383bddf27e84/66461b54c7ad08b40d16417e_img-blog-create-fw-subnet-route-table-f09c966319a8005dab33065a1786dcb5.png)
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](https://cdn.prod.website-files.com/653fe79c68bb383bddf27e84/66461b49bfa2c5d01bf0ba2f_img-blog-create-internet-gateway-route-table-968fec9bc4e2c1ed30e170e9472491a3.png)
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](https://cdn.prod.website-files.com/653fe79c68bb383bddf27e84/66461b49eef8fec0a8af01e3_img-blog-rule-for-https-1533a3fdb30a1ee059c0332536cd1c4e.png)
It is important to change the action to "Forward to stateful rule groups".
![Set forward to stateful rule groups](https://cdn.prod.website-files.com/653fe79c68bb383bddf27e84/66461b49dfd8cb96302f9a24_img-blog-set-forward-to-stateful-rule-groups-3718dc2901fb8dc3ba046cd265b61567.png)
I created a second rule to forward all other traffic to the stateful rule groups where it will be blocked.
![Final stateless rule group](https://cdn.prod.website-files.com/653fe79c68bb383bddf27e84/66461b499163e7f2caea1992_img-blog-final-stateless-rule-group-a3150f9659d89168fcd442d3a5e55206.png)
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](https://cdn.prod.website-files.com/653fe79c68bb383bddf27e84/66461b492c67f9a781f67efd_img-blog-create-stateful-rule-group-e9a6254ca0597cc38ff248048a1e2778.png)
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](https://cdn.prod.website-files.com/653fe79c68bb383bddf27e84/66461b498383dda9a3851a60_img-blog-firewall-policy-configuration-f423d4f4e3fc14037d63649d06031937.png)
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](https://cdn.prod.website-files.com/653fe79c68bb383bddf27e84/66461b4969e9e0e8b4216f7c_img-blog-firewall-details-13eedc41d01270f8f6f514411a1b297c.png)
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](https://cdn.prod.website-files.com/653fe79c68bb383bddf27e84/66461b49ef62fb3af31d817f_img-blog-firewall-log-configuration-ea51fe62db343efac04fb471cf387fed.png)
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.
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!
![](https://cdn.prod.website-files.com/653fe79c68bb383bddf27e59/6618fa27a818a760b7a3bd84_%5Basset%5D%20Newsletter-min.webp)
Dizzion values your privacy. By clicking on the submit button, you agree to the processing of your personal data in the manner indicated in the Dizzion Privacy Policy and consent to receive communications from Dizzion about our products, services, and events.