Connect an on-premises network to Azure
Posted July 7, 2021 by Adrian Wyssmann ‐ 5 min read
While modern companies may use a pure cloud approach, there are still companies which still have their own datacenter. Thus connecting your on-premiss network to the cloud is essential. In this post, I will have a look on how this works and what is required, focusing on Azure, as this is what we currently use at my employer.
The maybe simplest one is to have a VPN Gateway to extend an on-premises network.
To set up the VPN connection you need:
- Two endpoints that are addressable and located on the public Internet.
- An on-premises VPN device (hardware or software) to terminate the VPN connection, which uses Internet Protocol security (IPsec).
- An Azure virtual network with a site-to-site VPN connection. The network should have enough addresses for at least one subnet that can contain all Azure VMs.
- A route on the on-premises network, to forward traffic destined for the address space of the Azure virtual network to the on-premises VPN device.
- Firewall rules for traffic to and from the on-premises VPN device (IP port 50, UDP port 500 and 4500, both incoming and outgoing).
- A web proxy that gives computers that are connected to the on-premises network and the Azure virtual network access to the Internet.
The on-premises network might still have network services like Active Directory Domain Services (AD DS), Domain Name System (DNS), and proxy servers. Depending on your requirements, it might be beneficial to place some of these network resources in the Azure virtual network.
Checkout Connect an on-premises network to a Microsoft Azure virtual network for detailed instructions on how to plan and setup.
Below we have another example using VPN to also connect to [Azure Stack][#azure-stack]:
Azure ExpressRoute allows you to connect your datacenter via a private connection, rather going over the public internet as it is the case for VPN.
There are certain benefits over the VPN connection:
- Layer 3 connectivity between your on-premises network and the Microsoft Cloud through a connectivity provider.
- Connectivity to Microsoft cloud services across all regions in the geopolitical region.
- Global connectivity to Microsoft services across all regions with the ExpressRoute premium add-on.
- Dynamic routing between your network and Microsoft via BGP.
- Built-in redundancy in every peering location for higher reliability.
- Connection uptime SLA.
- QoS support for Skype for Business.
Azure Stack is an extension to add Azure services and capabilities to your environment (datacenter, remote location, edge devices). It includes three different services
- Azure Stack Edge is a hardware-as-a-service solution, which offers special cloud-managed devices for any edge location. There are three different devices available:
- Azure Stack Hub is an integrated hardware and software system which let you have your own autonomous cloud, while using the same tools as you use for managing Azure subscriptions. This requires so called scale units (racks with 4-16 servers) in your datacenter, which are provided by Microsoft partners. This can be connected or even disconnected from the cloud.
- Azure Stack HCI is a hyperconverged infrastructure (HCI) cluster solution that hosts virtualized Windows and Linux workloads and their storage in a hybrid, on-premises environment and allows you to natively monitor, secure, and back up to the cloud. Via the Azure portal you also have a central view of all your Azure Stack HCI deployments. This requires 2 to 16 validated servers running a specialized operating system purposely defined for hyperconverged infrastructure.
There are certain differences between Azure Stack Hub and Azure Stack HCI. To summarize it in a sentence, Azure Stack HCI is about connecting your datacenter to Azure services, whereas Azure Stack Hub is about having Azure services in your datacenter.
What is Hub and spoke?
At last we want to have a look at specific architecture pattern, the Hub-spoke network topology in Azure. The terminology comes from transportation, where traffic flows trough a central “hub”. Like in wheel, the routes (“spokes”) connect to the other endpoints from central hub. This requires less routes than a point-to-point connections between all endpoints.
In this pattern, you have a hub virtual network, that acts as a central point of connectivity to many spoke virtual networks
Typical uses for this architecture include:
- Workloads deployed in different environments, such as development, testing, and production, that require shared services such as DNS, IDS, NTP, or AD DS. Shared services are placed in the hub virtual network, while each environment is deployed to a spoke to maintain isolation.
- Workloads that don’t require connectivity to each other but require access to shared services.
- Enterprises that require central control over security aspects, such as a firewall in the hub as a DMZ, and segregated management for the workloads in each spoke.
Above are just basic considerations and if you are interested in more specifics, I recommend to follow-up here: