cancel
Showing results for 
Search instead for 
Did you mean: 
Dave_Potter
F5 Employee
F5 Employee

Preface -- Routing & Security

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.

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 (F5XC) provides an integrated multi-cloud networking feature allowing private business data to transit its low-latency backbone to other public and private sites regardless of the provider.

Here's how to use F5XC 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 F5XC’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.

Picture-MCNTransit-1.png

Prequisites

  • AWS: Programmatic API access to an AWS subscription
  • Azure: F5XC as an Azure AD App registration
  • (Optional): Existing VPC in AWS to attach to the F5DC TGW VPC
  • (Optional): Existing deployed AWS VPN VPC with legacy workloads or services that can be attached to the F5DC virtual global network

Deployment Steps

  1. 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-sitesPicture-MCNTransit_1.png

     

  2. Navigate to “Select service” and select “Cloud & Edge Sites”. 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 NetworkPicture-MCNTransit_2.png

     

  3. 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
  4. 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 credentialsPicture-MCNTransit_3.png

     Apply


    VPC Attachments:
                Add Item
                VPC ID: [an existing VPC belonging to your AWS Subscription]Picture-MCNTransit_4.png


                 Apply

    Network Configuration
                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-networkPicture-MCNTransit_5.png

                Add Item
    Picture-MCNTransit_6.png

                Save and Exit
     
    Click “…” Actions, then Plan (optional)
    After planning finishes, click Apply
    Picture-MCNTransit_7.png
  5. As provisioning happens, observe the newly created VPC, and it will also be attached to the existing VPC (assigned in step 4 above).Picture-MCNTransit_8.png

  6. 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
    Picture-MCNTransit_10.png
                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]
    Picture-MCNTransit_11.png

                Save and Exit

  7. Click “Apply” to consummate planning and deployment of the Azure VNET Site service.
    Picture-MCNTransit_12.png

     Wait and confirm that the service has successfully deployed.
    Picture-MCNTransit_13.png

  8. 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.

  9. 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
    Picture-MCNTransit_14.png

                Save and Exit

  10. 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.
    Picture-MCNTransit_16.png

  11. 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 F5DC-created 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.
    Picture-MCNTransit_15.png

     

  12. 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 F5DC 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 F5DC 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.
    Picture-MCNTransit_17.png

     

    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 video to follow along and see how I do this exact deployment using the F5 Distributed Cloud Console and each cloud provider's web interface.

 

Version history
Last update:
‎22-Jul-2022 16:18
Updated by:
Contributors