Chapter 3. Private network peering


Ansible Automation Platform on Microsoft Azure is deployed into an independent managed resource group with its own Azure virtual network (VNet).

When initially deployed, Ansible Automation Platform on Microsoft Azure’s VNet can only send requests to external networks through the public internet.

To enable Ansible Automation Platform on Microsoft Azure to access resources in an internet-gapped deployment, when access to resources has to happen over private networks, you must configure Azure network peering between your private virtual networks and Red Hat Ansible Automation Platform on Microsoft Azure’s managed application VNet.

You can configure your Azure VNets to enable private communication between multiple Azure VNets as well as private transit routing between Azure VNets and external VPN routed networks. These VPN networks can be on-premises or on other clouds.

No two Azure networking configurations are the same. To enable user access to Ansible Automation Platform on Microsoft Azure, work with your Azure administrators to connect your deployment to your VNets and external VPN routed networks.

Note

Network peering must be configured by Azure administrators in your organizaion who are familiar with Azure networking. Configuring network changes to your Azure account can cause outages or other disruptions.

The network peering procedures described in this document are not supported by Red Hat, as the processes and services are controlled and managed by Microsoft Azure. Contact Microsoft for assistance in peering Azure networks.

While every effort has been made to align with Microsoft’s documentation for this content, there may be drift in accuracy over time. Microsoft’s documentation is the definitive source for information about networking topics for Azure.

Azure offers different ways to peer private networks. These are typically divided into two categories:

  • Hub-and-spoke peering: In this topology, there is a centralized hub VNet that other virtual networks peer with. This hub network has mechanisms to route traffic through transit routing. Cloud networks, including VPN/Express Connect connections with on-premises and other cloud networks, can communicate through the hub VNet.
  • Azure Virtual WAN (VWAN): Azure Virtual WAN is a networking service that provides simplified hub-and-spoke network modeling across Azure, on-premises, and other VPN/Direct Connect networks. For more about VWAN, refer to Microsoft’s Virtual WAN documentation.
  • Direct peering: Private networks are individually connected to one another with no routing hops between them. This is a simpler peering model: it is useful when you only want to connect a few networks.

Refer to Choose between virtual network peering and VPN gateways in the Microsoft Application architecture fundamentals guide to determine the correct peering approach for your organization.

3.1. Hub-and-spoke peering (Transit routes)

Note

Updating route tables incorrectly can break your network. Only execute the steps in these procedures if you are confident that you can reverse any unexpected network behavior.

3.1.1. Hub-and-spoke peering process overview

Prerequisites

  • You have deployed Ansible Automation Platform on Microsoft Azure.
  • You have configured and tested an Azure VNet hub-and-spoke implementation in your Azure tenant. This prerequisite requires many Azure resources to be configured, including a Virtual Network Gateway.
  • You have configured transit routing between your spoke networks, including your VPNs. Refer to Configure VPN gateway transit for virtual network peering in the Microsoft Azure documentation for instructions.
  • You have identified the following:

    • The CIDR block(s) of your existing VNets (including VPNs & direct connects) that will need access to Ansible Automation Platform on Microsoft Azure UIs.
    • The CIDR block(s) of your existing VNets (including VPNs & direct connects) that will contain hosts or endpoints for Ansible automation.
    • The CIDR blocks of the Ansible Automation Platform on Microsoft Azure VNet from the managed resource group of the application. Refer to Finding the CIDR Block of the managed resource group for instructions.

Before peering any networks, ensure that there is no network address space overlap between your private VNets and your Ansible Automation Platform on Microsoft Azure network.

Procedure

  1. Find the CIDR Block for the Ansible Automation Platform on Microsoft Azure managed application Kubernetes cluster. See Finding the CIDR Block of the managed application Kubernetes cluster.
  2. Configure Network Peering with the Ansible Automation Platform Subnet. See Configuring Network Peering with the Ansible Automation Platform Subnet.
  3. Update the route tables:

    1. Configure route tables from your existing networks to send traffic to the managed application CIDR. You must add routes to the routing tables of every network requesting Ansible Automation Platform user interfaces and of every network that will have automation performed against its resources. See Routing to Ansible Automation Platform on Microsoft Azure.
    2. Configure routing to your VNets for each spoke network that you would like Ansible Automation Platform to communicate with, for automation or for accessing the user interfaces. See Routing to your VNets.

3.1.1.1. Finding the CIDR Block of the managed resource group

  1. Navigate to the Resource Groups page in the Azure portal.
  2. Click the managed resource group for Red Hat Ansible Automation Platform on Microsoft Azure. The resource group name is prefixed with “-mrg”.
  3. Select the VNet within the resource group to view its settings in the Overview page.

    The CIDR block of the cluster is displayed in the Address Space.

For further information, refer to View virtual networks and settings in the Microsoft Azure Virtual network guide.

3.1.1.2. Configuring network peering with the Ansible Automation Platform subnet

Within the Azure console, the Azure virtual network (VNet) is known as this virtual network, and the VNet that you want to peer with is known as remote virtual network.

In the Virtual Networks page in the Azure portal, use the following settings to configure peering between the Azure VNet and the VNet that you want to peer with the Ansible Automation Platform on Microsoft Azure app:

  • Under This virtual network, select settings for the Ansible Automation Platform on Microsoft Azure virtual network:

    • Peering link name: <hub_to_aap_peering_link_name>
    • Traffic to remote virtual network: Allow
    • Traffic forwarded from remove virtual network: Allow
    • Virtual network gateway or Route Server: Use this network’s gateway or Route server
  • Under Remote virtual network, select settings for the virtual network that you want to peer with Azure:

    • Peering link name: <aap_to_hub_peering_link_name>
    • Traffic to remote virtual network: Allow
    • Traffic forwarded from remote virtual network: Allow
    • Virtual network gateway or Route Server: Use the remote virtual network’s gateway or Route server

For further information on configuring peering, refer to Create a peering in the Microsoft Azure Virtual network guide.

3.1.1.3. Updating the route tables

Before you update the route tables, confirm that you satisfy the prerequisites for the hub-and-spoke peering process.

Routing to Ansible Automation Platform on Microsoft Azure

  1. Navigate to Route Tables in the Azure portal.
  2. As part of your hub-and-spoke configuration, you created one or more route tables to define the routes between the networks. Click on one of these route tables.
  3. From the route table menu bar, navigate to Routes Add.
  4. From the route table menu bar, select Routes Add.
  5. Configure routes from your existing networks to send traffic to Ansible Automation Platform. You must configure routes for any network requesting Ansible Automation Platform user interfaces and for any network that will have automation performed against its resources. For each route that you add, enter the following information:

    • Route name: Enter a route name for the Ansible Automation Platform managed application network
    • Address Prefix: The CIDR block of the managed application kubernetes cluster
    • Next Hop Type: Virtual network gateway
  6. Click OK to save the new route to the route list.

Repeat this procedure for all other route tables where you want to route traffic to Ansible Automation Platform.

Routing to your VNets

Add a route for each spoke network that you would like Ansible Automation Platform to communicate with, for automation or for accessing the user interfaces.

  1. Navigate to Route Tables in the Azure portal.
  2. In the list of route tables, select the route table for the Ansible Automation Platform on Microsoft Azure managed application.

    The name of the Ansible Automation Platform route table uses the following convention:

    aks-agentpool-<numbers>-routetable
  3. From the route table menu bar, navigate to Routes Add.
  4. Configure routing to your VNets for each spoke network that you would like Ansible Automation Platform to communicate with, for both automation or accessing the user interfaces.
  5. For each route that you add, enter the following information:

    • Route name: Enter a route name for the spoke network that you want Ansible Automation Platform to route to
    • Address Prefix: The CIDR block of the spoke network
    • Next Hop Type: Virtual network gateway
  6. Click OK to save the new route to the route list.

After you have configured the routing rules, traffic is routed to and from Ansible Automation Platform on Azure through your hub network.

Outbound routing through virtual appliances

If your organization uses Azure firewall services or third-party firewall appliances through a Virtual Appliance connection, you must configure outbound connectivity from the managed application, to enable Red Hat to maintain your application and to enable automation against external resources.

The easiest way to implement this is to create a firewall rule that allows all outbound traffic from port 443.

If you choose not to allow all outbound traffic from port 443, you must configure routes.

  • For Red Hat to manage and upgrade Ansible Automation Platform on Microsoft Azure and execute security patching, any machine in the Azure Kubernetes service (AKS) cluster must be allowed to submit a request to pull updates for containers used by Ansible Automation Platform. Add routes in the Ansible Automation Platform route table for outbound traffic from the full CIDR range of the Ansible Automation Platform on Microsoft Azure managed application to the following domains:

    • registry.redhat.io
    • quay.io
  • You must also allow traffic from your firewall to any other external domain or IP address that you want Ansible Automation Platform to run automation jobs against. Otherwise, your firewall will block connectivity between Ansible Automation Platform and destinations for automation.
3.1.1.3.1. Additional resources

For further information about adding routes to a route table in Azure, refer to Create a route in the Microsoft Azure Virtual network guide.

3.2. Azure Virtual WAN (VWAN)

3.2.1. Peering a VWAN Hub to the Ansible Automation Platform on Microsoft Azure Network

Before peering, you must connect a hub network, and at least one spoke network, to the hub network of the Azure VWAN to which you intend to connect Ansible Automation Platform on Microsoft Azure.

Prerequisites

  • A pre-configured Azure VWAN.
  • One or more of the following connections to the VWAN:

    • A DMZ network that contains Azure virtual machines that users can remotely log into to access Ansible Automation Platform on Microsoft Azure.
    • A DMZ network that contains an Azure virtual machine that local machines can connect to with SSH tunneling to access Ansible Automation Platform on Microsoft Azure.
    • A VPN or Direct Connect service to your local network that routes traffic from local machines to Ansible Automation Platform on Microsoft Azure.

Procedure

  1. Navigate to the Virtual Network Connections page for the VWAN that you want to peer with your Ansible Automation Platform instance.
  2. To create a connection between the VWAN hub and your Ansible Automation Platform instance, use the following settings:

    • Connection Name: <Ansible_Automation_Platform_connection_name>
    • Hubs: Select one or more VWAN hub networks that the managed application VNet will peer with.
    • Subscription: Select the subscription where Ansible Automation Platform on Microsoft Azure has been deployed.
    • Resource group: The managed resource group of the managed application. It is typically prefixed with “mrg-”.
    • Virtual network: The VNet of the managed application. There is only one VNet in the managed resource group.
    • Propagate to none: No
    • Associate Route Table: Select the default route table or the appropriate route table that your organization has configured for VWAN.
    • Propagate to Route Tables: Select one or more default route tables or the appropriate route table that your organization has configured for VWAN.
    • Propagate to labels: Select labels if your organization uses them.
    • Static routes: Do not complete this field.

When network peering completes, traffic routes to and from Ansible Automation Platform on Microsoft Azure though your VWAN hub network.

Additional resources

3.3. Direct peering

You can use direct peering to directly connect virtual networks. When two networks are peered, Azure updates routes between them so that traffic automatically flows between them.

The direct peering method is easier to configure than the hub-and-spoke model. However, the number of direct network peerings is limited. Direct peering becomes difficult to manage as the number of virtual networks grows, because each new network requires peering to all other networks.

3.3.1. Configuring direct network peering

You can configure network peering between your Azure network and your VNet in the Virtual Networks page of the Azure Portal.

Within the Azure console, the Azure virtual network is known as this virtual network, and the VNet that you want to peer with is known as remote virtual network.

In the Virtual Networks page in the Azure portal, use the following settings to configure the Azure network and the VNet that you want to peer with the Ansible Automation Platform on Microsoft Azure app:

  • Under This virtual network, select settings for the Ansible Automation Platform on Microsoft Azure virtual network:

    • Peering link name: <hub_to_aap_peering_link_name>
    • Traffic to remote virtual network: Allow
    • Traffic forwarded from remote virtual network: Allow
    • Virtual network gateway or Route Server: Use this network’s gateway or Route server
  • Under Remote virtual network, select settings for the virtual network that you want to peer with Azure:

    • Peering link name: <aap_to_hub_peering_link_name>
    • Subscription: Select the subscription where Ansible Automation Platform on Microsoft Azure has been deployed
    • Virtual network: Select the Ansible Automation Platform on Microsoft Azure virtual network: vnet-<aap_identifier>-<region>
    • Traffic to remote virtual network: Allow
    • Traffic forwarded from remote virtual network: Allow
    • Virtual network gateway or Route Server: Use the remote virtual network’s gateway or Route server

After you have configured direct network peering, traffic routes between Ansible Automation Platform on Microsoft Azure and private hosts and IPs on your Vnet.

For more detailed instructions for configuring peering, refer to Create a peering in the Microsoft Azure Virtual network guide.

For further information on direct peering, refer to Virtual network peering in the Microsoft Azure Virtual network guide.

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.