article

Centralizing Cloud Security with F5 and AWS Transit Gateway

Today we were fortunate to be a launch partner of AWS for their newly announced Transit Gateway feature, known as TGW.

We've had the opportunity to get our hands on TGW while it's been in private beta, and as a networking vendor up in AWS, we're just as excited about the functionality as AWS (if not more!). TGW will give customers more flexibility, and more control in their cloud routing. This means more opportunity to take advantage of the unique functionality that your F5 devices provides up in AWS.

Working with the AWS team here at f5, we had a pretty enlightening brain storming session focused on what use cases TGW could provide for our customers. Centralized routing will open a lot of doors for our customers, especially when it comes to security.

F5 and TGW Use Cases

One use case that seems to make obvious sense to us is using TGW to enforce complete traffic sanitization through a dedicated security VPC. In the example below, our fictitious enterprise built and populated a VPC with a series of our Advanced WAF VMs in a scale set. We then configured global route rules within our TGW to route all inbound traffic through this VPC, ensuring that this traffic would flow through the AWAF farm before making it on to its final destination, regardless of which AWS region/VPC the VM resided in.

Another use case for our fictitious enterprise would be to use TGW to enforce outbound traffic to flow through a forward proxy, such as F5's Secure Web Gateway, before leaving the AWS cloud. By connecting the on-premises datacenters, headquarters, and branch offices to AWS via Direct Connect or VPN, you now have a truly dynamically scalable outbound security filter for your cloud and on-premises based workloads.

In the next section of this post, I will walk you through setting up a POC environment utilizing an AWS transit gateway and the F5 Advanced WAF to act as a centralized security enforcement engine as described in the first use case above.

Let’s Make it Easy

To facilitate a quick and relatively painless process, we created a deployment CFT that will make quick work of the heavy lifting. Along with ancillary services, ( i.e. route tables, security groups, etc.), the template will deploy the following POC environment into US-East-2 region. The POC, (as shown below) consists of:

IMPORTANT: The provided template is unsupported and offered entirely “as is” and is by no means intended for production use. In addition to AWS services this template will deploy three, (3) virtual machines. Refer to the above links for licensing terms & conditions. To successfully deploy the CFT, you may first be required to accept the aforementioned terms & conditions. For ease of use the template deploys a statically configured environment with limited options. Feel free to clone and modify as desired.

Deploy the CFT

Using the AWS console, navigate to the ‘US-East-2, (Ohio)’ region and create a new CloudFormation stack by uploading the template; select ‘Next’ to continue

Provide a stack name and select previously created sshKey; select ‘Next’ to continue

Select ‘Next’ on the next screen to continue

Acknowledge and accept terms; select ‘Create’ to deploy the template

Deployed Resources

Once completed, (approximately 7-10 minutes) you can view the various resources created

VM Instances ( 3 total)

VPCs and Subnets ( 3 total)

Route Tables, ( 2 total)

Transit Gateway

Complete the Deployment - The Outputs Section

To finish setting up the POC environment, you will need to attach the VPCs to the TGW as well as add the appropriate routes to the newly created VPC route tables. As of this post, these last two steps must be completed via AW CLI*. Not to worry, the ‘Outputs’ section of the newly deployed CFT, (see below) contains the required commands.

Validating the POC Environment

Now that you have the environment stood up and access to the F5 configured, let’s take a look at the Advanced WAF.

Login to the F5 WAF using the aforementioned Url

From the main page, navigate to ‘Local Traffic’ –> ‘Pools’. If the attachments and routes were added successfully the existing web pool should have a green status.

Select the pool from the middle pane and click on ‘Members’. Both member servers, (located in ‘ApplicationVpc’ and ‘Application2Vpc’ respectively) should have a green status. This signifies that the BIG-IP, (located in the ‘SecurityVpc’) is able to communicate and pass traffic across the TGW and back to the web pool members.

Thanks for sharing info about TGW. I am not AWS pro so I have some questions:

Would it be impossible to create setups described in article without TGW or it will be just much more complicated?

I have issue with understanding this sentence: "We then configured global route rules within our TGW to route all inbound traffic through this VPC, ensuring that this traffic would flow through the AWAF farm before making it on to its final destination, regardless of which AWS region/VPC the VM resided in." - looking at the diagram traffic from Internet has to pass via Security VPC anyway. TGW is located behind Security VPC so routes in TGW are rather assuring that traffic leaving Security VPC will be routed to web server instance in the correct VPC as well (but I am not sure here) that returning traffic from vweb server will pass AWAF on the way back to Internet - or I am completely wrong here?

What is purpose of AWS WAF with F5 rule set (I have some idea what F5 rule set is) - what is protected by AWS WAF in this case - seems that not backend web servers as those are protected by F5 AWAF.

the workaround to transit gateway is creating a full mesh of VPN peering to interconnect VPCs. While in this example you have only 3 VPCs, it can become much more complex if you have tens of them. Specifically in use case where you to need to communicate between VPCs.

Security VPC describerd here is just a traditional VPC, so you have to make sure that inbound traffic, including traffic from other VPCs and VPNs, to back end servers are going first through the security VPC. The AWS Transit Gateway is fronting any VPC interconnecting to VPNs and Internet.

just a matter of courtesy here :) exposing an AWS WAF here allows easily delegating some security features to app team to manage their app access, while we enforce a more robust and deep security on the F5 A.WAF side on generic features not covered by AWS (L7 DDOS ,Anti Bot ...)