Aviatrix Answers

How can I avoid SNAT when using in-line, next-generation firewalls in AWS and multicloud environments?


Network Design
8 minute read


Introducing a “Bump-in-the-wire Cloud firewall” is often an urgent security project undertaken by enterprises adopting AWS and Azure. The goal is to inspect and secure the traffic resulting from growing connectivity in and out of their public cloud infrastructures.

Next-Generation firewalls have been a popular candidate for implementing these security measures. The ideal, multicloud architecture would look something like this:

But this architecture does not meet important requirements like High Availability, throughput scaling and compute scaling. The introduction of AWS Transit Gateway (TGW) raises hope that this architecture can finally become a reality. The AWS Transit Gateway (TGW) is a scalable, highly available service built to connect VPCs together and simplify connectivity to on-premise resources. Here are the two popular architectures of how to introduce in-line firewall using the AWS Transit Gateway (TGW):

1. Using AWS Transit Gateway (TGW) “VPC attachment” feature (this requires SNAT)

SOURCE: re:Invent © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.

2. Using AWS Transit Gateway (TGW)’s IPsec/ECMP feature (Requires SNAT)

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.

Note: These architectures were borrowed from AWS learning sites - https://www.slideshare.net/AmazonWebServices/connecting-many-vpcs-network-design-patterns-at-scale-arc405-aws-reinvent-2018

These ideas look simple. However, practitioners who have tried these will admit that there are major technical hurdles to be crossed before implementing this architecture. One of these hurdles is the requirement to Source NAT (SNAT) all traffic coming into the firewall for inspection. There are reasons SNAT-ing is required: 1. To avoid asymmetric routing across multiple firewall instances, 2. To overcome limitations in the Cloud networking constructs.

This requirement to source NAT all traffic has serious implications for distributed/hybrid applications. For most enterprises, this is a blocker for moving ahead with the implementation. SNAT-ing the traffic hides the source IP addresses of the API calls, leaving the web-services and microservices no way for using and applying normal security policies like security groups and access controls.

The good news is that you can avoid Source-NATing your traffic by using an AWS recommended transit gateway orchestration solution: Aviatrix Transit DMZ. This solution uses Aviatrix gateways (in the VPC that hosts the firewall) to intelligently manage packet routing in and out of the firewall interfaces. This simple wizard-based solution enables you to build out a bump-in-the-wire (in-line) firewall solution without having to SNAT the traffic.

There are other performance and high availability benefits to this Transit DMZ architecture. More on this topic can be found here: https://docs.aviatrix.com/HowTos/transit_dmz_faq.html