Aruba SD-Branch Integration with

Azure Public Cloud

Version 2.2

Authors:
Laura Neacșu
Samuel Pérez Buñuel

Technical Note
Contributor:
Jay Wadleigh
Copyright Information
Copyright © 2022 Hewlett Packard Enterprise Development LP.

Open Source Code

This product includes code licensed under the GNU General Public License, the GNU Lesser General Public License,
and/or certain other open source licenses. A complete machine-readable copy of the source code corresponding to such
code is available upon request. This offer is valid to anyone in receipt of this information and shall expire three years
following the date of the final distribution of this product version by Hewlett Packard Enterprise Company. To obtain
such source code, send a check or money order in the amount of US $10.00 to:

Hewlett Packard Enterprise Company

Attn: General Counsel
6280 America Center Drive
San Jose, CA 95002
USA

www.arubanetworks.com

Santa Clara, CA 95054

Phone: 1-800-WIFI-LAN (+800-943-4526)

Fax 408.227.4550
 Contents

Contents

Revision History .................................................................................. 4

1 Overview ........................................................................................ 5
1.1 vGW in Public Cloud Infrastructure ............................................................................5
1.2 Virtual Gateway Orchestrator .....................................................................................6
1.3 Azure Connectivity Modes ...........................................................................................8

2 Single VNET deployment ............................................................... 9

2.1 Single VNET Architecture Overview ............................................................................9
2.2 Configuration for Single VNET Deployments ...........................................................15
2.3 Expected Result ..........................................................................................................39

3 Multi-VNET Deployments ............................................................ 42

3.1 Multi VNET Architecture Overview............................................................................42
3.2 Configuration for Multiple VNETs .............................................................................46
3.3 Expected Result ..........................................................................................................68

4 Appendix 1 – Useful Azure Procedures ...................................... 73

4.1 Basic Azure Setup .......................................................................................................73
4.2 Setting up a Test Server in Azure ..............................................................................85

5 Appendix 2 – Manual connect to Azure vWAN ........................... 91

6 Reference ................................................................................... 111

Aruba SD-Branch Integration with Azure Public Cloud Contents | 3

 Revision History ion History
The following table lists the revisions of this document:

Revision Change Description

Version 1.0 Initial Publication

Version 2.0 Multi-VNET deployment added

Version 2.1 Updated Azure Marketplace information

Version 2.2 Added vWAN integration using Cloud Connect

Table 1 Revision History

Aruba SD-Branch Integration with Azure Public Cloud Revision History | 4

 1 Overview
This Tech Note describes how to integrate a Private Cloud infrastructure hosted in Azure into an Aruba SD-WAN.
In order to do so, the SD-WAN solution makes use of the Aruba Virtual Gateway (vGW), which will serve as entry-
point into the Virtual Network (VNET) environments a given customer may have in Azure.

Before we go into the details about how the Aruba vGW is deployed and operated, we need to set a basic
understanding about the different modes of operation within Azure.

1.1 vGW in Public Cloud Infrastructure

Aruba Branch Gateways support standard IPsec tunnels, and can therefore establish direct communication with
the Azure VPN Gateway. So, why would an Aruba Virtual Gateway be needed to integrate with Azure?

The Azure VPN Gateway doesn’t support certain SD-WAN capabilities of an Aruba VPN Concentrator (or vGW, in
the case of public cloud infrastructure). The most critical would be:

• Reverse Path Pinning, which ensures that traffic always returns through the same path of
origin that it came from, allows for branch gateways (BGWs) to perform Uplink load-
balancing and Dynamic Path Steering (DPS).
• Forward Error Correction, which can ruggedize critical edge-to-cloud communication flows
by selectively inserting parity packets in the communication flow.
• Orchestrated Tunnels, which automates the establishment of IPsec tunnels from all BGWs
to all relevant VPN Concentrators (including the vGW).
• Orchestrated Routing, which automates the exchange of routes across the SD-WAN.
• End-to-End visibility of the SD-WAN network under a single application (Aruba Central).

In summary, the use of the vGW to connect the SD-WAN environment to the public cloud environment is
highly encouraged, as it truly brings the public cloud environment into the SD-WAN network as if it were
another Data Center.

Aruba SD-Branch Integration with Azure Public Cloud Overview | 5

 Figure 1: Role of vGW

1.2 Virtual Gateway Orchestrator

The public cloud environment is, for many companies, a “foreign” element to their network, where services are
brought up relying on tools provided by the cloud provider that are not necessarily similar to those in the DC. For
that reason, something more advanced than a simple VM offered through the Azure marketplace is certainly
desirable.

The Aruba SD-Branch solution can make use use of a software-as-a-service (SaaS) component of Aruba Central to
handle the full life cycle of the vGW (manual bringup is also supported). This Technical Note describes the solution
using the orchestrated workflow, as it’s generally the preferred mechanism.

Aruba SD-Branch Integration with Azure Public Cloud Overview | 6

 Figure 2: vGW Orchestrator functions

As highlighted in the image above, Aruba Central handles the whole lifecycle of the vGW, from the initial bring up
and provisioning, through the regular management (as if it were another VPN Concentrator in the network) and to
even handle failover in High Availability (HA) scenarios.

In order to do so, it connects with the Customer Azure account to have visibility over it and provision the VM,
together with the necessary interfaces, subnets, public IP mappings, etc. The functions of the vGW Orchestrator
and the configurations required are covered in detail through this document.

Aruba SD-Branch Integration with Azure Public Cloud Overview | 7

 1.3 Azure Connectivity Modes
From the perspective of the SD-WAN network, Azure deployments can be differentiated between those where
each Virtual Network (VNET) would be treated as a separate node of the SD-WAN (this generally happens when
there is one or just a few VNETs), and those where there are multiple VNETs accessible through a single SD-WAN
node (generally happens when there are multiple VNETs).

Figure 3 - Azure deployment models

In the single-VNET deployment mode,, workloads would be distributed across different subnets, all belonging to
the same VNET. The Aruba Virtual Gateway(s) would be placed in that same VNET and serve as the exit point
towards the rest of the corporate network (branches, DCs, etc). In a certain way, the Aruba vGW behaves as the
“WAN router” for the VNET.

In contrast to that, when working in a multi-VNET environment, workloads are distributed across multiple VNETs
and are connected between them by attaching the VNETs to the Azure Virtual WAN (vWAN). In this scenario, the
Aruba vGWs are placed in a dedicated “Edge-VNET” from which they connect to the vWAN to establish
connectivity with the SD-WAN network.

This document will cover the deployment of an Aruba SD-Branch network integrating to single VNET
environments as well as to an Azure environment with multiple VNETs.

Aruba SD-Branch Integration with Azure Public Cloud Overview | 8

 2 Single VNET deployment
As explained above, there are scenarios where all workloads are in the same or a few VNETs. In such
environments, the Aruba vGW should reside in the same VNET as the workloads, effectively becoming the
connection point between the VNET and the rest of the network.

2.1 Single VNET Architecture Overview

2.1.1 Connectivity into the VNET
For an SD-WAN environment where the Branch Gateways are connected to the Azure environment through one
or multiple Internet circuits, or a combination of Internet and circuits with an MPLS with Azure ExpressRoute, the
deployment would look more or less like the illustration below:

Figure 4: SD-Branch with multiple INET circuits Figure 5: SD-Branch with combination of MPLS and
INET

From the perspective of the SD-WAN (and the SD-Branch vGW), the only difference between these two models
(Internet only or combination of MPLS and Internet) is the fact that tunnels would be just going through the
Internet, or through the Internet as well as the Azure ExpressRoute interface.

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 9
 2.1.2 Routing inside an Azure VNET
In a single Azure VNET environment, the only routing mechanism is to apply routing tables to the subnets in the
VNET (source: Azure). These routing tables have a maximum size of 400 entries (source: Azure), which means
that learning all routes from the SD-WAN would not generally be a viable option. In order to connect this
environment to the SD-WAN and other resources, the vGW will act as the gateway for all traffic coming in and out
the VNET.

The vGW Orchestrator facillitates this connectivity by creating 8 /27 subnets to connect the vGW(s) with other
resources in the VNET. The result will be:

• Internal VNET subnets will point to the vGW for all traffic in/out of the VNET.
• The vGW should have routes pointing traffic destined to corporate subnets through the
Virtual Network Gateway (if used). One way to simplify this is to use larger subnets to those
learned from the SD-WAN to ensure that traffic always picks the shortest path (as with any
other router, the vGW will use the more specific routes).
• The vGW’s default gateway will be via Internet.

The resulting network diagram would be something like this:

Figure 6: Routing Inside a single VNET

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 10
 2.1.3 High Availability in Single VNET environment
As mentioned before, the native routing mechanism available inside a VNET are static routes applied to the
subnets where the workloads are connected. That, coupled with the fact that Azure doesn’t support broadcast or
multicast inside the VNET (source: Azure) makes High Availability (HA) quite challenging. Thankfully, the Aruba
Virtual Gateway Orchestrator can take care of providing high availability in such an environment.

The HA solution for Aruba vGW works in an Active-Passive paired configuration. In this setup, there can be only
one active Virtual Gateway that can forward data in and out of the Virtual network (VNET) subnets. The Virtual
Gateway Orchestrator application decides which of the virtual gateways becomes Active or Passive and
communicates this decision to all the pivotal components. The decision of setting the Active or Passive virtual
gateway is based on the following requirements:

• Virtual machine health of each of the vGWs in a given HA-pair.

• The health of the vGW gRPC control connectivity to the SD-Branch Orchestrator.
• The connectivity of each of the vGWs to all the BGWs.

The vGW Orchestration app decides the status based on the state of each virtual gateway. The application runs a
poll every 20 seconds on each vGW for these criteria:

• VM Health: The VM health status is obtained from the Resource health (Azure) for each of
the gateways in all the VNETs across each of the regions of a given Azure cloud account.
• Control Health: The control health status is provided by the SD-Branch Orchestrator.
• Data and Tunnel Health: The data and tunnel health status is provided by the SD-Branch
Orchestrator module.

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 11
 2.1.3.1 Failover of subnet routes

Once the vGW Orchestrator has brought up the vGWs in the VNET (ideally in multiple availability zones – AZ), the
VNET subnets will be pointing to the Active vGW:

Figure 7: vGW HA - Initial Status

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 12
 In the event of a failover (which can be caused by any of the reasons mentioned above), the vGW Orchestrator
automatically modifies the routing table attached to the subnets to start pointing them towards the other vGW,
which will now be the active vGW.

Figure 8: vGW HA - Failover

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 13
 2.1.3.2 SD-WAN failover

As mentioned above, the SD-Branch Orchestrator can trigger a failover when a partial outage is detected in the
active vGW. In such an environment, the SD-Branch Orchestrator would work in conjunction with the vGW
Orchestrator to steer all traffic to the new active vGW.

Figure 9: vGW Failover – SD-Branch Routing

When the SD-Branch Orchestrator detects a problem with the Active vGW it not only changes the VNETs routing
tables to point to the backup vGW, but it also marks the routes to the primary vGW as “Passive” to avoid sending
traffic through it.

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 14
 2.2 Configuration for Single VNET Deployments
2.2.1 Basic Azure Setup
Even though the vGW would generally be set up in an existing VNET, knowing how to do at least a basic setup will
be necessary to have a good understanding about the overall solution.

The following are pre-requisites needed by the vGW Orchestration service:

• A VNET must exist, as it serves as a starting point for the vGW orchestrator application.
• The Orchestration engine will split it into 8 /27 subnets and consume them to connect the
vGW to different resources in the VNET. This means that the VNET must have a /24 subnet
available for vGW orchestration that will be automatically picked as part of the
orchestration process.
• (Optional) Virtual Network Gateway, in case the VNET is connected to the rest of the
corporate network either via RouteExpress or a manual IPsec tunnel. In Azure, a VNET is
routed by default to Internet.
• A Security group to place the vGW into (the default group can be used, but it’s not advised).
Ensure that you allow inbound and outbound UDP 4500 for the IPsec tunnels to come up.
• An SSH Key Pair to allow an out-of-band connection into the vGW before it’s managed by
Aruba Central.
• A Storage Account which contains the SD-Branch OS image.

And the following would usually be in place (but aren’t mandatory):

• Subnets (with VMs connected to them).

Step-to-step guidance on how to set up the Azure Basic Setup can be found in the Appendix 1 of this
NOTE
document.

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 15
 2.2.2 Subscribe to Aruba vGW in Azure Marketplace
Aruba vGWs are offered in the Azure marketplace following the “Bring Your Own License” model. In this format,
customers “subscribe” to the AMI in the Azure Marketplace (assuming the AMI’s running cost), but purchase
subscriptions from Aruba. The process is therefore the following:

• Customer purchases subscription from Aruba (90-day evals are also available).
• Customer searches for the Aruba vGW in the Azure Marketplace (or use this direct link).
• Customer generates API token for Aruba Central and orchestrates the vGW(s), as explained
below.
• Customer takes care of Azure cost to run the vGW instance.

Figure 10 - Subscribe to Azure vGW

Virtual Gateway subscriptions aren't generated when the account is created (as with other Central
NOTE subscriptions). The Virtual Gateway app takes care of generating eval subscriptions when a vGW is
requested for the first time, regardless of whether managed mode or unmanaged mode is in use.

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 16
 Figure 11 - Aruba Virtual Gateway (SD-Branch) in Marketplace

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 17
 2.2.3 Virtual Gateway Orchestration
As mentioned in the earlier sections, Aruba’s SD-Branch solution handles the whole lifecycle of a virtual gateway.
This will not just matter for the provisioning phase, but it will also be critical to provide high availability in single
VNET environments, where traditional L2 mechanisms such as VRRP won’t work (source: Azure).

For the orchestrated workflow, Central uses the Azure application for API access via Azure Service Management.

2.2.3.1 Create Storage Account (Optional step)

A storage account contains all of your Azure Storage data objects: files, disks, etc. The storage account provides a
unique namespace for your Azure Storage data that is accessible from anywhere in the world over HTTP or HTTPS.
For Aruba Virtual Gateway deployments, you will need a storage account to store the software image and also a
separate storage account for Boot Diagnostics. The Boot Diagnostics option allows you to view logs pertaining
to VM boot issues.

NOTE Skip this section if Azure Marketplace is used.

1. In the Azure portal menu, in the list of resources, type Storage Accounts. As you begin typing, the list filters
based on your input. Select Storage Accounts.

Figure 12: Storage Account

2. On the Storage Accounts window, choose Create.

Figure 13: Add Storage Account

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 18
 3. Enter, or select, the following information, and then select Review and then Create:
• Subscription: Select your Azure subscription.
• Select your existing Resource group.
• Name.
• Select your Azure Region.
• Set Redundancy to Locally-redundant storage (LRS).

Figure 14: Create Storage Account

4. After the deployment is completed and the storage account is created, select Go to resource.

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 19
 Figure 15: Go to Storage Account Settings

5. We will use the Containers available under Storage Account to upload the SD-Branch OS image.

Figure 16: Containers

6. Create a Container that will be used for SD-Branch OS image.

Figure 17: Container

7. Select the new created container and upload the SD-Branch OS image. The image can be downloaded from
https://asp.arubanetworks.com/ website. It is recommended to use the most recent OS image available.

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 20
 Figure 18: Created Container

Figure 19: Upload the SD-Branch OS image

2.2.3.2 Create Azure Application

1. From the Azure portal, select App registrations.

Figure 20: App registrations

2. Select New registration.

Figure 21: New registration

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 21
 3. Name the application and select a supported account type, which determines who can use the application.
After setting the values, select Register.

Figure 22: Register an application

4. After the application is created, the corresponding Tenant ID and Application ID will be used to add the
Azure application in the Central Orchestration app. Save the values.

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 22
 Figure 23: App Details

5. Next, you need to create a new application secret. Select Certificates & secrets. Provide a description of
the secret, and a duration. When done, select Add.

Figure 24: Create secret

6. ATTENTION! After saving the client secret, the value of the client secret is displayed. Copy this value
because you won’t be able to retrieve the key afterwards. You will need to enter the key value and
application ID in the vGW Orchestration app in Central.

Figure 25: Secret Key

7. You'll need to add additional permissions under API permissions. Choose Add a permission, and under
Microsoft APIs, select Azure Service Management.

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 23
 Figure 26: Add Permissions

8. Add the user impersonation permission. This will allow Central’s vGW Orchestration application to access
the Azure Management Service API.

Figure 27: Add Permission

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 24
 9. Access control (IAM) is the blade that you use to assign roles to grant access to Azure resources. Go to
Azure home and select Subscription. Go to your subscription details and select Access control (IAM).

Figure 28: Access Control (IAM)

10. Click Add > Add role assignment. The Add role assignment pane opens.
• In the Role drop-down list, select Contributor role.
• In the Select list, select the previous created application.
• Click Save to assign the role.

Figure 29: Add Role

11. After a few moments, it is assigned the role at the selected scope. From Role assignments can be seen the
recently added role.

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 25
 Figure 30 - Role

2.2.3.3 Virtual Gateway Orchestration

The Azure application can now be used to give Aruba Central access to the Azure account. This will allow the
Orchestration application to read the state of the VNETs and create/monitor/fail-over/delete the vGWs.

1. In Aruba Central, go to Network Services > Virtual Gateway > Configuration > Accounts > Azure > Add
Account.

Figure 31: Add Azure Account

2. Paste the Account name (which can be any administrative name we provide) as well as the Azure IDs
obtained from Azure app and Azure subscription. Please review the previous step “Create Azure
Application” from where we can retrieve Directory (tenant) ID, Application (client) ID and Secret key.

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 26
 Figure 32: Add Azure Account
Your Azure Subscription ID can be obtained by going to Subscriptions.

Figure 33: Subscription ID

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 27
 This will trigger the Orchestration application to connect to the Azure account. It should go to INIT status first
and, after a few seconds, to ACCESS VERIFIED status.

Figure 34: Azure Account Verification

As soon as the account is in ACCESS VERIFIED status, go to Deployment. The Orchestration application will
automatically display the VNETs in our account as well as the subnets belonging to the different VNETs. If you
make changes to your Azure setup, you can force the vGW Orchestration application to refresh the information by
clicking “IMPORT VNETS” in the top right.

Figure 35: vGW Deployment

3. It will also give us the option to spin up a vGW (or vGW pair in HA) in our VNET. Once there, simply provide
Virtual Gateway size, Azure Instance type, SSH Public Key (Check Appendix for details how to generate it)
and Security group and click Deploy Virtual Gateway. The deployment will take 2-3 minutes, during which
the Orchestration application will display a message saying DEPLOYING VIRTUAL GATEWAY and a
progress bar.

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 28
 Figure 36: Create vGW

4. Once the deployment has finished, the message will change to “VIRTUAL GATEWAY DEPLOYED”. Hovering
over the message displays the serial number(s) of the Virtual Gateway(s) that have been deployed.

Figure 37: vGW Deployment Finished

5. To monitor the status of the VMs, go to the List tab. Once again, hovering over the different values in the
table provides additional information.

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 29
 Figure 38: Virtual Gateways Summary

The vGW will need a few minutes to boot, but since all the configuration for Aruba Gateways comes from Aruba
Central, it’s advisable to start configuring it right away.

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 30
 2.2.4 vGW Initial Configuration in Aruba Central
Now that the vGW AMI has been orchestrated, the vGWs can be configured like any other VPN Concentrator. The
following steps will therefore resemble those that we would follow with an on-premises VPN Concentrator.

2.2.4.1 Initial vGW Group Setup

All devices > Organization > Network Structure > Groups. If not already available, create a new group for the
vGWs. For the orchestrated HA mechanism to work, we should have a dedicated group per VNET. Please note that
the group password will be the default user admin password for all the gateways in this group.

A few other details to keep in mind are that we should have a single group per pair of vGWs for orchestrated HA
to work and that this TechNote describes the configuration done using the GUI. Therefore, create the vGW group
as a GUI group for Gateway and set the group type to VPNC:

Figure 39: Group Creation

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 31
 Figure 40 - Group Type

Go to Global > Organization > Network Structure > Groups and move the vGW to the newly created
“Virtual Gateway” group.

Figure 41: Move vGW to Group

2.2.4.2 vGW Initial Configuration

The orchestrated nature of the vGW will mean that the virtual gateway group will have slightly different
characteristics that the ones we’d normally see in a VPNC group. Ports and VLANs will be automatically set by the
VGW orchestration engine, and some system-wide parameters such as the System-IP work better when
automated.

2.2.4.2.1 Basic System Settings

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 32
 As mentioned before, the System-IP is a critical configuration element for each Aruba Gateway operating as a
VPNC or BGW. Each Aruba Gateway uses one VLAN interface as its System-IP. By default, this interface is used by
the Aruba Gateway to communicate with network services such as RADIUS, Syslog, TACACS+, SNMP, DNS or NTP.

Given the dynamic nature of the vGWs, it’s recommended to set their System-IP with the mechanism used for
BGWs:

• Create Gateway Pool from your VPNC group from Devices > Gateway > Configuration >
Interfaces > Pool Management > Gateway Pool.
• Create the System-IP VLAN from Interfaces > VLANs and assign Gateway Pool to the VLAN:
▪ Enable Routing: checked ✓
▪ IP Assignment: Gateway Pool
▪ VLAN Pool: System-IP-pool
▪ Force operational status UP: checked ✓
• Set System-IP VLAN from System > System IP Address.

Aruba Central does not push any configuration to a gateway until the System IP is present, which
NOTE means that, once you set the System IP, Aruba Central will push all pending configurations and trigger
a reboot.

Other recommended settings that can be done at the group level are:

• Disable Spanning Tree – as there’s no need for it inside an Azure VNET.

• The vGW will learn the Azure DNS server as part of the orchestration (which is learned via
VM agent 168.63.129.16). To use a different one, set it manually.
• Set an NTP Server (for example pool.ntp.org).

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 33
 2.2.5 Virtual Gateway Routing Configuration
When using the Virtual Gateway Orchestration in Aruba Central, vGW interfaces will be automatically set with an IP
address. In the case of the INET port/VLAN, even the default-gateway will be learned. The vGW Orchestration
application will create /27 subnets to connect to the Internet, the VPN GW and the VNET LAN. These subnets will
be associated with the following Ports/VLANs.

Azure Interface vGW VLAN vGW Port Connects to

aruba-vgw-<n>-eth1 4094 GE 0/0/0 Internet

aruba-vgw-<n>-eth2 4093 GE 0/0/1 ExpressRoute (VPN GW)

aruba-vgw-<n>-eth3 4092 GE 0/0/2 VNET Subnets (not yet

connected)

NOTE n will be 0 for the “active” vGW and 1 for the “passive” vGW when setting up redundant vGWs.

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 34
 Figure 42: vGW Subnets

At this point, the Azure subnets still don’t have a route to the vGW. This step is achieved by clicking
NOTE
Connect in the vGW Orchestration page and should be done after vGW is configured.

2.2.5.1 VPNC Network Configuration (device-specific)

Even though most of the configuration is done by the vGW Orchestration app, it is still necessary to add routes
pointing to the VNET as well as to the Azure VPN GW to ensure the traffic gets routed properly. This can be done

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 35
 through the device-specific configurations of each vGW by going to Devices > Gateways > <Select vGW> >
Configuration > Routing > IP Routes.

Considering the vGW Orchestrator has used the A.B.C.0/24 subnet to provision the different interconnect /27
subnets, the Azure “gateway” IPs will be an IP address from the coresponding subnet (example shown here).

Azure INTERNET VPN GW LAN GW

Interface (VLAN 4094) (VLAN 4093) (VLAN 4092)

Active vGW A.B.C.33 (learnt via DHCP) A.B.C.65 A.B.C.97

Passive vGW A.B.C.161 (learnt via A.B.C.193 A.B.C.225

DHCP)

This can also be checked (once the vGW has come UP), through the monitoring pages in Aruba Central, from
Devices > Gateways > <Select vGW> > LAN.

Figure 43: IPs Learned from Azure

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 36
 2.2.6 Connect Virtual Gateway to VNET Subnets
Once it’s verified that the vGW is UP and operational, it’s finally advisable to start routing traffic through it. To do
so, go to the Orchestration app and click Connect in the subnets that need to be routed through the vGW from
the Deployment tab of the vGW Orchestration app. Go to Network Services > Virtual Gateways >
Configuration > Deployment.

Figure 44: Connect Subnet to vGW

It’s important to keep in mind that this routing table will replace whatever was previously attached
CAUTION!
to the subnet’s routing table. Ensure that your vGW has the ability to reach all destinations!

Make sure that the network security group associated, both inbound and outbound rules, is
Note allowing the traffic initiated from instances located in Azure subnets. More details on Azure
network security groups can be found here.

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 37
 After this change, the topology of the Azure VNET would look more or less like this (simplified view):

Figure 45: Azure topology - Single VNET

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 38
 2.3 Expected Result
2.3.1 vGW Configuration Verification
Once the vGW is up and configured, the Aruba Central monitoring dashboards display details of the state of the
Virtual Gateways. To view a summary of the device status, click Overview. To view the subnet information, click
WAN and LAN tabs, from Devices > Gateways > <Select vGW> > Overview.

Figure 46: vGW Monitoring Information

To check the real-time routing information, go to Routing > Route Table.

Figure 47: vGW Routing information

Lastly, and as it happens with the BGWs, more advanced actions like rebooting the device or launching a CLI
session into the vGW can be triggered from the Actions dropdown, and troubleshooting workflows can be
accessed through the Open Tools button.

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 39
 2.3.2 Azure Routing Configuration
Clicking Connect in the vGW Orchestrator workflow triggers a route being attached to the subnet in Azure
pointing all non-VNET traffic through the vGW. This can be further validated in the Azure portal by going to your
Virtual network > Subnets. Select the connected subnet and check the routing table attached.

Figure 48: Subnet

Figure 49: Subnet Route Table

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 40
 To check route table content, go to your Resource group and select the corresponding route table from the list
of resources. Select the route table. The next-hop for all non-VNET traffic will point to the vGW LAN IP address.

Figure 50: Route Table under Resource Group

Figure 51: Route Table

Aruba SD-Branch Integration with Azure Public Cloud Single VNET deployment | 41
 3 Multi-VNET Deployments
As explained above, there are also scenarios where workloads are distributed across multiple VNETs. In these
cases, the Azure Virtual WAN (vWAN) is often used to handle the connectivity between VNETs. More about the
vWAN can be found in this link.

3.1 Multi VNET Architecture Overview

3.1.1 Connectivity into the Cloud Environment

When bringing SD-WAN into an Azure environment with multiple VNETs, Aruba recommends setting up an “Edge
VNET” to act as the gateway between the cloud IaaS (Infrastructure as a service) and the SD-WAN. Aruba vGWs
deployed in the “Edge VNET” would peer directly with the Azure Virtual WAN.

Figure 52 - Overview Architecture with Multiple VNETs

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 42

 The mechanism supported by Azure to exchange routes with the vWAN is to set up IPsec connections between
the vGWs and the Virtual HUB (vHUB) and to run eBGP inside the tunnels. That allows the dynamic exchange of
routes between the SD-WAN and the Azure environment.

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 43

 3.1.2 Routing between Azure vWAN and Aruba vGW
The communication between the Azure vWAN and the Aruba vGWs, and ultimately the SD-WAN network, is
established by bringing up redundant IPsec tunnels between the Azure vHUB and the Aruba vGWs. Once the
tunnels are up, eBGP sessions should be established to exchange prefixes between the cloud environment and the
SD-WAN environment.

Figure 53 - Peering between vGW(s) and vWAN

It is recommended to enable BGP multipath in the Aruba vGWs. When both BGP peers have BGP multipath
enabled, traffic is load-balanced across all equal cost paths. BGP paths with the same BGP path selection attributes
(Local preference, AS Path, Origin code, MED, IGP metric) qualify for multipath next-hops. Aruba vGWs support a
maximum of 16 equal cost paths.

When connecting to to an Azure Virtual HUB, the maximum BW per VPN connection can be up to 10 Gbps
(source: Azure). To maximise the bandwidth available between the vGW and the vWAN, make sure BGP MultiPath
is enabled in the Aruba vGW(s).

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 44

 3.1.3 High Availability in Multi-VNET Environment
In the same way as it happens for the single VNET environment, the vGW Orchestrator, together with the SD-
Branch Orchestrator, will take an active role in the redundancy process. The redundancy solution works by pairing
Primary-Secondary vGWs and having the SD-Branch Orchestrator app prefer routing traffic through the Primary
vGW.

However, as opposed to what happens in a single VNET environment, when peering with the Azure vWAN, the
SD-Branch vGWs use BGP to exchange routing information as well as to handle failover. This means that, in order
to keep a symmetric communication flow, the Secondary vGW should be configured to advertise routes that look
less preffered to the Azure vHUB.

The Azure recommendation is to use AS_PATH to influence the routing decisions of the vHUB (source: Azure).
Advertising a longer AS_PATH from the Secondary vGW will influence the vHUB to choose as best path the one
advertised by the Primary vGW, as it has a shorter “AS_PATH”.

The recommendation is, therefore, to prepend its AS number on the Secondary vGW in the AS-PATH when SD-
WAN prefixes are advertised to the vWAN.

Figure 54 - Multi VNET Routing Failover

3.1.4 Route Summarization

It’s generally recommended to summarize routes when operating in medium to large SD-WAN environments to
avoid saturating the routing tables of the smaller gateways. In the case of the integration with the Azure vHUB,
this recommendation can almost be considered a mandate, as the Azure vHUB can learn a maximum of 200
prefixes per BGP session (source: Azure).

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 45

 3.2 Configuration for Multiple VNETs
As mentioned above, an Edge VNET (also referred to as “transit VNET”) would have to be created to place the
vGWs. The same steps described in the section about the Basic Azure Setup can be followed to create such VNET.
Once the Edge VNET is ready, the orchestration of the vGWs can be done exactly as described in the section about
the Virtual Gateway Orchestration. Finally, the initial configuration of the vGWs, would be done as described in the
section about vGW Initial Configuration in Central.

One new element will be introduced in this workflow to automate the integration between Azure vWANs and
Aruba vGWs, Cloud Connect.

3.2.1 Aruba Cloud Connect

Aruba Central provides a unified framework to manage all integrations with cloud infrastructure or security
services: Cloud Connect. This service allows automating connectivity by making use of partner APIs to define
sites/locations, finding the nearest point of presence, and automatically establish IPsec tunnels. Furthermore, it
can also help provide advanced capabilities such as defining 3rd party options or establishing routing
neighborhoods.

Figure 55 - Aruba Cloud Connect

In this case, the Cloud Connect service will be used to automate the communication between Aruba vGWs and
Azure vWAN.

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 46

 3.2.2 Aruba vGW Orchestration for Multi-VPC
As in the case of Single VPC Deployments, Aruba Central can handle the entire life cycle of the Aruba vGW, from
the instantiation of the Aruba VGW to connect with all the relevant parts of the Azure VNET where it is located. In
the case of multi-VPC deployments the following steps would apply.

For the vGWs to be orchestrated in the Edge VNET, the same Azure application described in the Single VNET
section would be needed. Go to Virtual Gateway Orchestration for full details.

The vGWs will generally be deployed in a dedicated “Edge VNET”, as described above. Choose this option to
enable Edge VNET under deployment screen. When Edge VNET is enabled, the Virtual Gateways are deployed in
an Active-Active high availability mode and Multi-Availability Zone option is enabled by default.

Figure 56 - Edge VNET Option

The Edge VNET would have the same requirements described in the section about Single VNET Deployments,
under Basic Azure Setup. Detailed instructions on how to create an Azure VNET can be found in the Appendix of
this document, in the VNET Creation section.

Lastly, the vGW can be orchestrated from Aruba Central by deploying it in the Edge VNET. The same process
described under Error! Reference source not found. can be followed.

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 47

 3.2.3 Virtual WAN Setup and Integration
In multi-VNET scenarios, the vWAN will most likely be present at the moment of the SD-WAN integration.
Nevertheless, it’s important to understand the mechanisms involved, as well as the steps to make it happen.

3.2.3.1 Create the vWAN

1. In the Azure portal menu, in the list of resources, type Virtual WAN. As you begin typing, the list filters
based on your input. Select Virtual WAN.
2. On the Virtual WAN page, click Create to open the Create WAN page.

Figure 57 – Add Virtual WAN

3. On the Create WAN page, on the Basics tab, enter or select the following information, and then
select Review + Create and then Create:
• Subscription: Select your Azure subscription.
• Select your existing Resource group.
• Select your Azure Region.
• Name.
• Type set as Standard (as we will need to create a hub).

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 48

 Figure 58 – Create Virtual WAN

3.2.3.2 Create the vHUB

A hub is a virtual network that can contain gateways for site-to-site or ExpressRoute functionality.

1. In the Azure portal menu, in the list of resources, type Virtual WAN. Locate the Virtual WAN that you
created. On the Virtual WAN page, under the Connectivity section, select Hubs.

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 49

 Figure 59 – vWAN Hubs

2. On the Hubs page, select +New Hub to open the Create virtual hub page.
3. On the Create Virtual HUB page, on the Basics tab, enter or select the following information. It will take 30
minutes to create the virtual hub.
• Select your Azure Region.
• Name.
• Hub private address space. The minimum address space is /24 to create a hub, which implies
anything range from /25 to /32 will produce an error during creation.

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 50

 Figure 60 – Create virtual hub

4. Next select Next: Site-to-site. On the Site-to-site tab, complete the following fields:
• Select Yes to create a Site-to-site VPN.
• The AS Number field is not editable in the virtual hub at this time.
• Select the Gateway scale unit value from the dropdown. The scale unit lets you pick the
aggregate throughput of the VPN gateway being created in the virtual hub to connect sites to. If
you pick 1 scale unit = 500 Mbps, it implies that two instances for redundancy will be created,
each having a maximum throughput of 500 Mbps.

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 51

 Figure 61 – Create Site to Site VPN Gateway

5. Select Review + Create to validate. Select Create to create the hub. It will take 30 minutes to create the
virtual hub.

3.2.3.3 Connect the VNETs to vHUB

In this step, you create the connections between your hub and a VNET. Repeat these steps for each VNET that you
want to connect.

1. On the portal page for your virtual WAN, click Virtual network connections. On the virtual network
connection page, click +Add connection.
2. On the Add connection page, fill in the following fields and after click OK to create the virtual network
connection:
• Connection name. Name your connection.
• Hubs. Select the hub you want to associate with this connection.
• Subscription.
• Virtual network. Select the virtual network you want to connect to this hub.

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 52

 Figure 62 – Add a VNET connection

Figure 63 – VNET connections

3.2.3.4 Create Storage Account

A storage account contains all of your Azure Storage data objects: files, disks, etc. The storage account provides a
unique namespace for your Azure Storage data that is accessible from anywhere in the world over HTTP or HTTPS.
For Aruba Virtual Gateway deployments, you will need a storage account to store the software image and also a
separate storage account for Boot Diagnostics. The Boot Diagnostics option allows you to view logs pertaining
to VM boot issues.

1. In the Azure portal menu, in the list of resources, type Storage Accounts. As you begin typing, the list filters
based on your input. Select Storage Accounts.

Figure 64: Storage Account

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 53

 2. On the Storage Accounts window, choose Create.

Figure 65: Add Storage Account

3. Enter, or select, the following information, and then select Review and then Create:
• Subscription: Select your Azure subscription.
• Select your existing Resource group.
• Name.
• Select your Azure Region.
• Set Redundancy to Locally-redundant storage (LRS).

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 54

 Figure 66: Create Storage Account

3. After the deployment is completed and the storage account is created, select Go to resource.

Figure 67: Go to Storage Account Settings

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 55

 4. Cloud Connect use the Containers available under Storage Account. Create a Container that will be used for
Cloud Connect orchestration.

Figure 68: Containers

Figure 69: Container

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 56

 3.2.4 Aruba vGW Configuration
The information downloaded from Azure will then be used to configure the vGWs.

3.2.4.1 Configure vGW WAN uplink

Configure the uplinks and assign a label to them on the Gateway Management > WAN > Uplink page on
both vGWs at the device level. Public IP of each vGW needs to be configured for each WAN uplink. Public IP
address of each vGW can be found under Monitoring > Overview > Summary screen.

Figure 70 – vGW WAN uplink

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 57

 Figure 71 – Public IP address

• The site name should not include the underscore (_) special character.
Note
• The uplink name should not include the special characters hyphen (-) and underscore
(_).

3.2.4.2 Enable SD-Branch Orchestrator

Set the Overlay mode as Orchestrated and Enable Orchestrator at the group level under Gateway
Management > VPN > SD-WAN Overlay, for both vGWs.

Figure 72 – Enable SD-Branch Orchestration

3.2.4.3 Enable BGP routing

Enable BGP and configure a valid Autonomous System (AS) number at device level for each vGWs. BGP can
be enabled at group level. When doing so, please make sure the AS number is unique per datacenter.

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 58

 Figure 73 – Enable BGP

3.2.4.4 Orchestrate connectivity to vWAN through Cloud Connect Service

Go to Manage > Network Services > Cloud Connect, click the Settings icon. The configuration page is
displayed. Select the cloud provider Azure and the newly added Azure account is listed. For more details,
review Virtual Gateway Orchestration from Single VNET section.

Figure 74 – Azure account under Cloud Connect

Click Deployment tab. The Cloud Connect service discovers the Azure vWANs for the account and displays
them under the Deployment tab.

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 59

 Figure 75 – vWAN network under Cloud Connect

Select a Group from Filter groups and map to the vWANs to which we need to connect. Enable the check
box under Connection column.

Figure 76 – Set connection

Click Preview to displays all the groups selected for connecting to Azure vWAN and click Submit.

Figure 77 – Preview configuration

Cloud Connect Orchestration will take care of all the necessary steps between the Aruba vGWs and Azure to
fully orchestrate the connection. The following will be generated and pushed by Cloud Connect
orchestration:

• On the Aruba vGWs

o VLANs and IP address to source the BGP Peerings (Cloud Connect will by default use VLANs
from the 4000-4080 range).
o IPsec tunnel setup. In every device of the connected group, for each uplink, two IPsec
tunnels are formed to have high availability.

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 60

 o BGP peer configuration
o BGP route-map configuration
• On Azure
o VPN Sites configurations

The Deployment Status will display Completed for a successful configuration. For more details hover over
the Deployment Status field.

Figure 78 – Deployment status

3.2.4.5 Advertise SD-Branch routes

Cloud Connect service creates route-maps auto_cloud_connect_in and auto_cloud_connect_out. These

route-maps are editable and have a default permit rule with sequence number 20. It is recommended to
edit these route-maps to filter the routes exchanged with the Azure vWAN.

Figure 79 – Cloud Connect route-maps

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 61

 Figure 80 – Cloud Connect route-maps match any

Make sure to advertise SD-WAN Overlay, connected, static, or OSPF routes to BGP and redistribute BGP prefixes
to SD-WAN Overlay.

Figure 81 - Redistribute SD-WAN to BGP

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 62

 Figure 82 – Redistribute BGP to Overlay

The return traffic from Azure data center should prefer the hub higher in the DC preference. Based on the DC
preference configured on the branches, the SD-Branch Orchestrator will also assign the corresponding cost and
incrementally prepend its AS number when advertising branch prefixes.

For example, the routes advertised to the hub having the highest preference will have an overlay cost of 10, which
translates to a ‘no AS prepended’. A route advertised to a hub having the fourth preference will have an overlay
cost of 40, which is advertised with its own AS number prepended 3 times.

To see the advertised routes attributes sent to the Azure data center from the CLI, run “show ip bgp neighbors
<peer> advertised-routes” commands.

CLI Output:
(Bucuresti-DC1) #show ip bgp neighbors 10.62.250.12 advertised-routes

Status codes: > - Best Path, i - internal

Origin codes: i - IGP, e - EGP, ? - incomplete, m - multipath

BGP Route Path Table

--------------------
Network Next Hop Metric LocPref Path
------- -------- ------ ------- ----
> 10.2.100.12/32 10.2.101.1 0 0 65111 ?
> 10.2.101.0/24 10.2.101.1 0 0 65111 ?
> 10.60.251.32/27 10.2.101.1 0 0 65111 ?
> 10.60.251.64/27 10.2.101.1 0 0 65111 ?
> 10.60.251.96/27 10.2.101.1 0 0 65111 ?
> 190.3.8.200/29 10.2.101.1 0 0 65111 65111 65111 I
> 10.127.24.0/26 10.2.101.1 0 0 65111 65111 65111 i
> 10.127.24.0/27 10.2.101.1 0 0 65111 65111 65111 i
> 5.5.5.1/32 10.2.101.1 0 0 65111 65111 65111 i
> 190.3.8.224/27 10.2.101.1 0 0 65111 65111 65111 i
> 5.5.5.2/32 10.2.101.1 0 0 65111 65111 65111 i
> 190.3.8.208/28 10.2.101.1 0 0 65111 65111 65111 i-→The
route is received from a
branch is which have Bucuresti-DC1 hub set with 4th DC preference.
(Bucuresti-DC1) #

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 63

 3.2.4.6 Route summarization

For most deployments, an additional step would be required; that is, to enable route summarization. This is
necessary to ensure that the BGP routing table in the vHUB is not overflowed by the prefixes advertised by the
SD-Branch.

Route maps allow the configuration of filtering criteria by defining a set of rules or match statements with permit
or deny conditions for the prefixes which we advertise to vWAN. In route summarization scenario, we need to
configure a prefix list to match only the route aggregate and redistribute it via route-map to the vWAN.

Figure 83 - Aggregate BGP advertisements

Figure 84 – Create Prefix-list to Match Route Aggregate

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 64

 Figure 85 – Route-map Matching IP-Prefix List

In the case of aggregation, ensure you include AS-Path Prepending on the VGW having second DC preference to
make less prefered the prefixes advertised to the vWAN. This step is necessary as for route aggregation, AS-Path
attribute is not being retained by the aggregate route, as it is in the case of individual advertised BGP routes which
have their AS-Path attributed dynamically changed by the DC preference value of the corresponding vGW.

Figure 86 – AS-Path Prepend on the Secondary vGW

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 65

 Lastly, the new created route-map has to be added on the outbound direction of the BGP peer with Azure vWAN.

Figure 87 – Advertise Only Permitted Prefixes to vWAN

To verify the advertised routes in the Aruba Central UI, go to All devices > Gateways > List of Online
Gateways > <Select your device> and then click the Overview tab and select Routing > BGP. Detailed
advertised routes are displayed under Send Paths window:

Figure 88 – Only Permitted BGP Routes are Advertised to vWAN

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 66

 Figure 89 – Advertised BGP aggregate routes to vWAN

3.2.4.7 BGP Multipath

As mentioned above (Routing between Azure vWAN and Aruba vGW), BGP multipath should be enabled on
Aruba vGWs when connecting to the Azure vHUB to maximize the bandwith between the SD-WAN and the cloud
environment. Go to Routing > BGP > Advanced to enable BGP Multipath.

Figure 90 – Enable multipath

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 67

 3.3 Expected Result
After the tunnels and routing are configured, both Azure and Central will start reporting that the tunnels are UP
and that the routing information is being exchanged.

3.3.1 Expected Result in Azure Portal

After the tunnels and BGP peerings have been established, the Azure page will start displaying tunnel
status/Connectivity Status as Connected (and the vHUB is learning BGP routes from the vGWs). This can be
monitored from Virtual WAN > HUBs > <Your hub>> VPN (Site to Site) page.

Figure 91 - Azure VPN (Site to site)

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 68

 At the same time, the vHUB routing rable will start being populated with routes coming from the SD-WAN
network. This can be monitored through Virtual WAN > HUBs > <Your hub>> Routing>Effective Routes
page.

Figure 92 - vHUB Routing table

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 69

 3.3.2 Expected Result in Aruba Central
Aruba Central displays the tunnels established between the vGWs and the Azure vHUB. In order to check this, go
to the Gateway Details dashboard and click the Tunnels tab:

Figure 93 - vGW Tunnel status

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 70

 Once the tunnels are UP, the next step would be to check the routing information. This can be viewed in
Routing > BGP or Routing > Route Table.

When debugging BGP issues, ensure that the BGP session with vHUB appears as “Established” in the neighbors
table and that the vGW is receiving prefixes from Azure vWAN:

Figure 94 - BGP Neighbors

Next, verify that the prefixes learnt from the vHUB are learned in the BGP routing table. We can see in the output
of the BGP table that both paths are marked as best as a result of multipath being enabled:

Figure 95 - BGP Routing table

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 71

 And, lastly, double-check that the routes learned from the vWAN are making their way to the routing table:

Figure 96 - vGW Routing table

Aruba SD-Branch Integration with Azure Public Cloud Multi-VNET Deployments | 72

 4 Appendix 1 – Useful Azure Procedures
4.1 Basic Azure Setup
If you’re just getting started, the first step will be to create a VNET. An Azure Virtual Network (VNet) is the
fundamental building block for your private network in Azure. A VNET enables many types of Azure
resources to securely communicate with each other, the Internet, and on-premises networks. VNET is
similar to a traditional network that you'd operate in your own data center (source: Azure).

The steps to set up a VNET are described in the following sections.

4.1.1 Resource Group Creation

A resource group is a container that holds related resources for an Azure solution. Generally, this includes
resources to the same resource group so you can easily deploy, update, and delete them as a group. For example,
this would include manageable items such as VNETs, subnets, route tables, etc.

1. From the Azure portal, select Resource groups.

Figure 97: Resource Groups

2. Select Create.

Aruba SD-Branch Integration with Azure Public Cloud Appendix 1 – Useful Azure Procedures | 73
 Figure 98: Add Resource Group

3. Enter the following values:

• Subscription: Select your Azure subscription.
• Resource group: Enter a new resource group name.
• Region: Select an Azure location, such as Central US.

Figure 99: Create Resource Group

4. Select Review + Create and after validation is passed, select Create. It takes a few seconds to create a
resource group.

Aruba SD-Branch Integration with Azure Public Cloud Appendix 1 – Useful Azure Procedures | 74
 NOTE Open the resource group and press Delete Resource Group if you want to delete the resource group.

4.1.2 VNET Creation

The following steps describe how to manually create a VNET.

1. In the Azure portal, select Virtual network and then select Create.

Figure 100: Select Virtual Networks

2. Under Create virtual network > Basics, enter or select values for the following settings:
• Select a Subscription.
• Select your Resource group.
• Name: The name must be unique in the resource group that you select.
• Select your Azure Region.

Aruba SD-Branch Integration with Azure Public Cloud Appendix 1 – Useful Azure Procedures | 75
 Figure 101: Create virtual network – Basics

3. Under Create virtual network > IP addresses, enter the values for the following settings:
• IPv4 address space.
• Subnet name: The subnet name must be unique within the virtual network.
• Subnet address range: The range must be within the address space you entered for the
virtual network.

Figure 102: Create Virtual Network – IP Addresses

Aruba SD-Branch Integration with Azure Public Cloud Appendix 1 – Useful Azure Procedures | 76
 4. Select Review + Create and after validation is passed, select Create. It takes a few seconds to create a VNET.

Figure 103: Create VNET

Aruba SD-Branch Integration with Azure Public Cloud Appendix 1 – Useful Azure Procedures | 77
 4.1.3 Create a Security Group
The next steps are to be followed to create a Security Group. This is the firewall policy applied to a given Azure
instance. In the case of the vGW, we need to ensure that inbound port UDP 4500 is open to allow tunnels coming
from the Branch Gateways.

5. In the Azure portal menu, in the list of resources, type “Network security group”. Select Create.

Figure 104: Network Security Group

1. Enter, or select, the following information, and then select Review + Create and then Create:
• Subscription: Select your Azure subscription.
• Select your Resource group.
• Name.
• Select your Azure Region.

Aruba SD-Branch Integration with Azure Public Cloud Appendix 1 – Useful Azure Procedures | 78
 Figure 105: Create Security Group

2. Create inbound policies under the new Security group. Make sure you at least allow inbound UDP 4500.
Select Inbound security rules and then select + Add.

Aruba SD-Branch Integration with Azure Public Cloud Appendix 1 – Useful Azure Procedures | 79
 Figure 106: Add Inbound Security Rules

Figure 107: Customized Security Group

Azure creates the 65000, 65001 and 65500 default rules in each network security group that you
NOTE
create.

Aruba SD-Branch Integration with Azure Public Cloud Appendix 1 – Useful Azure Procedures | 80
 4.1.4 Create SSH Key Pair
Another mandatory steps is to create a SSH Key pair. In case anything were to go wrong with the vGW
Orchestration, this key pair can be used to SSH into the vGW. The Azure console provides a private key that will
allow user to SSH into our vGW (the security group policy needs to allow inbound SSH). Make sure you keep it in
a secure location.

1. From your Azure Cloud Shell, use the “ssh-keygen -t rsa -b 2048” command to generate public and private
key files. By default, these files are created in the ~/user directory. The command creates an SSH key pair
using RSA encryption and a bit length of 2048.

Figure 108: Cloud Shell

Figure 109: Key Gen

Aruba SD-Branch Integration with Azure Public Cloud Appendix 1 – Useful Azure Procedures | 81
 2. The Public key can be displayed using “cat” command, using the path and Public key filename which was
created. Save the Public key, it will be used during vGW Orchestration.

Figure 110: Public Key

CAUTION! Ensure that you Copy the full string displayed by Public Key, including “ssh-rsa” and the trail.

Save the Private key to your local machine to be used later to SSH into VGw. Use again “cat”
NOTE
comand to display the Private key (e.g “cat ssh-key”).

4.1.5 (Optional) VPN Gateway

In this step, you create the virtual network gateway for your VNET. Creating a gateway can often take 45 minutes
or more, depending on the selected gateway SKU. The virtual network gateway uses a specific subnet called the
gateway subnet. The gateway subnet is part of the virtual network IP address range that you specify when
configuring your virtual network. It contains the IP addresses that the virtual network gateway resources and
services use. Azure recommends that you create a gateway subnet that uses a /27 or /28.

1. In the Azure portal menu, in the list of resources, type Virtual network gateway. As you begin typing, the
list filters based on your input. Select Virtual network gateway.

Figure 111: Create VPN GW

2. On the Virtual network gateway window, choose Create.

Aruba SD-Branch Integration with Azure Public Cloud Appendix 1 – Useful Azure Procedures | 82
 Figure 112: Create Virtual Network Gateway

3. Enter, or select, the following information, and then select Review + Create and then Create:
• Subscription: Select your Azure subscription.
• Name.
• Select your Azure Region.
• Select the gateway SKU.
• Select your existing Resource group.
• Public IP address name.

Aruba SD-Branch Integration with Azure Public Cloud Appendix 1 – Useful Azure Procedures | 83
 Figure 113: Create VPN GW

Aruba SD-Branch Integration with Azure Public Cloud Appendix 1 – Useful Azure Procedures | 84
 4.2 Setting up a Test Server in Azure
If you have been following the steps described in this Technical Note, the communication with the Azure VNET
should be all set. However, validating operational status using only monitoring dashboards in Aruba Central may
not be sufficient. Here’s a small guide explaining how to bring up a server in Azure to connect to it through the
SD-WAN and test the service end-to-end.

4.2.1 Bringing up a VM in Azure

Bringing up a server in Azure is extremely straigthforward. This procedure includes the following steps:

1. From your Azure portal, type virtual machines in the search and under Services, select Virtual machines.

Figure 114: Virtual Machines

2. This leads to the Virtual machines page. Select Create to create a new VM.

Figure 115: Add Virtual Machine

3. Under Basics enter, or select, the following information:

• Subscription: Select your Azure subscription.
• Select your existing Resource group.
• Virtual machine Name.
• Select your Azure Region.

Aruba SD-Branch Integration with Azure Public Cloud Appendix 1 – Useful Azure Procedures | 85
 • Select the VM Image.
• Administrator account (Username and Password).

Figure 116: Create VM

Aruba SD-Branch Integration with Azure Public Cloud Appendix 1 – Useful Azure Procedures | 86
 Figure 117: Create VM

4. Next, under Networking, enter or select the following information, and then select Review + Create and
then Create:
• Select your existing Virtual network.
• Select your existing subnet where the VM will be deployed.

Aruba SD-Branch Integration with Azure Public Cloud Appendix 1 – Useful Azure Procedures | 87
 4.2.2 Connecting to the Test Server
Now that the test server is up, connect to test server through SSH or RDP from the test branch network. In your
Azure portal, go to Virtual machines > Your VM. Click the Connect button on the overview page for your virtual
machine.

Figure 118: Connect to Test Server

Aruba SD-Branch Integration with Azure Public Cloud Appendix 1 – Useful Azure Procedures | 88
 The console displays a screen explaining how to SSH into the test server.

Figure 119 - Connect using PEM Certificate if SSH is Used

To test the connectivity between a host located in a branch and a test server deployed in Azure,
NOTE please ensure to disable on the VM the firewall enabled on the private profile, if a Windows WM is
used.

Aruba SD-Branch Integration with Azure Public Cloud Appendix 1 – Useful Azure Procedures | 89
 Figure 120 – Disable the firewall on the private domain on the VM

Aruba SD-Branch Integration with Azure Public Cloud Appendix 1 – Useful Azure Procedures | 90
 5 Appendix 2 – Manual connect to Azure vWAN
While the automated mechanism described under Multi-VNET Deployments is generally preferred due to it’s
ease of use, it’s important to also understand how things can be manually configured when required. This section
seeks to cover that deployment mode.

5.1.1 Virtual WAN Setup and Integration

In multi-VNET scenarios, the vWAN will most likely be present at the moment of the SD-WAN integration.
Nevertheless, it’s important to understand the mechanisms involved, as well as the steps to make it happen.

5.1.1.1 Create the vWAN

1. In the Azure portal menu, in the list of resources, type Virtual WAN. As you begin typing, the list filters
based on your input. Select Virtual WAN.
2. On the Virtual WAN page, click Create to open the Create WAN page.

Figure 121 – Add Virtual WAN

3. On the Create WAN page, on the Basics tab, enter or select the following information, and then
select Review + Create and then Create:
• Subscription: Select your Azure subscription.
• Select your existing Resource group.
• Select your Azure Region.
• Name.
• Type set as Standard (as we will need to create a hub).

Aruba SD-Branch Integration with Azure Public Cloud Appendix 2 – Manual connect to Azure vWAN | 91
 Figure 122 – Create Virtual WAN

5.1.1.2 Create the vHUB

A hub is a virtual network that can contain gateways for site-to-site or ExpressRoute functionality.

1. In the Azure portal menu, in the list of resources, type Virtual WAN. Locate the Virtual WAN that you
created. On the Virtual WAN page, under the Connectivity section, select Hubs.

Aruba SD-Branch Integration with Azure Public Cloud Appendix 2 – Manual connect to Azure vWAN | 92
 Figure 123 – vWAN Hubs

2. On the Hubs page, select +New Hub to open the Create virtual hub page.
3. On the Create Virtual HUB page, on the Basics tab, enter or select the following information. It will take 30
minutes to create the virtual hub.
• Select your Azure Region.
• Name.
• Hub private address space. The minimum address space is /24 to create a hub, which implies
anything range from /25 to /32 will produce an error during creation.

Aruba SD-Branch Integration with Azure Public Cloud Appendix 2 – Manual connect to Azure vWAN | 93
 Figure 124 – Create virtual hub

4. Next select Next: Site-to-site. On the Site-to-site tab, complete the following fields:
• Select Yes to create a Site-to-site VPN.
• The AS Number field is not editable in the virtual hub at this time.
• Select the Gateway scale unit value from the dropdown. The scale unit lets you pick the
aggregate throughput of the VPN gateway being created in the virtual hub to connect sites to. If
you pick 1 scale unit = 500 Mbps, it implies that two instances for redundancy will be created,
each having a maximum throughput of 500 Mbps.

Aruba SD-Branch Integration with Azure Public Cloud Appendix 2 – Manual connect to Azure vWAN | 94
 Figure 125 – Create Site to Site VPN Gateway

5. Select Review + Create to validate. Select Create to create the hub. It will take 30 minutes to create the
virtual hub.

5.1.1.3 Create a Site to Site

1. On the portal page for your virtual WAN, in the Connectivity section, select VPN sites to open the VPN sites
page.

Figure 126 – VPN sites

Aruba SD-Branch Integration with Azure Public Cloud Appendix 2 – Manual connect to Azure vWAN | 95
 2. On the VPN sites page, click +Create site.

Figure 127 – Create site

3. On the Create VPN Site page, on the Basics tab, complete the following fields:
• Select your Azure Region.
• Name - The name by which you want to refer the connected site.
• Device vendor - The name of the peer vendor.
• Border Gateway Protocol – Set enable. All connections from the site will be BGP enabled.
• Hubs - The hub that you want your Site to connect to.

Aruba SD-Branch Integration with Azure Public Cloud Appendix 2 – Manual connect to Azure vWAN | 96
 Figure 128 – Create VPN Site

4. Select Links to add information about the link connecting to vGW:

• Link Name.
• Provider Name. The name of the link for the remote site
• Speed. For example, 1000 means 1000 Mbps is the speed of the link.
• IP Address - Public IP address of the vGW using this link.
• BGP address of vGW used to source the BGP peering.
• ASN (AS Number) of the vGW.

You can use the checkbox to delete or add additional links. Four links per VPN Site are supported.

Aruba SD-Branch Integration with Azure Public Cloud Appendix 2 – Manual connect to Azure vWAN | 97
 Figure 129 – Add Link

The public IP address assigned to each vGW as part of the orchestration process can be found under Network
Services/Virtual Gateways Summary:

Figure 130 – vGW Public IP

Once you have finished filling out the fields, select Review + create to verify and create the site. View the status
on the VPN sites page. The site will go to Connectivity Status unknown because the site has not yet been
connected to the vGW at this point.

5. This will result in a set of Site-to-Site IPsec tunnels created. The configuration for vGWs can be downloaded
from VPN sites, Download Site-to-Site VPN configuration. The Aruba vGW is configured by means of a
GUI, so there won’t be a CLI output to copy and paste. Download the json file to gather the necessary
information. Once the json file has finished creating, you can click the link to download it.

Aruba SD-Branch Integration with Azure Public Cloud Appendix 2 – Manual connect to Azure vWAN | 98
 Figure 131 – Download VPN configuration

The configuration downloaded from Azure includes information for the setup of 2 IPsec tunnels (and 2
NOTE
BGP peerings). Don’t miss the configuration for the second IPsec tunnel/BGP peering.

6. To use more easily the data from the json file, use a json formatter tool as for example
https://jsonformatter.org/. We will need the following information:
• IP addresses of the virtual hub. Because each connection is composed of two tunnels in active-
active configuration, you'll see both IP addresses listed in this file listed as "Instance0" and
"Instance1" for each site.
• Azure BGP IP address listed as BgpPeeringAddresses “Instance0" and "Instance1”
• PSK key that was automatically generated.

Aruba SD-Branch Integration with Azure Public Cloud Appendix 2 – Manual connect to Azure vWAN | 99
 Figure 132 – Azure VPN configuration

5.1.1.4 Connect the VNETs to vHUB

In this step, you create the connections between your hub and a VNET. Repeat these steps for each VNET that you
want to connect.

7. On the portal page for your virtual WAN, click Virtual network connections. On the virtual network
connection page, click +Add connection.
8. On the Add connection page, fill in the following fields and after click OK to create the virtual network
connection:
• Connection name. Name your connection.
• Hubs. Select the hub you want to associate with this connection.
• Subscription.
• Virtual network. Select the virtual network you want to connect to this hub.

Aruba SD-Branch Integration with Azure Public Cloud Appendix 2 – Manual connect to Azure vWAN | 100
 Figure 133 – Add a VNET connection

Figure 134 – VNET connections

Aruba SD-Branch Integration with Azure Public Cloud Appendix 2 – Manual connect to Azure vWAN | 101
 5.1.2 Aruba vGW Configuration
The information downloaded from Azure will then be used to configure the vGWs.

5.1.2.1 Create the eBGP peering Interface VLANs

The vGW will need an IP address or a Loopback to establish the BGP peering with the vHUB. The IP address will be
configured on an “always UP” VLAN interface (set force operational status to UP) or on a loopback IP address. The
BGP source IP address was requiered previouly when vHUB was created.

Figure 135 – BGP source interface

5.1.2.2 Set up the IPsec tunnels

The next step would be to create the IPSec tunnels between the vGWs and the vHUB. For this setup, once again,
make use of the information downloaded from Azure.

The following are the recommended parameters for source/destination network:

• Source network/mask: Any

• Destination network/mask: Any

Aruba SD-Branch Integration with Azure Public Cloud Appendix 2 – Manual connect to Azure vWAN | 102
 Figure 136 - IPsec Tunnel Source/Destination

Aruba SD-Branch Integration with Azure Public Cloud Appendix 2 – Manual connect to Azure vWAN | 103
 Where the IKEv2 policy is defined as AES256 – SHA with DH group 2:

Figure 137 – IKEv2 policy

Aruba SD-Branch Integration with Azure Public Cloud Appendix 2 – Manual connect to Azure vWAN | 104
 And transform-set is esp-aes256-sha.

Figure 138 - Set transform-set

For the rest of the tunnel parameters, the following are the recommended parameters:

• Peer Gateway IPv4: Public IP address of vHUB

• VLAN: 4094
• Trusted, Enforce NAT-T, Pre-Connect, Force tunnel
• PFS: Group 2

Aruba SD-Branch Integration with Azure Public Cloud Appendix 2 – Manual connect to Azure vWAN | 105
 Figure 139 - IPsec tunnel parameters

Aruba SD-Branch Integration with Azure Public Cloud Appendix 2 – Manual connect to Azure vWAN | 106
 5.1.2.3 Configure BGP

First, we need to add static routes via the Site-2-Site tunnels, which will point to the Azure BGP peer address. This
configuration will be based on the information downloaded from Azure.

Figure 140 – Azure BGP peer IP addresses

Aruba SD-Branch Integration with Azure Public Cloud Appendix 2 – Manual connect to Azure vWAN | 107
 The last step is to configure the vGWs to establish an eBGP peering between the vGWs and the vHUB to start
exchanging prefixes.

Figure 141 – Enable BGP

Figure 142 – BGP configuration

Aruba SD-Branch Integration with Azure Public Cloud Appendix 2 – Manual connect to Azure vWAN | 108
 Where allowall route-map is matching all prefixes received or advertised by the peer:

Figure 143 - Route-map applied to BGP neighbor

Aruba Gateways follow RFC8212, which mandates that a route-map has to be applied to eBGP
NOTE neighbors or the implicit “deny” will be applied to the route-map. It is therefore needed to apply route
map to eBGP neighbors in order to learn prefixes from them.

The return traffic from Azure data center should prefer the hub higher in the DC preference. Based on the DC
preference configured on the branches, the SD-Branch Orchestrator will also assign the corresponding cost and
incrementally prepend its AS number when advertising branch prefixes.

For example, the routes advertised to the hub having the highest preference will have an overlay cost of 10, which
translates to a no AS prepended. A route advertised to a hub having the fourth preference will have an overlay
cost of 40, which is advertised with its own AS number prepended 3 times.

To see the advertised routes attributes sent to the Azure data center from the CLI, run “show ip bgp neighbours
<peer> advertised-routes”commands.

CLI Output:

(Bucuresti-DC1) #show ip bgp neighbors 10.62.250.12 advertised-routes

Status codes: > - Best Path, i - internal

Origin codes: i - IGP, e - EGP, ? - incomplete, m - multipath

BGP Route Path Table

--------------------
Network Next Hop Metric LocPref Path
------- -------- ------ ------- ----
> 10.2.100.12/32 10.2.101.1 0 0 65111 ?
> 10.2.101.0/24 10.2.101.1 0 0 65111 ?
> 10.60.251.32/27 10.2.101.1 0 0 65111 ?
> 10.60.251.64/27 10.2.101.1 0 0 65111 ?
> 10.60.251.96/27 10.2.101.1 0 0 65111 ?
> 190.3.8.200/29 10.2.101.1 0 0 65111 65111 65111 I
> 10.127.24.0/26 10.2.101.1 0 0 65111 65111 65111 i
> 10.127.24.0/27 10.2.101.1 0 0 65111 65111 65111 i
> 5.5.5.1/32 10.2.101.1 0 0 65111 65111 65111 i

Aruba SD-Branch Integration with Azure Public Cloud Appendix 2 – Manual connect to Azure vWAN | 109
 > 190.3.8.224/27 10.2.101.1 0 0 65111 65111 65111 i
> 5.5.5.2/32 10.2.101.1 0 0 65111 65111 65111 i
> 190.3.8.208/28 10.2.101.1 0 0 65111 65111 65111 i -→The
route is received from a
branch is which have Bucuresti-DC1 hub set with 4th DC preference.
(Bucuresti-DC1) #

Also, make sure to advertise SD-WAN Overlay routes to BGP and redistribute BGP prefixes to SD-WAN Overlay:

Figure 144 - Redistribute SD-WAN to BGP

Figure 145 - Redistribute BGP into SD-WAN Overlay

Aruba SD-Branch Integration with Azure Public Cloud Appendix 2 – Manual connect to Azure vWAN | 110
 6 Reference
Aruba SD-Branch Fundamentals Guide:

• https://community.arubanetworks.com/t5/Validated-Reference-Design/SD-Branch-
Fundamentals-Guide/ta-p/482038

Mid-Size Deployment Guide:

• https://www.arubanetworks.com/assets/tg/AVD_SD-Branch-Midsize-Design.pdf

Aruba SD-Branch Orchestrator Tech Note:

• https://asp.arubanetworks.com/downloads/documents/RmlsZTo3NzRjY2Y1NC1kZjE
xLTExZTktOWUyNy1lMzRhYTIwNDExMzQ%3D

Aruba SD-Branch Online Documentation:

• https://www.arubanetworks.com/techdocs/central/latest/content/sd-
branch/vgw/vgw_azure_overview.htm
• https://www.arubanetworks.com/techdocs/central/latest/content/sd-branch/cfg/overlay-
orchestration/sdwan-oto-oro.htm

Azure links:

• Azure limits: https://docs.microsoft.com/en-us/azure/azure-resource-

manager/management/azure-subscription-service-limits#networking-limits
• Azure documentation: https://docs.microsoft.com/en-us/azure/?product=featured
• Global transit network architectures with Virtual WAN:
https://www.youtube.com/watch?v=iBCy8Vvl7rk

RFCs links:

• Default External BGP Route Propagation Behavior without policies:

https://tools.ietf.org/html/rfc8212
• BGP Multipath: https://tools.ietf.org/html/rfc8212
• BGP Graceful Restart: https://tools.ietf.org/html/rfc4724

Aruba SD-Branch Integration with Azure Public Cloud Reference | 111