Integrate BIG-IP with AWS CloudWAN Service Insertion

As organizations develop larger hybrid cloud architectures, many are adopting a cloud-based WAN architecture.  In a cloud-based WAN architecture, an organization uses the global network of a cloud provider to create the WAN between their remote facilities, data centers, and public cloud deployments.  Organizations gain tremendous benefits with the ability to create over the top (OTP) WAN topologies that can be based on consumer or commercial-grade internet connections, increasing agility for the organization.

This agility does come with responsibility as organizations leveraging cloud-based WAN solutions need to insert security services.  To ease this integration, AWS introduced Cloud WAN service insertion, allowing users to pragmatically stitch security services into the Cloud WAN fabric.  The ability to inspect traffic and mitigate the risk of threat actors pivoting across the environment is critical for organizations in every industry.  This is why F5 has partnered with AWS to support organizations security needs and integrate F5 security portfolio into Cloud WAN service insertion.

In a Cloud Wan deployment, you have a Cloud WAN, core network, policy, and segments.  VPCs, VPNs, Cloud WAN Connect, or transit gateways are attached to a Cloud WAN segment, creating the network topology allowing traffic to flow.  AWS Cloud WAN service insertion introduces the concept of a Network Function Group (NFG) that allows for traffic to be steered to security and inspection services based on network policy. 

 

WHY F5

F5 excels at creating systems that span the OSI model with our full proxy technology.  The BIG-IP proxy technology allows organizations to apply advanced networking and security controls into the traffic path while inspecting and securing 30+ protocols with Advanced Firewall Module.  In Addition, F5 SSL Orchestrator can be leveraged to create dynamic security chains and SSL decryption at scale for traffic traversing the WAN allowing for multi-vendor security services to be inserted via a single policy.  You can read more about AFM and SSLO Orchestrator on DevCentral.

 

Your Computing Environment 

Your organization has multiple computing environments, and you are using Cloud WAN to connect them.  These computing environments are connected to Cloud WAN via an “attachment”.  These attachments can be VPCs, VPNs, Connect or Transit Gateway Route Tables.

In our topology, we will use VPCs for our attachments.  In our diagram we have 4 VPCs (2 Prod, 2 Dev) and two segments (f5CWAN and Dev).  Currently traffic flows between the Prod VPCs and the Dev VPCs and the segments cannot communicate with each other. We also deployed security services VPCs.  All of these VPCs are attached to the Core Network.

In our example, we will focus on how you would deploy F5 security in AWS using Cloud WAN but you could also use these services from your on-premises deployment (or any other location) that Cloud WAN Service Insertion allows you to leverage.

Examining the Security VPC Architecture Options

At this point, we have a general picture of a Cloud WAN. We need to explore the two options we have to architect the security VPCs.  The decision comes down to using or not using AWS Gateway Load Balancer.

Security VPC without Gateway Load Balancer

 In a security VPC without a Gateway Load Balancer, the deployment pattern consists of one BIG-IP (or HA pair of BIG-IPs using F5 Cloud Failover Extension) in each Availability Zone (AZ).  For logical clarity and greatest control, some users will find that 2 subnets and 2 route tables per AZ makes the most sense to control the routing. From a forwarding standpoint, traffic enters an AZ via a Cloud WAN attachment located in a subnet.  Based on that subnet’s route table (1) traffic will be forwarded to an Elastic Network Interface (ENI) on BIG-IP.  When traffic leaves BIG-IP the routing table on that subnet (2) forwards the traffic back to the Cloud WAN attachment.

Security VPC with Gateway Load Balancer

In this topology we will deploy the Cloud WAN attachments in dedicated subnets, the VPC Endpoints in dedicated subnets, and then the Gateway Load Balancer and BIG-IPs.  Traffic enters into the VPC via the attachment ENIs and the respective route table will steer the traffic to the VPC Endpoints.  Gateway load balancer will send the traffic over a Geneve tunnel to any one of the BIG-IP instances to be processed.  Traffic returned from the BIG-IP will go back over the Geneve tunnel to the gateway load balancer endpoint and the route table of the respective subnet will send the traffic back to the Cloud WAN attachment.

In the firewall VPC, it is critical to leverage Appliance Mode due to the symmetric nature of traffic flows that are inspected by security services.

 

What pattern should you deploy?

Deciding between which pattern should be deployed is a combination of decisions.  The pivotal decision is scalability and resiliency.  By introducing Gateway Load Balancer in the topology, we can provide horizontal scale within and across AZs.  This is rooted in AWS routing, where within a given route table you can only have one route for a destination. In our topology, that route is pointed towards a network interface.  If that network interface belongs to an instance, then the capacity of traffic is equal to the instance.  If the network interface belongs to a GWLB the capacity is N number of AFM or SSLo instances.   Additionally, GWLB will address the resiliency requirements of the security instances and supports AWS Auto Scale.

 

Which F5 Security Solution Should be Used?

If the requirements are that you need to inject firewall and IPS services, then leveraging F5 AFM will meet your core requirements.  You can apply the same security policy to all traffic in the environment or you can define more specific policies based on virtual server precedence.  If you have more dynamic needs and would like to be able to insert additional security services into the traffic flow based on service chain polices, then F5 SSL Orchestrator would be a better match.  To learn more about how SSL Orchestrator was applied to AWS Gateway Load Balancer please see the DevCentral Article on how to increase security without rearchitecting your applications. 

 

Cloud WAN Attachments

In our validation topology, all of our systems are deployed in VPCs but you will see that the applications are attached to F5cwan segment and the security VPC is attached to a NFG. 

 

Mapping Attachments to function

The attachment is placed in the NFG based on the attachment tags.  In our scenario we are working with two tags, one tag, f5-cwan, attaches the VPCS to the segment f5cwan.  The other tag, f5security attaches to the f5security NFG.

 

In our sample deployment, we will use Cloud WAN to connect a VPC in US-EAST-1 to a VPC in US-WEST-2 and we will deploy a single Network Function group in US-EAST-1 to inspect all the traffic.  Your organization can deploy Network Function groups and attachments in all, some or one region based on your needs.  From an F5 standpoint, this a reflection of both AWS and your organization’s security needs.

 

Understanding the Service Insertion Network

Our security VPCs will be attached to our Cloud WAN via a network function group. At this point, a user leverages Cloud WAN and tells them their intent, such as if they want to inspect all traffic between attachments on the same segment or between attachments on different segments. Users can also instruct Cloud WAN if that traffic should only be inspected once or if it should be inspected by the near side and far side network function groups.  In our example policy, we will instruct our Cloud WAN to inspect traffic between attachments on the same segment named f5cwan

 

The area highlighted in red shows us the network function groups we have.  The area highlighted in green is the policy that matches the tags on our Cloud WAN attachments to a segment or a network function group.  The area highlighted in orange says that attachments on our f5cwan segment will be sent via the f5security network function group and should only be inspected one time (single hop). To create isolation on the segment we need to configure our attachments to be isolated in our segment policy.

Based on this policy we have a network map topology that has an east and west VPC connected to the f5cwan segment and a security VPC that is connected to the Cloud WAN edge in us-east-1

All traffic between the two segments will flow through the security services in us-east-1.

 

Traffic Flow Across the WAN

Now that we understand the attachments and the VPC architectures, how should traffic flow?  In our example topology, traffic will flow from a client in us-east-1 to a Cloud WAN attachment. Our Cloud WAN service insertion will instruct the system to send the traffic to the security service VPC.  The routing in the security service VPC will send the traffic to the service, and if the traffic is allowed, the traffic will flow out to the server in us-west-2.  On the return, traffic will repeat the pattern

If we apply the flow to the original architecture, we will see a picture like this:

Having an extensive background in networking, I always want to see it “on the wire” via a packet capture.  So let’s test it out.  I will send a ping and a curl command from my server in us-east-1 to my server in us-west-2. 

Looking at the server in us-west-2

Now let’s look at the BIG-IP running in my f5security network function group in us-east-1.  Here you can see that the traffic was sent to the BIG-IP (in) and then sent back to the VPC network (out)

 

Conclusion

 

AWS Cloud WAN is being adopted by many organizations and it is critical to secure traffic that traverses this service.  By using F5 security solutions with AWS Cloud WAN service insertion you can enjoy the networking benefits of AWS Cloud WAN while providing the security, control and visibility your organization requires.  To learn more or to see it in action please contact your F5 Solutions Engineer.