Introduction
Routing between multiple private clouds is today’s reality. In addition to connectivity, businesses must enforce network access controls to protect highly-sensitive data from being widely exposed. To interconnect today’s public and private cloud networks, F5 Distributed Cloud (F5 XC) Network Connect provides an integrated multi-cloud networking platform that allows private business data to transit its low-latency backbone to other public and private sites regardless of the provider.
Here's how to use Network Connect to route traffic between multiple sites using the site-mesh feature, and see how easy it is to control access to different business resources using Distributed Cloud's firewall policy with site labels.
Solution Overview
To support the lifecycle of an app, access to the services dedicated to its three stages of deployment is available to specific areas of the business. In this solution, I have an AWS Transit Gateway-connected VPC with a spoke VPC where the ops and monitoring team is. The app is in production in a separate VPN connected VPC in AWS, is being staged in GCP where additional testing tools are located, and is being developed in a separately managed yet connected location in Azure where the developer tools are cheapest to use.
To ensure that developers do not have access to data in the production phase of the app, a firewall policy based on site labels restricts connectivity for the developers to just the dev and staging sites in the network where the app is being worked on. Meanwhile, only the production phase of the app can be accessed from an internal ops team and through the Internet.
Prequisites
- AWS: Programmatic API access to an AWS subscription
- Azure: F5 XC as an Azure AD App registration
- (Optional): Existing VPC in AWS to attach to the F5 managed TGW VPC
- (Optional): Existing deployed AWS VPN VPC with legacy workloads or services that can be attached to the F5 XC virtual global network
Deployment Steps
- Log into the F5 Distributed Cloud Console, then navigate to “Select service” and select "Shared Configuration". Add a virtual site with the following fields, then "Save & Exit".
Name: select-sites
Site Type: CE
Site Selector Expression: site-group == group-sites - Navigate to “Select service” and select “Multi-Cloud Network Connect”. Go to “Networking > Virtual Networks”, then “Add virtual network”. Enter the following to create a global virtual network, then “Save & Exit”:
Name: sites-global-network
Select Type of Network: Global Network - Navigate to “Site Management > AWS TGW Sites”, then “Add AWS TGW Site”. Enter the following:
Name: aws-tgw-site
Labels: Name=site-group Value=group-sites - Now enter the “Configure” section and enter the following to each:
AWS Configuration:
AWS Region: [region of choice, example: us-west2]
Select Services VPC: New VPC Parameters
AWS VPC Name: Autogenerate VPC Name
Primary IPv4 CIDR block: 10.10.0.0/16
Select Transit Gateway: New TGW Parameters
Select BGP ASN: Automatic
(Optional) Public SSH key: [your SSH public key, recommended for troubleshooting]
Ingress/Egress Gateway (two Interface) Nodes in AZ: [Add Items]
Show Advanced Items: on
AWS AZ Name: [your desired region’s AZ, example: us-west-2a]
Subnet for Inside Interface: Specify Subnet
Specify Subnet: New Subnet
IPv4 Subnet: 10.10.1.0/24
Workload Subnet: New Subnet
IPv4 Subnet: 10.10.2.0/24
Workload Subnet: New Subnet
IPv4 Subnet: 10.10.0.0/24
Save & Exit
Automatic Deployment: Automatic Deployment
Automatic Deployment: [your AWS programmatic API credentials]
Apply
VPC Attachments:
Add Item
VPC ID: [an existing VPC belonging to your AWS Subscription]
Network Configuration
Apply
Show Advanced Fields: on
Select Global Networks to Connect: Connect Global Networks
Add Item
Select Network Connection Type: Direct, Site Local Inside to a Global Network
Global Virtual Network: system/sites-global-network
Add Item
Save and Exit
Click “…” Actions, then Plan (optional)
After planning finishes, click Apply -
As provisioning happens, observe the newly created VPC, and it will also be attached to the existing VPC (assigned in step 4 above).
-
Add an Azure VNET Site. Navigate to Site Management > Azure VNET Sites, then click “Add Azure VNET Site”.
Enter the following parameters:
Name: azure-vnet-wus2
Labels: Name=site-group, Value=group-sites
Resource Group: RG-F5DC-usw2
Recommended Azure Region Name: westus2
Vnet: New Vnet Parameters
Azure Vnet Name: Autogenerate Vnet Name
IPv4 CIDR block: 10.40.0.0/16
Select Ingress Gateway or Ingress/Egress Gateway: Ingress/Egress Gateway (Two Interface) on Recommended Region
Ingress/Egress Gateway (Two Interface) on Recommended Region: Configure
Azure AZ Name: 1
Subnet for Inside Interface: New Subnet
IPv4 Subnet: 10.40.1.0/24
Subnet for Outside Interface: New Subnet
IPv4 Subnet: 10.40.0.0/24
Add Item
Enable "Show Advanced Fields" to expose Advanced Options
Select Global Networks to Connect: Connect Global Networks
Add Item
Select Network Connection Type: Direct, Site Local Inside to a Global Network
Add Item
Global Virtual Network: system/sites-global-network
Apply
Automatic Deployment: Automatic Deployment
Automatic Deployment: [your Azure VNET app credential]
Public SSH key: [your public ssh key, recommended for troubleshooting]Save and Exit
-
Click “Apply” to consummate planning and deployment of the Azure VNET Site service.
Wait and confirm that the service has successfully deployed.
-
In the lower left panel, select “Advanced nav options hidden”, click “Show”, and confirm the dialogue popup. This enables visibility to the setting in the step below.
-
Navigate to “Networking > Site Mesh Groups”, then click “Add site mesh group” and enter the following details:
Name: select-sites-mesh
Site Mesh Group Type: Full Mesh
Virtual Site (Sites in this group): shared/select-sitesSave and Exit
-
Navigate to “Site Connectivity > Site Mesh Group”, and click select-sites-mesh. You should now see the two sites created in this document. The final steps are required to complete connectivity to any workloads or virtual machines running in your AWS and Azure environments.
-
To send traffic from your existing stub AWS VPC, open the AWS Console, and find the route table belonging to the subnet where your workload or virtual machine(s) are located. Edit the route table and add an entry for the CIDR blocks that should be send across the new AWS Transit Gateway. The following image in an example of what this looks like in an existing AWS VPC that was attached per this procedure.
-
In the Azure Portal, go to Resource Groups or Networking and locate the subnet created by F5DC and change the routes inside the user-defined route table (rt-0) as needed to align with the following diagram. All traffic that should go across the Global Network must be sent to the SLI interface of the F5DC deployed node.
In the following example, I’ve changed the SLI subnet’s user-defined route table (UDR) in Azure to send only specific traffic over the Global Network. The next hop for 10.0.0.0/8 is to type VirtualAppliance with IP address 10.40.1.5. The exact IP address can be found in the Azure Portal by navigating to Virtual Machines > master-0 > Networking > SLI.
You've now deployed and connected internal/inside networks of two cloud sites from different providers using Layer 3 routing with the Distributed Cloud Service Global Network capability in a Site Mesh Group (Full-Mesh) configuration.
Watch my companion video to follow along and see how I do this exact deployment in the Distributed Cloud Console and in each cloud provider's web interface.
