Integrating Third-Party Firewall Appliances with VMware Cloud on AWS Using VMware Transit Connect
By Sheng Chen, Sr. Specialist Solutions Architect – AWS
As customers continually move towards hybrid cloud architectures, it has become increasingly important to address network security requirements for having a centralized security inspection solution between VMware Cloud on AWS and the native AWS environment, on-premises data centers, and the internet.
With an extensive selection of third-party firewall solutions from AWS Marketplace, customers have the flexibility to deploy the same network security solutions in the cloud as they have on-premises, with a seamless user experience.
Through this post, customers will learn how to integrate their preferred third-party firewall solutions with VMware Cloud on AWS, by leveraging the VMware Transit Connect feature. I will provide an example with a detailed walkthrough for integrating a Palo Alto firewall appliance with VMware Cloud on AWS using VMware Transit Connect.
VMware Transit Connect
VMware Transit Connect provides high bandwidth, low latency, and resilient connectivity to Software Defined Data Centers (SDDCs) within a SDDC group.
An SDDC group is a logical entity that leverages VMware managed Transit Gateway (VTGW) through automated provisioning and controls to interconnect SDDCs and Amazon Virtual Private Clouds (VPCs), as well as establishes hybrid connectivity to on-premises data centers over an AWS Direct Connect Gateway (DXGW).
In addition, VMware Transit Connect helps customers simplify management at scale through automatic route propagations to the route tables in each SDDC and the VTGW. SDDCs automatically learn routes advertised by other SDDCs within the same SDDC group, and networks advertised from other VPCs and on-premises networks via the VTGW and DXGW.
Furthermore, with the recent m15 release, customers can now integrate a third-party firewall with the SDDC group through a Security VPC, by injecting a static route at the VMware Transit Connect via a high speed VPC attachment.
Prior to this, customers could only integrate firewall appliances with SDDCs through virtual private network (VPN) connectivity with limited bandwidth and scalability, or to redirect SDDC traffic back at on-premises firewalls with added latency and complexity.
Security VPC Architecture
The diagram below represents a centralized Security VPC architecture for integrating third-party firewall appliances into VMware Cloud on AWS, using the VMware Transit Connect.
Figure 1 – VMware Cloud on AWS Security VPC reference architecture.
The Security VPC provides transit routing and centralized security inspection and enforcement for traffic traversing:
- Between SDDC and the internet
- Between SDDC and workload VPCs
- Between SDDC and on-premises
This architecture also simplifies the process for customers to connect SDDCs with their existing AWS environment through the combined use of VTGW and customer managed AWS Transit Gateway (TGW).
The reference architecture can be used as the basis for a proof of concept (PoC) by following the eight steps highlighted in the diagram above:
- Deploy a SDDC into an SDDC group, which automatically builds a VTGW and establishes connectivity between SDDCs via the VTGW.
- Build a Security VPC with access to the internet via an Internet Gateway (IGW).
- Create one public subnet with access to the IGW and connect it to the firewall internet-bound interface (Eth1/3), which is assigned to an “Internet” Security Zone.
- Provision one private subnet that will be attached to the VTGW, with a dedicated route table to push all SDDC egress traffic to the firewall interface (Eth1/2), which is assigned to a “SDDC” Security Zone.
- Deploy another private subnet with a separate route table to be attached to the customer managed TGW and the firewall interface (Eth1/1), which is assigned to a separate “AWS” Security Zone.
- Provision a third-party (zone-based) firewall appliance within the Security VPC to provide transitive routing and policy inspection from zone SDDC to zone AWS and the Internet
- Create a new (or attach the existing) customer managed TGW to the Security VPC using subnet-01. This provides transitive routing between SDDCs and existing workload VPCs and on-premises data center.
- Attach the Security VPC to the VTGW using subnet-02. Configure a static default route at the VTGW towards the Security VPC attachment.
In addition, since all SDDC egress traffic to the internet, and ingress access from the internet, including SDDC management traffic will be enforced to go through the Security VPC. The architecture helps prevent customers from accidentally exposing vCenter access to the internet via the SDDC console.
For more details, please refer to the full reference architecture.
In the following example, we are going to deploy a Palo Alto firewall appliance and integrate into a VMware Cloud on AWS environment, based on the Security VPC reference architecture.
Figure 2 – Demo example.
Before we get to the detailed steps, I have provisioned and prepared the following items as prerequisites to this lab:
- One VMware Cloud on AWS SDDC.
- One Security VPC consisting of two private subnets, and one public subnet with access to an IGW.
- One Palo Alto firewall appliance deployed with three interfaces, each attached to one of the three subnets.
- One AWS TGW with one workload VPC attached.
I’ll walk through the configurations covering the following aspects:
- VMware Transit Connect
- AWS networking
- Palo Alto appliance (networking setup only)
Part 1: VMware Transit Connect
To begin with, we’ll create a SDDC group to include the existing SDDC as a member, which triggers an automatic deployment of a VTGW that connects to the SDDC via high speed VPC attachment.
Once the Transit Connect and SDDC connectivity status are showing “CONNECTED,” we can associate the AWS account of the Security VPC to the SDDC group.
Figure 3 – Associate AWS account to the SDDC group.
In the AWS console, we’ll soon be able to see the VTGW resource being shared under the Resource Access Manager (RAM). Accept the share, and create a Transit Gateway VPC attachment to connect the VTGW to the Security VPC.
Figure 4 – Accept the VTGW resource share.
Back in the SDDC group console, accept the newly-created TGW attachment. Once the Security VPC’s status becomes “available,” we can add a static default route towards it.
Figure 5 – Add static (default) route towards the Security VPC.
The static route will be automatically propagated to all member SDDCs, and this can be verified at the “Routes Learned” section under Networking & Security > Transit Connect.
Figure 6 – Verify route propagation within the SDDC.
Part 2: AWS Networking
To prepare the AWS networking side, we’ll need to create one dedicated route table for each of the three subnets, which represent the three security zones: “Trust” (native AWS side), “Untrust” (SDDC side), and “Public” (internet).
Next, we’ll configure the following static routes for each of the security zones. This ensures all inter-zone traffic is pushed through the Palo Alto firewall, which provides security inspection and policy enforcement between the SDDCs, AWS native environment, and the internet.
Figure 7 – Route table setup for each security zone.
Navigate to the route table of the AWS TGW (for native workload VPC), and add the SDDC routes towards the Security VPC. Optionally, you could just add a default route to push all egress traffic including internet access via the Security VPC, like I did here.
Figure 8 – Add static route at AWS TGW.
Part 3: Palo Alto Appliance
We’ll now move on to the Palo Alto appliance configurations. Once you have allocated a network interface to the firewall for each of the three subnets, make sure to disable the Source/Destination Check on every network interface. This is important as it allows the firewall interface to handle traffic that’s not designated to the IP address of itself.
Figure 9 – Disable source/destination check on firewall interfaces.
You will also need to allocate at least one public Elastic IP (EIP) address and associate it to the private address of the firewall internet interface. A SNAT rule is required at the firewall to translate all SDDC-to-internet packets to the interface private address, which is then mapped to the public EIP before it gets forwarded to the internet.
Figure 10 – Assign a public EIP to the firewall internet interface.
Next, log into to the Palo Alto management console to configure the firewall interfaces. Under Network > Ethernet, assign each Ethernet interface to the private address of its connected ENI accordingly. Attach each interface to the appropriate firewall zone and virtual router (I’m using the default router instance as an example here).
Figure 11 – Palo Alto firewall interface and zone configurations.
Finally, navigate to Network > Virtual Router > default to configure the firewall route table as per the lab topology.
Figure 12 – Virtual router configuration.
At this point, we have established transit connectivity at the Palo Alto appliance through the Security VPC. Depending on the firewall rules you have configured, you should be able to observe live flow logs for traffic traversing across different security zones.
Figure 13 – Live traffic monitoring at the Palo Alto firewall.
It’s important to note the overall throughput of the Security VPC architecture is heavily depending on the third-party firewall solution customers choose to deploy. It’s recommended that you check with the preferred firewall vendor and make sure to select the appropriate Amazon Elastic Compute Cloud (Amazon EC2) instance type based on your environment requirements.
Depending on the internet traffic demand, you can set up a separate firewall instance dedicated for the internet-bound traffic inspection. In addition, you could leverage NAT gateway and VPC ingress routing to offload the NAT function to a NAT gateway and further improve firewall performance.
High availability (HA) can be achieved by setting up a firewall HA pair with an active/passive deployment in the same AWS Availability Zone (AZ). Depending on the firewall vendor support, you could also leverage floating secondary IP addresses to provide better failover time.
Since this architecture consists of two transit gateways, it’s impossible to build an active/active firewall HA solution across multiple AZs. In order to maintain route symmetry for each stateful firewall, the appliance mode feature is required but does not span across multiple transit gateways. This is due to each transit gateway maintaining its own session affinity, which could select a different (firewall) ENI within another AZ, causing return traffic getting dropped.
However, you can still implement a cross-AZ firewall HA solution with an active/passive deployment, and to switch over traffic to a secondary firewall in the event of a primary firewall/AZ failure. This process can be monitored and remediated through an automated pipeline such as AWS Lambda functions.
Inbound Access from the Internet
Similar to the outbound internet access, inbound access from the internet to SDDCs also requires DNAT to be configured at the firewall appliance using the internet interface address. You can configure secondary IPs on the firewall internet interface with additional public EIPs to publish more internal services.
An alternative option is to leverage a dedicated ingress VPC with Application Load Balancers to terminate inbound connections, before forwarding traffic to the web or app virtual machines running in the SDDCs. This option provides better efficiency and scalability while reducing costs by conserving public EIPs.
In this post, we took a closer look at a centralized Security VPC architecture for integrating third-party firewall solutions with VMware Cloud on AWS, using the VMware Transit Connect feature.
We also went through a real example of integrating a Palo Alto firewall appliance with VMware Cloud on AWS based on this reference architecture.
To learn more, I recommend you review these additional resources: