Overview

By default, any resource that resides in a Azure Virtual Network cannot communicate with on-premises LSA networks. The centrally-managed Azure Cloud Connectivity offering, using site-to-site VPN connections, enables this communication.

Our architecture for this connectivity is detailed below:

To provide resiliency, we connect to Azure using two site-to-site VPN connections. For site-level fault tolerance, one connection originates in ITF, while the other originates in our LC data center. Each connection has two VPN tunnels for redundancy.

These connections terminate in the (Central US) Location within Azure using a service called Azure Virtual WAN.

Azure Virtual WAN has a couple of components:

The first is a Virtual Hub; This is a Microsoft-managed virtual network where the VPN appliances live and the connections from campus terminate into Azure.

The second is the Virtual network connections; This is the resource that the Azure VNets Peer into to gain access to our VPN connections. When a customer requests that this connectivity enabled in their Azure Subscription, we will create a VNet Peering from their subscription to our Virtual WAN Virtual Network Connection resource.

Note: While Azure does support VNet Peering across Subscriptions, this functionality is specifically disabled for customer Virtual Networks. If you need to enable communication between two or more of your Azure Subscriptions, please reach out to the Cloud Team to discuss options.

Cost

ITS is centrally funding the VPN connections to campus. However, there are resources that get created to support this connection, and those resource costs are the responsibility of the customer. Customers are also responsible for charges that they incur for any data that traverses the connection.

Example:

You are a customer that uses this connectivity to reach a server on campus that resides in an LSA network. You are accessing it from a single Azure Subscription and transfer 500GB of data over the course of a month using this offering.

Site-to-site VPN connections provided by ITS Enterprise Infrastructure - No cost

VNet peering - 500GB - at $0.035/Gb

Total Estimated Charges - $17.5/month

Limitations

There is an issue caused by asymmetric routing when users on campus meet the following conditions:

• Their Virtual Network is configured for Campus to Cloud Connectivity as outlined in this article, and...
• They are trying to access an Azure resource that resides in their VNet. This could be a Virtual Machine, Azure SQL Server, etc., and...
• The resource they are trying to access has a public IP address fronting it (Static IP or dynamically assigned by Azure), and...
• The DNS name resolves to that public IP, or they are accessing it via that public IP directly

On campus, private routes takes precedence over the default internet route so traffic destined for a resource’s public IP will be delivered but return traffic will go over the VPN tunnel and be dropped. We recommend using the private IPs assigned to your Azure VNet-based resources to connect from campus. Additionally, you can configure separate DNS records with hostmaster to manage the private and public IP addresses.

Requests

We encourage customers to meet with us prior to submitting a request to enable this connectivity in their Azure Subscription. You can schedule time to speak with us.

Request Campus to Cloud Connectivity in your Azure Subscription