Deploy centralized traffic filtering using AWS Network Firewall

In this blog, we will walk through the steps to accelerate your centralized deployment of AWS Network Firewall using a new deployment automation solution—AWS Network Firewall deployment automation for AWS Transit Gateway. We will also discuss common use cases for AWS Network Firewall in a centralized architecture that uses AWS Transit Gateway.

Though this post is focused on the centralized filtering model that uses Transit Gateway, AWS Network Firewall can also be deployed in a distributed or hybrid connectivity model. Please see the blog post, Deployment models for AWS Network Firewall, for a full array of common AWS Network Firewall architectures patterns.

This blog assumes you are already familiar with AWS Network Firewall and Transit Gateway. If you are unfamiliar with AWS Network Firewall, check out the AWS Network Firewall launch announcement for a good overview. If you are interested in learning about Transit Gateway, the Transit Gateway overview page will get you started.

Common use cases

Figure 1: Traffic flow diagram for common centralized traffic filtering use cases

The preceding diagram (figure 1) shows common architectural patterns for centralized traffic filtering, and shows traffic flow for new connections initiated from within a VPC. Return packets for the connection follow the same path in reverse. Following are descriptions of the common architecture patterns for centralized traffic filtering. When you deploy your solution, you can choose to implement any one, two, or all three architecture patterns.

1. North-South VPC to internet egress traffic, via NAT Gateway:
   Traffic from private subnets within a VPC is routed through Transit Gateway and AWS Network Firewall. Then it is routed through a NAT gateway that performs network address translation (NAT) for the traffic that flows out to the internet. This architecture is for outbound connections only, as the NAT gateway cannot accept inbound connections from the internet. For ingress options, please see the blog post Deployment models for AWS Network Firewall.
2. North-South VPC to on-premises traffic, via VPN connection or AWS Direct Connect: Traffic between a VPC and a remotely connected network is routed through AWS Network Firewall. This provides an additional layer of control over traffic flowing between these points.
3. East-West VPC to VPC traffic:
   Traffic between two VPCs is routed through the Transit Gateway. Common use cases include providing an application VPC access to a shared services VPC, or facilitating communication between a development VPC, a testing/QA VPC, or a production VPC.

Solution overview

In this blog post, we will walk through the deployment of this automated solution and look at the real-world use cases in the preceding sections. We assume that you have an existing Transit Gateway that you want AWS Network Firewall to use for traffic filtering. If you do not already have a Transit Gateway and attachments deployed, please see Getting started with transit gateways in our documentation.

The automated solution implementation includes an AWS CloudFormation template that deploys several resources: an inspection VPC, a pair of AWS Network Firewall endpoints, Transit Gateway attachments, a code repository, a pipeline for updating the Network Firewall solution configuration, and more. Please see the AWS solutions implementation overview for a detailed description of the architecture. The diagram that follows (figure 2) reproduces an architecture from the overview page. This diagram shows components deployed by the solution, and existing Transit Gateway and existing VPC attachments (that are not part of the solution).

Figure 2: AWS Network Firewall deployment automation architecture overview (source)

Prerequisites

In order to perform centralized traffic filtering with the solution, you need a Transit Gateway with at least one Transit Gateway attachment (such as a VPC, VPN, or Direct Connect attachment). It is possible to deploy the automated solution without specifying a Transit Gateway when launching the CloudFormation template. But, in the solution deployment that follows you must attach the inspection VPC to the Transit Gateway and update your Transit Gateway route tables manually.

You must have access to the AWS account where you plan to deploy the solution. This is generally the same AWS account where the Transit Gateway resides. You must have access to an IAM user or role within this account to launch CloudFormation templates and perform the final implementation steps.

The following architecture diagram (figure 3) illustrates the demo environment we are using. This is a well-architected environment that demonstrates multiple use cases. Note that when deploying the automated solution, you are not required to use all of the use cases shown here.

The following diagram (figure 3) shows our demo architecture and illustrates multiple existing Transit Gateway use cases:

• East-West VPC to VPC
• North-South VPC to VPN
• North-South VPC egress to internet

Figure 3: Example architecture before solution deployment – showing multiple use cases

The following diagram (figure 4) shows a demo architecture that illustrates multiple use cases that are possible after the automated solution has been deployed. Note that this diagram does not show all of the resources that are deployed as part of the solution.

Figure 4: Example architecture after solution deployment – showing multiple use cases

Implementing the solution

We break deployment down in to four parts:

1. Prepare to launch the CloudFormation stack
2. Launch the CloudFormation stack for the solution
3. Update Transit Gateway route table associations
4. Customize the solution (modifying firewall policies, rule groups, etc.)

Prepare to launch the CloudFormation stack:

Before we deploy the solution, let’s gather the information that we need for the CloudFormation inputs.

1. Sign in to the AWS Management Console of the AWS account where you plan to deploy the automated solution. Then select the AWS Region where your existing Transit Gateway resides.
   
2. Locate the Transit Gateway ID for the Transit Gateway you want to use with the AWS Network Firewall solution. To do this, navigate to the VPC service.
   • Once in the VPC service, select Transit Gateways on the left navigation column and your existing Transit Gateways will be displayed.
   • Note the ID of the Transit Gateway. We will use this ID when we deploy the CloudFormation template for the solution.
3. Now verify that the Region of your existing Transit Gateway offers the AWS Network Firewall service. You do this by checking that the AWS Network Firewall service is shown on the left navigation column. If AWS Network Firewall is not shown, visit the AWS Regional services list to verify that AWS Network Firewall is available in your Region.
   
4. Create a Transit Gateway route table that is associated with your inspection VPC. This route table is used by the Transit Gateway to route traffic to its final destination after it is processed by the AWS Network Firewall.
   • Select Transit Gateway route tables from the left navigation column within the VPC service console.
   • Select Create Transit Gateway route table.
   • Enter a Name tag for the route table (“Firewall TGW route table,” for example) and then select the Transit Gateway ID of the Transit Gateway that you plan to associate with the solution.
   • Once the new Firewall route table has been created, note its ID.
     
5. Create a Transit Gateway route table that will be associated with your Transit Gateway spoke attachments following the deployment of the automated solution.
   • While still in the Transit Gateway route tables view, select Create Transit Gateway route table.
   • Enter a Name tag for the route table (“Inspection TGW route table,” for example). Then, select the Transit Gateway ID of the Transit Gateway that you plan to associate with the solution.
   • Once the new inspection route table has been created, note its ID.
     
6. Add route propagations and static routes to your firewall Transit Gateway route table for your connected networks. These entries route traffic that has been processed by the AWS Network Firewall and is flowing out of the inspection VPC to the final destination. For our demo environment, we have added route propagations for our two VPC attachments and static routes for our VPN and Egress VPC.
   • For documentation on adding route propagations and static routes, see Transit Gateway route tables in our documentation.
     
7. Determine your log destination for the Network Firewall logs and the type of logs you want to collect. See the automated deployment page of the solution’s implementation guide for full details on the firewall logging configuration.

Launch the CloudFormation stack for the solution

Next, we deploy the solution using the included CloudFormation stack. For full details on the CloudFormation template and its parameters, see the automated deployment page of the solution’s implementation guide.

1. Click this launch template link. The link takes you to the Create stack function within the CloudFormation console in the N. Virginia Region (us-east-1).
2. If the Transit Gateway that you want to use with the solution is not in N. Virginia, select the correct Region by clicking N. Virginia at the top of the console and then selecting the correct Region. You will be taken to the Create stack page for the selected Region and the Amazon S3 URL. The solution’s CloudFormation template is automatically populated.
   
3. Click Next to continue.
4. Enter a name for the stack in the Stack name In our demo environment, we have chosen to name our stack “NetworkFirewallDemo.”
5. Under VPC configuration, provide the CIDR block for the inspection VPC to be created by the solution.
   • Make sure to use a CIDR block that does not overlap with any network that is already connected to the Transit Gateway. Any overlap with the CIDR block of another network will cause routing issues as traffic flows through the inspection VPC. In our demo environment, we will use the default inspection VPC CIDR of 192.168.1.0/26.
6. Under Transit Gateway configuration, provide the ID of the existing Transit Gateway that you want to attach to the inspection VPC. This ID was previously gathered in step 2 of the preparation section.
7. Next, associate the Transit Gateway route table with the inspection VPC Transit Gateway attachment (for example, a firewall Transit Gateway route table). This ID was previously gathered in step 4 of the preparation section.
8. Set the Transit Gateway route table to route 0.0.0.0/0 to the inspection VPC TGW attachment. This will be your inspection Transit Gateway route table that we created in step 5 of the preparation section.
9. In the firewall logging configuration section, select your preferred log destination, type of logs, and log retention. These values were determined in step 7 of the preparation section. See the automated deployment page in the solution’s implementation guide for full details on firewall logging configuration.
10. Review your entries for accuracy and click Next.
    
11. Make any desired adjustments to the Configure stack options. For this example, we leave everything as is, and click Next.
12. Review your stack details. Check the box labeled I acknowledge that AWS CloudFormation might create IAM resources (this step is necessary because the CloudFormation template is creating IAM roles and policies). Finally, click Create stack.
13. Wait for the CloudFormation stack to reach status CREATE_COMPLETE.
    
14. Once the CloudFormation stack is complete, head over to the AWS CodePipeline service to check that the pipeline execution has succeeded. Note that the Network Firewall solution is not functional until the pipeline execution has succeeded. To check the pipeline status, select the AWS CodePipeline service from the Services dropdown at the top (or by typing “AWS CodePipeline” into the search bar at the top). The pipelines are shown there.
    

Update Transit Gateway route table associations

Next, we must update the Transit Gateway route table associations for the spoke Transit Gateway attachments. This change routes all traffic passing through the Transit Gateway from the spoke attachments (VPCs, VPN, Direct Connect) to the inspection VPC for processing.

1. If your Transit Gateway networking environment is already handling application/workload traffic, schedule a time to complete this maintenance. These changes will temporarily disrupt traffic flows through the Transit Gateway.
2. Locate the Transit Gateway route table that your Transit Gateway attachments are currently using. To do this, select the VPC service. Once in the VPC service, select Transit Gateway route tables on the left navigation column and your existing Transit Gateway route tables will be displayed. In our demo environment, the route table is named “Spoke TGW route table.”
   • Note that this is NOT the inspection route table that we created earlier.
3. With the spoke Transit Gateway route table selected in the upper frame, select the Associations tab in the lower frame. One at a time, select the check box next to each attachment ID and click Delete association. Wait for the dissociations to complete and click refresh. The associated attachments list for your old spoke Transit Gateway route table should be empty.
   
4. Now that we have removed those associations, we associate the attachments with our new inspection Transit Gateway route table. Select the inspection Transit Gateway route table, and then click Create association. Select the VPC attachment you want to associate using the Choose attachment to associate dropdown list and click Create association. Repeat this process for all desired associations.
   
5. Test connectivity between networks that are connected through the Transit Gateway and AWS Network Firewall solution. Verify that traffic is able to reach endpoints that are routed through the solution.
   • Note that in its default configuration, the AWS Network Firewall deployed with the solution allows all traffic to pass.

Customizing the solution

Following implementation and testing, we begin customizing the AWS Network Firewall configuration. As a best practice, update the Network Firewall policies and rules by updating the source code that is located in the AWS CodeCommit repo that is created by the solution. Once you commit an updated version of the source code in AWS CodeCommit, AWS CodePipeline automatically deploys the changes to your environment. This workflow streamlines both Network Firewall policy/rule updates and rolling back previous changes. Please see Configuring resources for AWS Network Firewall in the solution’s implementation guide.

Cleanup

To remove the solution from your AWS account, first revert your Transit Gateway route table associations with your spoke VPC attachments to your original route table (see Transit gateway route tables documentation). This will remove the inspection VPC from the routing path and allow traffic to flow directly between your Transit Gateway attachments. Proceed to the Uninstall the solution section of the solution implementation guide and follow the uninstall procedure for the solution. Finally, delete the Transit Gateway route tables that you created in the Prepare to launch the CloudFormation stack section above (see Transit gateway route tables documentation). These Transit Gateway route tables were created for routing spoke attachment traffic to the inspection VPC and for the inspection VPC attachment itself.

Conclusion

In this blog, we walked through common use cases for the AWS Network Firewall deployment automations for Transit Gateway automated solution. These included: east-west VPC to VPC traffic, north-south VPC to VPN/AWS Direct Connect traffic, and north-south VPC to internet egress. We then deployed the automated solution into an AWS account with an existing Transit Gateway and Transit Gateway attachments. This architecture enables the inspection of traffic flowing through the Transit Gateway by the Network Firewall service for an additional layer of security between your connected networks. To learn more about other common architecture patterns for AWS Network Firewall, continue on to the blog post Deployment models for AWS Network Firewall. To learn more about firewall policies and rule groups for Network Firewall, continue on to the AWS Network Firewall Developer Guide.