09-Aug-2022 05:10 - edited 21-Apr-2023 09:50
As businesses continue to adopt and depend on the unique services that multiple cloud providers offer, providing uniform connectivity and controlling access to each corner of the cloud is no longer trivial.
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.
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.
Apply
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-sites
Save 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.