How I did it: Leveraging Aviatrix to simplify F5 SSL Orchestrator deployments in public cloud

In increasing numbers, more and more companies are moving their workloads from on-premises locations to the public cloud. Along with moving their applications, they also need to move their network and application security to the public cloud as well.

On-premises environments offer you control at every layer, from hypervisor to physical routers, firewalls, advanced services appliances and so forth. You can define layers, zones and route traffic thru them as you like.

However, in the public cloud, the same rich set of networking capabilities may not be present, and this makes inserting F5 SSL Orchestrator transparently in the traffic flow more complex. It can be done, but it requires creating a set of routing table rules that must be maintained.

In this blog post, I’m going to give a high-level walkthrough of how I leveraged Aviatrix to simplify the transparent insertion of F5 SSL Orchestrator into the traffic flow.

What is F5 SSL Orchestrator?

Organizations need to protect critical assets from threats that originate both outside and inside the corporate environment. However, most traffic is now encrypted, and existing security controls are unable to perform decryption at the scale required to enable inspection, leaving critical assets vulnerable. F5 SSL Orchestrator provides policy-based orchestration to enable cost-effective visibility across the full security chain for any network topology, device, or application.

F5 SSL Orchestrator provides high-performance decryption of inbound and outbound SSL/TLS traffic, enabling security inspection to expose threats and stop attacks. Dynamic service chaining and policy-based traffic steering allow organizations to intelligently manage encrypted traffic flows across the entire security chain with optimal availability.

SSL Orchestrator ensures encrypted traffic can be decrypted, inspected by security controls, then re-encrypted, delivering enhanced visibility to mitigate threats traversing the network. As a result, organizations maximize their security services investment for malware, data loss prevention (DLP), ransomware, and next-generation firewalls (NGFW), thereby preventing inbound and outbound threats, including exploitation, callback, and data exfiltration.

An example SSL Orchestrator service chain with 3 inspection services:

What is Aviatrix?

The process of manually maintaining public cloud route tables can be difficult, tedious, and susceptible to human error—making it the ideal candidate for automation. This automation is provided by Aviatrix, which dramatically simplifies VPC-to-VPC, VNet-to-VNet, and even cloud-to-cloud “network plumbing” at large scale.

The Aviatrix cloud network platform delivers the advanced networking, security and operational visibility services required by enterprises, while maintaining the simplicity and automation of cloud.

Aviatrix implements a hub and spoke model where the Aviatrix Transit Gateway is the hub and Aviatrix gateways deployed in a VPC/VNet are the spokes. When the spoke gateways connect to the Aviatrix Transit Gateway, they establish and maintain an encrypted tunnel.

The Aviatrix gateways manage traffic as it enters and exits to and from a VPC/VNet. Aviatrix can be deployed in AWS, Azure, Google Cloud and Oracle Cloud.

How Aviatrix simplifies F5 SSL Orchestrator integrations

Defining the potentially complex routing needed to transparently insert F5 SSL Orchestrator into the traffic flow can be very challenging. Moreover, as the environment changes, these routing tables will need to be updated.

Aviatrix understands and leverages the public cloud API infrastructure and can dynamically define and adjust the routing tables as needed.

Aviatrix Firewall Network (FireNet) combines the intelligent orchestration and automation provided by the Aviatrix Controller with advanced Aviatrix Transit capabilities to significantly simplify transparent insertion of F5 SSL Orchestrator into the traffic flow. The combined solution eliminates the need for administrators to manually propagate routes and update routing tables when changes are made to the environment.

Additionally, since SSL Orchestrator takes on all SSL/TLS de-encryption and re-encryption that would otherwise be done by security inspection devices, performance improves for those devices as well. For high availability, Aviatrix provides scaling active / active F5 SSL Orchestrators across availability zones. Aviatrix further contributes to overall security effectiveness by preserving source IP addresses that are critical to security policy enforcement.

To transparently insert F5 SSL Orchestrator into the flow of traffic between two VPC/VNets, simply put one of the Aviatrix spoke gateways into an Aviatrix inspection policy. Behind the scenes, Aviatrix updates the routing table to ensure that the traffic from the source is transparently routed first to F5 SSL Orchestrator.

At this point, F5 SSL Orchestrator will select the appropriate service chain based on defined policy and will route the traffic through one or more security inspection services. Assuming none of the services in the chain block the traffic, F5 SSL Orchestrator forwards the traffic to the original destination.

As this graphic illustrates, due to an Aviatrix inspection policy, traffic from the Dev VPC is first routed to F5 SSL Orchestrator and the service chain before reaching the QA VPC.

High Level Walkthrough

This is a high-level walkthrough of what I did to create the deployment pictured above in AWS and not a step-by-step deployment guide. Both the Aviatrix and F5 SSL Orchestrator documentation provide the detailed steps necessary (please see links at bottom of blog).

The steps to create the deployment:

Deploy Aviatrix Controller
Create Aviatrix transit VPC
Deploy Aviatrix transit gateway
Enable Aviatrix FireNet function
Create application VPCs
Deploy Aviatrix spoke gateways into application VPCs
Connect Aviatrix spoke gateways to the Aviatrix transit gateway
Deploy F5 SSL Orchestrator
Put one of the spoke gateways into an Aviatrix inspection policy

Deploy the Aviatrix Controller

I launched the Aviatrix controller from the AWS Marketplace and, after supplying the values appropriate for my deployment, the Aviatrix controller was up and running in a new VPC.

I connected to the newly launched Aviatrix controller via a web browser and, after establishing a new password, was ready to move on to the next steps.

Because the Aviatrix controller understands the public cloud APIs, the controller can be used to create the VPCs instead of using the AWS console. In my case, I used the Aviatrix controller to create all the VPCs.

Create Aviatrix Transit VPC

Using the Aviatrix controller, I created a new VPC and checked the box to enable it as an Aviatrix Transit VPC. By doing so, all necessary subnets and route tables needed by the Aviatrix Transit will automatically be created. Cool.

Deploy Aviatrix Transit Gateway

The Aviatrix Transit gateway is the hub part of the Aviatrix hub and spoke architecture and is what provides the “glue” that connects the rest of the pieces together.

I used the Aviatrix controller to deploy the transit gateway into the transit VPC created in the previous step. As part of the gateway deployment, an EC2 instance size needs to be specified. The larger the instance size, the more traffic throughput an Aviatrix transit gateway can support.

My deployment has a single transit gateway, but I could have enabled Aviatrix gateway high availability by simply clicking on a button to enable it and Aviatrix would have launched a second transit gateway. Easy.

Enable Aviatrix FireNet function

Aviatrix calls the feature that simplifies integration of firewall instances into the environment, FireNet – short for “Firewall Network”. It is this feature that is leveraged to transparently insert F5 SSL Orchestrator into the traffic flow.

I used the Aviatrix controller to enable the FireNet feature on the Aviatrix transit gateway created in the previous step by simply clicking the button to enable it.

Create Application VPCs

I used the Aviatrix controller to create the Dev, QA and Prod application VPCs, but I could also have created the VPCs using the AWS console. Each application VPC needs to have a public subnet defined.

In each application VPC, I deployed an Ubuntu instance and then deployed an Nginx web server as well.

Deploy Aviatrix spoke gateways

Aviatrix spoke gateways are used to connect a VPC to an Aviatrix Transit gateway over an encrypted tunnel and each of the application VPCs need to have a spoke gateway deployed.

I used the Aviatrix controller to launch a spoke gateway into each application VPC. As a part of that, I referenced the public subnet of each VPC as well as the spoke gateway instance size. Like the transit gateway, the larger the EC2 instance size, the higher traffic throughput the spoke gateway can support.

My deployment has a single spoke gateway in each application VPC, but I could have enabled Aviatrix spoke gateway high availability by simply clicking on a button to enable it and Aviatrix would have launched a second spoke gateway. Simple.

Attach Aviatrix spoke gateways to Aviatrix transit gateway

In my deployment, the Aviatrix Transit gateway is used to route traffic between the different application VPCs and each spoke gateway needs to be connected to the transit gateway.

I used the Aviatrix controller to attach each spoke gateway to the transit gateway. At this point, I was able to access each of the Nginx web server instances from each of the application VPCs.

Deploy F5 SSL Orchestrator

I’m not going to cover the steps necessary to actually deploy F5 SSL Orchestrator in AWS, but F5 has deployment guides for SSL Orchestrator that cover the details of how to do it. Please see links at bottom of blog post.

However, in order for Aviatrix to transparently route traffic to it, F5 SSL Orchestrator does have to be deployed into the Aviatrix Transit VPC that has the FireNet feature enabled.

In order for the traffic to be properly routed by Aviatrix once it has been processed by an SSL Orchestrator service chain, the BIG-IP with SSL Orchestrator must have the default route configured to point to the Aviatrix gateway.

Define F5 SSL Orchestrator as a firewall in Aviatrix

The use case for my deployment is transparent insertion of F5 SSL Orchestrator into the traffic flow. In order for Aviatrix to do its routing magic and redirect traffic to F5 SSL Orchestrator, I had to define F5 SSL Orchestrator as a firewall in the Aviatrix FireNet configuration. Even though I’m not leveraging F5 Advanced Firewall Manager in this deployment, to Aviatrix, F5 SSL Orchestrator is considered, generically, as a firewall.

Basically, Aviatrix needs to know which F5 SSL Orchestrator interface to send client traffic to and which interface the traffic will exit from F5 SSL Orchestrator.

Other than defining the F5 SSL Orchestrator ingress and egress interfaces to Aviatrix, there was nothing more I needed to do in order for Aviatrix to be ready to transparently insert F5 SSL Orchestrator into the traffic flow by manipulating the AWS routing tables.

Put one of the spoke gateways in an inspection policy

In the previous step, I added F5 SSL Orchestrator as a firewall in the Aviatrix FireNet configuration. However, in order for Aviatrix to transparently insert F5 SSL Orchestrator into the traffic flow, I had to put one of the spoke gateways into an inspection policy.

An Aviatrix inspection policy is applied when traffic ingresses or egresses to and from a VPC that has a spoke gateway that is defined in an inspection policy. When traffic hits the spoke gateway that is in an inspection policy, Aviatrix transparently re-routes traffic to the firewall defined to Aviatrix FireNet which, in my case, is F5 SSL Orchestrator.

For my use case, I wanted traffic going in and out of the QA application VPC to be routed to F5 SSL Orchestrator so that the services in a security chain could scan the cleartext traffic for threats. I did this by simply selecting the QA spoke gateway in an Aviatrix inspection policy.

Once the traffic has been processed by the service chain(s) defined in F5 SSL Orchestrator, the traffic is sent back to the Aviatrix gateway which then routes the traffic to its original destination.

I never had to know or understand which route tables had to be modified or what specific routes were needed to insert F5 SSL Orchestrator transparently into the traffic flow. Aviatrix took care of all the messy details for me.

Did someone say multi-cloud?

The walkthrough I’ve documented is all within AWS, but Aviatrix works with AWS, Azure, Google Cloud and Oracle Cloud. Just as I did in AWS, I could have replicated the exact same deployment in the other public clouds. More to the point, I could also establish connectivity between two or more cloud providers with Aviatrix providing the encrypted tunnels and routing between them. So, multi-cloud is no more difficult to configure than a single cloud.

Summary

As I have shown through this blog post and walkthrough, the class-leading SSL decryption and security service chaining capability of F5 SSL Orchestrator together with the advanced, dynamic public cloud routing features of Aviatrix, makes for a stellar combination that is both powerful, yet simple to implement at the same time.