Using AWS Firewall with an Autodeployed SGA

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.