F5 Distributed Cloud - Regional Decryption with Virtual Sites
Introduction:
With the continued growth of multi-cloud infrastructures, enterprises are looking for a "cloud above the clouds" as their new strategic point of delivery and control. This is exactly what the F5 Distributed Cloud (F5 XC) provides with its SaaS-delivered data planes that we call Regional Edges (RE). The F5 Distributed Cloud enables enterprises to use our SaaS platform for Application Proxying, Load Balancing, Web Application Firewall, API Discovery, and Security, Bot and Fraud Protection, Multi-Cloud Networking, and much more. To achieve these multi-cloud delivery and security solutions, we must terminate TLS within our Regional Edges. However, what if your organization has rules and regulations around encryption, such that inspection points and key storage must reside within specific countries or continents in which the enterprise operates? Let's look at how you can resolve this challenge with F5 Distributed Cloud's Virtual Site configuration.
F5 Distributed Cloud - Networking Overview
By default, our F5 Distributed Cloud's SaaS data
planes of Regional Edges are connected to two networks, the Internet, and the F5 Global Backbone. Our Global Backbone is a multi-terrabit, low-latency physical network with a software-defined, distributed overlay network. We call this the F5 Distributed Cloud Application Delivery Network (ADN). The ADN provides interconnectivity between our Regional Edges, Customer's Data Centers, Customer's Clouds, and our Customer Edge software. If you review Hurricane Electric Internet Services BGP Peering Report, you'll see F5 is one of the most peered global networks in the world with almost 5000 IPv4 adjacencies and almost 4000 IPv6 adjacencies.These adjacencies are critical to the success of our Anycast route advertisement, which uses the underlay routing of the internet for BGP multi-path to route clients to the nearest Regional Edge. Internet standards require organizations advertising network prefixes to the internet to be a /24 or greater. F5 Distributed Cloud advertises multiple /24 or greater prefixes globally from all Regional Edges. If you're a networking nerd like me, you can dig deeper into F5's advertisements via Hurricane Electric, linked above. If you're curious about how internet advertisements have changed over the years, you might refer to APNIC's article on BGP in 2021 - The BGP Table, where they review how the internet routing tables have changed over the years.
The Solution
Let's step through this diagram and discuss how this solution works. You can see All Region Edges are advertising a /24 of 185.56.152.0 to the internet. Now let's imagine we want to have two custom topologies, one for North America's Regional Edges, and one for Regional Edges within Europe. We would configure two new Virtual Sites, which I will show you how to do the steps in the next section. There is a pre-requisite to setting up decryption topologies via Virtual Sites; we need an additional Virtual IP (VIP) address per topology within the tenant. Remember, a tenant comes with a single IP by default, but you can add additional IPs. These IPs can come from the F5 Distributed Cloud blocks, or you can Bring Your Own IPs (BYOIP), but this requires that you bring a full /24 due to the rules of the internet for advertisement.
Configuration Steps:
- Create a Virtual Site - From "Select Service" - Choose "Shared Configuration" ==> Manage -> Virtual Site
- Use existing labels to choose sites or regions of sites that you would like to be included in your Regional Edge Virtual Site
- IMPORTANT - Be sure to include more than one Regional Edge for your Virtual Site
- Graphic below shows London and Paris' Regional Edges configured as part of my EU Virtual Site
- Update additional Tenant IP Address - From "Select Service" - Choose "Shared Configuration" ==> Manage -> Public IP Addresses
- Click the three dots under "Actions" and choose "Manage Configuration"
- In the top right corner, click "Edit Configuration"
- Under "Virtual Site" - choose the Virtual Site you created in Step 1
- Update VIP Advertisement on Load Balancer—From "Select Service" - Choose "Load Balancers" ==> Manage -> Load Balancer -> HTTP Load Balancer
- Since our Virtual Site and Public IP address are configured within the shared namespace, we can apply this config to any Load Balancer in any Namespace.
- Either create a new HTTP Load Balancer, or edit an existing Load Balancer's configuration
- Navigate to "Other Settings" and change the VIP Advertisement to "Internet (Specific VIP)"
- Choose the public IP Address that you modified for the Virtual Site in step 2.
Verification:
Be sure that DNS has been updated to reflect the FQDN(s) associated with the HTTP Load Balancer and now resolve to the new public IP address. Verify by running a nslookup or dig from your local machine. The reason I chose EU Regional Edges for this article was to simplify the verification that this solution is working, as I am based in the United States. My traffic will typically traverse the NY Regional Edge.
Navigate: "Select Service" - Choose "Load Balancers" ==> Virtual Host -> Load Balancer -> Click "Performance Monitoring" under your Load Balancer -> Click "Requests" tab and find your request.
You'll see for the client request below, the client is in the United States, specifically Mentor, Ohio. However, the L5-7 services, TLS Termination, Proxy, Load Balancing, and additional delivery and security features occurred in the Paris Regional Edge (pa4-par). When reviewing your request, you can click on the JSON tab, which provides upwards of 100 attributes of each request.
For this specific traffic flow, the client traversed the Internet to our NY Regional Edge, then utilized the F5 Global Backbone to the nearest Regional Edge configured as part of the Virtual Site, which in this client's case the BGP multi-path of Paris. Once the traffic arrives in the Virtual Site Regional Edge (Paris), the F5 XC Software then provides L3-L7 services, most importantly, TLS termination and proxying of the traffic.
In the below diagram, we see this traffic flow as red line traversing the internet, yellow line using F5 Global Backbone, and green line within the Virtual Site Regional Edge. The green line would be the termination point for the client-side traffic flow. This client-side flow is to the Regional Edge software where L3-4 connection is established, the TLS session setup begins, and ultimately where application layer services would be proxied to the origin service.
Summary:
I hope you found this article useful and learned how F5 Distributed Cloud allows you to be specific in where your keys are stored and utilized for TLS termination within the F5 Distributed Cloud SaaS architecture. By using Virtual Sites and additional Public IP Addresses, you can build custom topologies of our Regional Edges over the F5 Global Backbone. Please leave comments or questions, and I'd be happy to update the article or provide answers directly in the comments.
Additional Links to Distributed Cloud Content:
Kubernetes Architecture Options with F5 Distributed Cloud
App Stack, the "iRule" of F5 Distributed Cloud
Multi-Cluster, Multi-Cloud Networking for K8S with F5 Distributed Cloud – Architecture Pattern
- MichaelOLearyEmployee
Thanks for the article Matt. I've had customers ask about steering traffic through certain regions. Sometimes it's because they don't want their TLS private key stored outside of their own country/region, but sometimes it's just because they want all traffic flow to go through a given region. I never knew about this possibility before now.
- pkuligowskiEmployee
What an amazing article, thanks Matt!