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
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
Inspect all traffic between the VPC's and internet traffic using BIG-IP security services. Support dynamic scale of the inspection service.
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 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:
Diagram: Security VPC with TGW attachments
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:
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
This deployment pattern leverages BIG-IP security services and the GWLB integration to secure an AWS environment while offering the following benefits:
Check out our AWS documentation:
Test the integration yourself - Use a self-service lab that you can deploy in your own AWS account (Fully automated deployment using Terraform):