Microsoft Azure

Virtual Appliances deployed on Microsoft Azure are subject to the following configuration limitations:

• Azure does not support layer 2 bridging; therefore, the Passthrough Service is not supported in Virtual Appliances deployed on Azure.
• Azure supports one subnet per virtual interface, therefore only one VLAN can be supported on an Interface Group.

Note:

This document describes a basic setup of a Virtual Appliance in the Microsoft Azure cloud, at a single Azure location, within a single VNET. For assistance with deploying more complex Azure configurations, please contact support.

Prerequisites for Microsoft Azure

• Administrative access to your Azure Portal
• Active Azure Subscription & Azure Location
• Active Registration to the following Resource Providers:
  • Microsoft.Network
  • Microsoft.Compute
  • Microsoft.Storage
• Sufficient amount of compute resources available in the Resource Group that you are deploying in (ex. Number of vCPUs available)
• Azure Express Route (if required)

Prerequisites

• A valid license
  • In order to acquire a license, you will first need to spin-up the new appliance so that you can obtain the UUID of the appliance.
  • Once a UUID has been obtained from the appliance, please contact your Account Team who will assist you with procuring a valid license that will need to be applied to the Virtual Appliance before service can be enabled.
• An Appliance Package for the specific site being deployed (available from your NCN's Change Management Page once the configuration containing the new site has been staged

Supported Topologies

There are 3 basic topologies supported for Microsoft Azure:

1. Single WAN Link Using Azure Public IP Address

   Figure 2-15 Sample Topology for Single WAN Link using Azure Public IP Address

   
2. Single WAN Link Using Azure Express Route

   Figure 2-16 Sample Topology for Single WAN Link using Azure Express Route

   
3. Dual WAN Link using Azure Public IP address and Azure Express Route

   Figure 2-17 Sample Topology for Dual WAN Links with Azure Public IP and Azure Express Route

   

Deployment Notes

1. Standard deployment of the Virtual Appliance with a single public WAN Link requires two Public IP Addresses:
   1. One for permanent use by the WAN VIP.
   2. One for permanent or temporary use by the MGT IP:
      1. Permanent Public IP – if you wish to have the MGT accessible via Public IP permanently.
      2. Temporary Public IP – if you wish to temporarily access the Virtual Appliance and then remove the Public IP access once Conduit MGT access has been established.
2. The Azure Virtual Appliance requires dedicated LAN and WAN subnets for Talari use only.
3. Other subnets that exist in your Azure environment can be connected to the LAN subnet via User Defined Routes.
4. If Internet service is required at the Virtual Appliance site, the Configuration must utilize a Dynamic Outbound PAT to the Public IP Address of the Virtual Appliance's WAN VIP.
5. IP forwarding must be enabled on all Azure NICs connected to the Virtual Appliance, with the exception of the MGT NIC.
6. All required NICs must be attached to the Virtual Appliance prior to enabling the service on the virtual appliance.
7. If requirements dictate more complex topologies, please consult with Talari to ensure supportability.

VM Size Requirements

Choose a VM size most appropriate for your deployment scenario and performance requirements. Deploying a virtual machine that does not meet the requirements is not supported. Additionally, this may result in instability and/or suboptimal performance of the Virtual Appliance.

Addressing Guidelines and Planning

Before creating or appropriating Microsoft Azure resources, determine how many IP subnets will be required by reviewing the supported topologies discussed above along with your configuration needs. For standard deployment, define a minimum of:

1. A unique Address Space for the Virtual Network (VNET).
2. At least one Company LAN subnet for company assets contained within that VNET.
3. A unique, LAN subnet contained within that VNET.
4. A WAN subnet contained within the VNET for each WAN Link.
5. LAN & WAN VIPs for the Virtual Appliance, contained within their respective subnets.
6. Optional (for MGT): you may choose to leave your MGT address accessible via Public IP, place it into your already-existing Company LAN Subnet, or create an entirely new MGT Subnet for the Interface. In this example, we will assume that the MGT Interface and MGT IPs will live on the Company LAN Subnet as discussed in the topology overview.

Single WAN Link Example

• VNET Address Space: 10.0.0.0/23
• Existing Company LAN Subnet: 10.0.0.0/24
• LAN Subnet: 10.0.1.0/24
  • LAN Virtual IP (VIP): 10.0.1.11/24
• WAN Subnet: 10.0.2.0/24
  • WAN Virtual IP (VIP): 10.0.2.11/24
• MGT Virtual IP (VIP): 10.0.0.4

Note:

Subnet size prefixes as small as /29 may to be used. Smaller subnets are not permitted by Azure due to the requirements of their reserved IP addresses. The first three addresses in each subnet are reserved by Azure for their internal services and cannot be assigned to the Virtual Appliance.

Create Network Resources

Prior to deploying a Virtual Appliance, you should ensure that you have all the Microsoft Azure resources required by your topology and configuration. If you have already gathered the required resources, please skip ahead to the section below. If you do not have already-existing Microsoft Azure resources that can be used for the Virtual Appliance, the following steps will walk through the process of creating each of the following: Resource Groups, VNET, Subnets, Route Tables, Network Security Groups, Public IPs, and Virtual NICs.

Resource Group

If you are not using an existing Azure Resource Group, you will need to create a new resource group in your chosen region. To create a new resource group, select “Resource Groups” from “All Services” in the Azure Portal Menu, and click “Add.” Enter a name for the Resource Group, select the Subscription and Location, then click “Create.”

Figure 2-18 Create Resource Group

Virtual Network (VNET)

If you do not have an already-existing VNET with free Address Space, you will need to create a new VNET or alter an existing VNET to include the Address Space you defined in the “Addressing Guidelines & Planning” section.

To create a new VNET:

1. Select “Virtual Network” from “All Services” in the Azure Portal Menu.
2. Select “Add” to create a new VNET.
3. Enter a Name for the VNET.
4. Type the Address Space defined in the “Addressing Guidelines & Planning” section.
5. Select the Resource Group and Location defined in the “What You Need Before Starting” section.
6. Give the Subnet (one that will be created for the VNET) a Name and type the Address Range defined above in the “Addressing Guidelines & Planning” section above.
7. Select “Basic” for DDoS protection and click “Create.”

Figure 2-19 Create VNET

To modify an existing VNET:

1. Select “Virtual Network” from “All Services” in the Azure Portal Menu.
2. Select an existing VNET and select “Address Space” and “Subnets” to alter an existing VNET.

Figure 2-20 Modify VNET

Subnets

Create the Subnets defined in the “Addressing Guidelines & Planning” section above.

To create a new Subnet:

1. Select “Virtual Network” from “All Services” in the Azure Portal Menu.
2. Select the desired VNET.
3. Select “Subnets”.
4. Click the “+ Subnet” button to create a new subnet within the Address Space of the VNET.
5. Repeat for each required Subnet.

Figure 2-21 Create Subnet

Route Tables

Route Tables will need to be created for each Subnet created above. The following routes are required for each Subnet's Route Table:

• MGT – 0.0.0.0/0 Internet
• LAN – next hop set as Company LAN Subnet
• WAN – 0.0.0.0/0 Internet

To create a new Route Table:

1. Select “Route Tables” from “All Services” in the Azure Portal Menu.
2. Click “+ Add.”
3. Enter a Name for the Route Table.
4. Select the Subscription and Location chosen in the “Prerequisites” section above.
5. Enable BGP route propagation if desired.
6. Click “Create.”
7. Repeat for each required Route Table.

Figure 2-22 Create Route Table

Once created, the new Route Table will have to be modified to include all required routes, with a minimum of the above-discussed routes included in each Subnet's Route Table.

To modify an existing Route Table:

1. Select “Route Tables” from “All Services” in the Azure Portal Menu.
2. Select the desired Route Table.
3. Select “Routes.”
4. Click “+ Add” to add a new route.

Figure 2-23 Modify Route Table

Once all required routes are added to the newly-created Route Tables, each Route Table will need to be associated with the appropriate Subnet. To associate a Subnet with a Route Table:

1. Select “Route Tables” from “All Services” in the Azure Portal Menu.
2. Select the Route Table you wish to associate with a Subnet.
3. Select “Subnets.”
4. Click “+ Associate.”
5. Select the VNET & Subnet you wish to associate the Route Table with.

Figure 2-24 Associate Route Table with Subnet

Note:

You may also need to add routes to your already-existing Company LAN Subnet(s) so they can route traffic to the newly-created Subnets.

Network Security Groups (NSGs)

You will need to create two Network Security Groups (NSGs): one for the MGT Interface (to be created in a later step) and one for the WAN Interface (to be created in a later step).

The following rules must to be added for both inbound and outbound traffic for the MGT & WAN NSGs:

• NSG-MGT - Permit TCP 443 | Permit TCP 22 (for browser & SSH access)
• NSG-WAN - Permit UDP 2156-2157 (TRP access)

To create a new Network Security Group:

1. Select “Network Security Groups” from “All Services” in the Azure Portal Menu.
2. Click “+ Add.”
3. Give the Network Security Group a Name.
4. Select the Subscription, Resource Group, and Location previously selected.
5. Click “Create.”

Figure 2-25 Create new Network Security Group

Once the new NSGs are created, the Inbound and Outbound Security Rules discussed above must to be added to each respective NSG.

To modify an existing NSG and/or a new Inbound/Outbound Security Rule to an existing NSG:

1. Select “Network Security Groups” from “All Services” in the Azure Portal Menu.
2. Select the desired NSG.
3. Select “[Inbound | Outbound] security rules.”
4. Add rules as required.

Example Security Rule Configuration: An Inbound Rule allowing TRP Traffic (Talari UDP 2156 traffic) requires the following parameters:

• Source: any
• Source Port Ranges: *
• Destination: any
• Destination Port Ranges: 2156
• Protocol: UDP
• Action: Allow

Figure 2-26 Create Inbound/Outbound Security Rule on NSG

Public IP Addresses

At a minimum, the Virtual Appliance requires 1 Public IP Address:

• WAN Pub IP – Public IP Address to be associated with the WAN Interface.
• MGT Pub IP – Public IP Address to be associated with the MGT Interface (optional once deployment is complete).

Note:

The MGT Interface may be permanently associated with a Public IP if public MGT access is desired. Should MGT access be set-up through the Conduit, however, the temporary Pub IP created for the MGT Interface here can be de-allocated once an Appliance Package has been applied to the Virtual Appliance and MGT access has been verified through the Conduit.

To Create a new Public IP Address:

1. Select “Public IP Addresses” from “All Services” in the Azure Portal Menu.
2. Click “+ Add.”
3. Enter a name for the Public IP Address.
4. Select “Basic” for “SKU” and “IPv4” for IP Version.
5. Static IP addresses are recommended to guarantee use of same Public IP by the Virtual Appliance WAN Links.
6. Select the Resource Group and Location defined in the “What You Need Before Starting” section.
7. Click “Create.”

Figure 2-27 Create Public IP Address

Virtual Network Interfaces (NICs)

The Virtual Appliance requires 3 Virtual NICs at a minimum: one for MGT, one for LAN, and one for WAN. If additional WAN Links are used in the deployment, additional Interfaces will have to be created. Please contact Talari for assistance with advanced topology configuration & deployment.

To create a new Network Interface:

1. Select “Network Interfaces” from “All Services” in the Azure Portal Menu.
2. Click “+ Add.”
3. Enter a name for the new Interface.
4. Select the VNET & Subnet to be associated with that Interface.
5. Choose “Static” IP Address Assignment and give your Interface an IP defined in the “Addressing Guidelines & Planning” section.
6. Select the Subscription, Resource Group, and Location defined in the “What You Need Before Starting” section.
7. Click “Create.”

Figure 2-28 Create a Network Interface

Virtual NIC Configuration

The WAN and MGT Interfaces created above will have to be associated with a previously-created or already-existing Public IP Address and NSG. All Interfaces will also have to be configured for IP Forwarding.

To Associate a Public IP Address with a Virtual NIC:

1. Select “Public IP Addresses” from “All Services” in the Azure Portal Menu.
2. Select a previously-created Public IP Address.
3. Click “Associate.”

Figure 2-29 Associate Public IP to Network Interface

In the “Associate Public IP Address” sub-menu:

1. Select “Network Interface” as the Resource Type.
2. Select the appropriate Network Interface from the “Network Interface” selection menu.

To Associate a Network Security Group with a Virtual NIC:

1. Select “Network Security Groups” from “All Services” in the Azure Portal Menu.
2. Select to a previously-created NSG.
3. Select “Subnets.”
4. Click “Associate.”

Figure 2-30 Associate Network Security Group with Virtual NIC

To enable IP Forwarding on a Virtual NIC:

1. Select “Network Interfaces” from “All Services” in the Azure Portal Menu.
2. Select to a previously-created Virtual NIC.
3. Select “IP Configurations.”
4. “Enable” IP Forwarding and click “Save.”

Figure 2-31 Enable IP Forwarding on Virtual NIC

Deploy The Virtual Appliance

Once all Azure Resources have been created, configured, and gathered, the Virtual Appliance is may be created.

To create a new Virtual Appliance:

1. Navigate to “Virtual Machines” from “All Services” in the Azure Portal Menu
2. Click “+ Add.”
3. Search for “Talari” in the Azure Marketplace.
4. Select the “Talari Networks Virtual Appliance” image.
5. Click “Create”.

Figure 2-32 Select Marketplace Image

Once “Create” is clicked the page will redirect to a settings configuration sub-menu. In order to complete the Virtual Appliance creation process, the user must:

1. Configure basic settings.
2. Choose virtual machine size.
3. Configure optional features.
4. Confirm all appliance setting configurations.

Step 1: Configure Basic Settings

1. Enter a unique name for the Virtual Appliance.
2. Select “SSD” as the VM disk type.
3. Select Authentication type SSH public key
4. Enter “talariuser” for the Username.
5. Select and configure the SSH public key source (example below is for existing public key)
6. Select the Subscription, Resource Group, and Location defined in the “What You Need Before Starting” section.
7. Click “OK.”

Figure 2-33 Create Virtual Machine: Configure Basic Settings

Step 2: Choose Virtual Machine Size

1. Select a desired VM size based your needs and the minimum supported requirements discussed in the “Prepare Your Azure Environment” section above.
2. Click “Select.”

Figure 2-34 Create Virtual Machine: Select a VM Size

Step 3: Configure Optional Features

1. Leave “High Availability” at “None.”
2. Select “Yes” for “Use managed disks.”
3. Select the previously-created/designated VNET.
4. Select the previously-created MGT Subnet.
5. Select the previously-created MGT Public IP Address.
6. Select the previously-created MGT NSG.
7. Select “Off” for the “Auto-shutdown” menu.
8. Enable “Monitoring.”
9. Select the auto-populated Diagnostic storage account.
10. Select “No” for the “Managed service identity” option.
11. Click “OK.”

Figure 2-35 Create Virtual Machine: Configure Optional Features

Step 4: Summary and Deployment

1. Review the summary information and Terms of Use.
2. When satisfied and ready to accept the Terms of Use, click “Create” to build the Virtual Appliance. Wait until the deployment has completed (this can be verified in the notification window).

Note:

Full appliance deployment will take up to 10 minutes.

Step 5: Add Additional Network Interfaces

Once deployed, navigate to the newly-created Virtual Appliance and stop it. You will need to add the additional LAN/WAN Interfaces.

To add a Virtual NIC to a Virtual Machine:

1. Navigate to “Virtual Machines” from “All Services” in the Azure Portal Menu .
2. Select the newly-created Virtual Appliance.
3. Select “Networking” from the VM Menu.
4. Click “Attach network interface.”

Note:

The Interfaces must be attached in the following order: MGT | LAN | WAN. Failure to do so will incorrectly associate the interfaces, resulting in non-operability.

Figure 2-36 Attach Network Interface to VM

Verify all Public IPs, NSGs, Subnets, and NICs are configured, attached, and associated per the instructions above prior to turning the appliance back on.

Final Verification and Network Integration

1. Start the Virtual Appliance.
2. Using the above ssh key pair, login to talariuser on the appliance through the Public IP MGT interface

   Note:

   Even after deployment is successful, it may take some time (up to 10 additional minutes) before the management port will respond on the MGT IP as the software activates. Unless you have custom security rules in place to allow ICMP, you will NOT be able to ping the MGT IP even when it is accessible.

3. Change the talariuser password (sudo passwd talariuser)
4. Open a web browser and navigate to the Public IP. This should give you access to the standard Web GUI. Use talariuser for the user and the password created in the previous step.
5. Install the initial configuration package for the Virtual Appliance site gathered in the “What You Need Before Starting” section. Follow the prompts on the screen to install the package and enable the service.
6. Verify that the Virtual Appliance is connecting to Edge properly and that all paths are functioning as expected. This can be verified either on the Virtual Appliance side or the NCN.
7. Confirm connectivity from the new Virtual Appliance to the APN. At this point, the GUI should be accessible by the previously-defined private management IP. Once confirmed, the Public IP associated with the Management Interface may be dissociated and removed so the Web UI is no longer accessible via the Public IP if desired.

The Virtual Appliance in Azure should now be fully functional and integrated.