17-Jan-2023 05:00 - edited 02-Jul-2023 03:17
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 utilize 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.
By default, our F5 Distributed Cloud's SaaS data
These adjacencies are critical to the success of our Anycast route advertisement which utilizes 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.
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 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.
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 sesssion setup would begin, and ultimately where application layer services would be proxied to the origin service.
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 utilizing 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.
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
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.