Ingress/Egress VPC inspection with BIG-IP and GWLB
Introduction
The previous article in this series reviewed the BIG-IP and AWS Gateway Load Balancer (GWLB) integration,
in this article we will focus on a deployment pattern that is used to inspect traffic in and out of a VPC using BIG-IP security services and GWLB.
Baseline:
In this scenario we will focus on a single existing VPC with EC2 instances and no BIG-IP security services
Goal:
Inspect traffic in and out of the VPC, scale the BIG-IP deployment as needed
Deployment pattern:
Considering the requirements and tools available, the deployment pattern will use the following attributes:
- 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. We will reference the workload VPC as the 'Consumer' VPC as it consumes security services.
- Use Routing tables in the 'consumer' VPC to send all traffic to the security VPC for inspection.
- Leverage transparent security services on the BIG-IP for inspection (BIG-IP security features configuration is out of scope for this article)
We can dive into each of the individual tasks:
- The Security VPC
- Provisioning the 'consumer' VPC network to send traffic through the security VPC
Security VPC:
Here, we are deploying the BIG-IP fleet and exposing it using GWLB. Some of the considerations when creating this VPC:
- Deploy in the same region as the 'consumer' VPC
- Design based on your availability requirements,
- Number of availability zones(AZ)
- How many BIG-IP's in each AZ
These are the actions we need to take in the provider VPC to inspect all ingress/egress traffic:
- 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
Diagram: The security VPC - BIG-IP fleet behind a GWLB, exposed using GWLB service
Consumer VPC:
In the consumer VPC, the BIG-IP group is abstracted by the GWLB and consumes the security services from the provider VPC via a new component: GWLB endpoint. This endpoint acts as bridge between the consumer VPC and the provider VPC. It essentially creates an ENI in one of the consumer's VPC subnet. Please note that a single endpoint belongs to a single availability zone and design accordingly.
Inspecting all ingress traffic requires the use of 'Ingress routing' – an AWS feature that allows sending all ingress traffic from the internet gateway to an ENI or to a GWLB endpoint.
Here are the actions we need to take in the consumer VPC to inspect all ingress/egress traffic:
- Create GWLB endpoints in each relevant availability zone that are attached to the 'GWLB endpoint service' from the provider VPC
- Change the ingress routing table so that all traffic in each AZ will get routed to the respective GWLB endpoint.
- Change the subnets routing tables so that all traffic in each AZ will get routed to the respective GWLB endpoint.
Diagram: Inspecting all ingress/egress in the Security provider VPC
Traffic flow
Ingress traffic flow between an external user and an EC2 instance in the consumer VPC:
Egress traffic flow between an EC2 instance in the consumer VPC and an external user:
Summary:
With this deployment you can protect your AWS VPC using the robust security services offered by the BIG-IP platform and get the following benefits:
- Scalability - Deploy as many BIG-IP instances as you need based on performance and availability requirements
- Transparent inspection - Inspecting the traffic without any address translation
- Optimized compute - all BIG-IP devices are active and processing traffic
Next steps:
Test the deployment yourself - Check out our self-service lab that you can deploy in your own AWS account (Fully automated deployment using Terraform):
