Ingress/Egress and inter VPC inspection with BIG-IP and GWLB deployment pattern

Introduction

The previous article in this series provided an overview of the BIG-IP and Gateway Load Balancer integration, this article covers a deployment pattern for inspecting various traffic flows between VPC's by leveraging this integration and AWS Transit Gateway

Baseline:

The following diagram represents the network we would like to protect, this is a common pattern that creates a centralized ingress/egress point for all of the VPC's through the 'internet VPC', each 'spoke VPC' connects to a Transit Gateway (TGW) which provides connectivity to the other spoke VPC's and to the internet VPC. With this baseline state each spoke VPC can communicate with all other VPC's without any inspection through the transit gateway. Internet traffic is not inspected as well

Goal:

Inspect all traffic between the VPC's and internet traffic using BIG-IP security services. Support dynamic scale of the inspection service.

Deployment pattern:

With the baseline and goal in mind, we will leverage GWLB to insert BIG-IP security services into the relevant traffic flows. we will leverage GWLB's ability to separate the security devices (BIG-IP's) from the workloads they are protecting. The BIG-IP's will be deployed in their own VPC – the Security VPC.

Next, we can dive into each of the individual tasks:

The Security VPC
Provisioning the network to send traffic through the security VPC

The security VPC

The BIG-IP fleet is deployed in a dedicated security VPC. GWLB is used to distribute the traffic to the BIG-IP target group, the GWLB is exposed using the 'GWLB endpoint service'. As this VPC will be attached to the TGW, we need to create TGW attachments. The TWG attachments are created in their own subnets to gain more control over routing. Next, we create GWLB endpoints in multiple availability zones inside the security VPC. Finally, the routing tables are adjusted to send all traffic from the TGW attachment subnets (traffic that needs to be inspected) to the GWLB endpoint in the respective AZ. Traffic that was inspected is routed back to the TGW (using the GWLB endpoint routing table).

These are the actions we need to take in the provider VPC to work with TGW:

Deploy a group of BIG-IP's
Create a GWLB target group and associate the BIG-IP's to it
Create a GWLB and assign the previously created target group to the listener
Create a GWLB endpoint service and associate it with the GWLB
Configure the BIG-IP's to receive traffic over the tunnel and inspect according to the desired policy
Create TGW attachments to dedicated subnets
Create GWLB endpoints and attach them to the GWLB service
Configure the routing tables to send all traffic from the TGW attachments to the GWLB endpoints, and from the GWLB to the TGW attachments (Traffic from the security VPC to the TGW will use a dedicated TGW routing table)
On the TGW, the security VPC will use its own routing table that allows it to reach anywhere in the network – 'Security VPC Rtb', this routing table will receive traffic coming back from the security VPC after inspection which means that we can send it directly to the destination.

Diagram: Security VPC with TGW attachments

Provisioning the network to send traffic through the security VPC

Now that we have our security services connected to the TGW, we need to provision the network to send all the relevant traffic flows to the security VPC. Controlling the traffic flows is done using the following components:

TGW routing table - TGW supports different routing tables for each attachment
Ingress routing table - Controlling traffic entering the Internet VPC from the internet through the internet gateway
Subnet routing table - Each subnet may have its own routing table, we are using this capability to control traffic

Since we are already sending all the traffic from the spoke VPC's to TGW, there is no need to change any of the routes inside the spoke VPC's. We only need to change the TGW routing table for the spoke VPC's attachments. We will create a new routing table- 'TGW ingress Rtb' that will point all traffic to the security VPC. Next, we will change the 'ingress' routing table of the internet VPC so that it sends all traffic to the security VPC for inspection.

Diagram: Ingress/Egress and inter-VPC inspection using transit gateway and GWLB

With all of the routing tables and components involved, it helps to look at a visual diagram of the traffic flows, Here are some diagrams that describes the different traffic flows and how they get inspected. Keep in mind that routing is not stateful, meaning it is our responsibility to ensure symmetric traffic flows.

Diagram: Spoke10 to Spoke20 logical traffic flow

Diagram: External user to Spoke 10 web service

Diagram: Spoke10 to the internet

Summary

This deployment pattern leverages BIG-IP security services and the GWLB integration to secure an AWS environment while offering the following benefits:

Scalability - BIG-IP's are deployed as a dynamic group that can scale to meet any performance needs.
Operational efficiency - All BIG-IP instances are active and processing traffic
Separate the security devices from the workload VPC