Azure Virtual Datacenter - Part 1 - Overview

Read time: 5 minutes

Series overview

• Azure Virtual Datacenter - Part 1 - Overview
• Azure Virtual Datacenter - Part 2 - Virtual Networks
• Azure Virtual Datacenter - Part 3 - Firewall deployment

What is an Azure Virtual Datacenter?

The term Azure Virtual Datacenter was introduced by Microsoft as an approach for extending your on-premises datacenter to the public cloud in a secure way. The complete description of the Azure Virtual Datacenter is described in the eBook “Azure Virtual Datacenter”, which can be found here: https://azure.microsoft.com/mediahandler/files/resourcefiles/1ad643b8-73f7-43f6-b05a-8e160168f9df/Azure_Virtual_Datacenter.pdf.

This series will cover the creation of an Azure Virtual Datacenter from a networking point-of-view. Software Defined Networking is a key component of the Azure Virtual Datacenter, which gives you a very flexible networking solution to work with. On the other hand, some things need to be done different, compared to traditional networking since layer 2 can’t be used in Software Defined Networking. In future series, I will cover governance and compliancy more in detail.

Azure Virtual Datacenter Design

The demo environment I will create throughout the series will be an Azure Datacenter, based on a hub-and-spoke model. An on-premises network is also needed to test networking from and to the Azure Datacenter. I will create a separate Virtual Network to simulate the on-premises datacenter, connected with a site-to-site VPN.

Here an overview of the complete environment:

Design decisions

Hub-and-Spoke model

The environment is built on the Hub-and-Spoke model. In this model, there is a centralized hub that connects the external and spoke networks. All traffic is sent through centralized firewalls, enabling you to filter and analyze the network traffic. It also contains all necessary centralized services like management servers, Active Directory, DNS, … .

The workloads are separated in different spokes. These spokes are actually Virtual Networks, connected to the central hub using vNet peering. This way, you can separate different types of workloads delivering a secure environment for the services, running in the spokes. Another approach could be separating operational companies or teams in different spokes for segregation of duty.

User Defined Routes

User Defined Routing is one of the benefits of Software Defined Networking. Using User Defined Routes, you can steer traffic in a desired direction. In this case, we will send all traffic from the spokes and the gateway subnet to the load balancer of the centralized firewalls.

Route or NAT

For internet traffic, traffic should use NAT, or more detailed sNAT or source NAT. This way, the source IP of a network package is translated to the public IP.

For traffic between east and west (between the on-premises network and the Azure Virtual Datacenter), routing should always be used. This is very important since some protocols, like Kerberos, don’t work (well) through NAT.

Standard load balancer

Before standard load balancers came into play, basic load balancers were the only way to use load balancing in Azure. But using a basic load balancer, ports need to be added one port per rule, where standard load balancers have HA ports where all ports can be specified in a single rule.

Firewall-on-a-Stick

Flow symmetry

Since the standard load balancer came available, a true active-active firewall setup came in sight. Multiple ports (or the complete range of 1-65535) could be forwarded in a single rule, but traffic needs to be symmetric. If a load balancer is placed on the untrusted side, and another on the trusted side, all traffic is load balanced in both directions. But there is no guarantee that returning traffic will flow through the same firewall it came in. To solve this issue, firewall-on-a-stick is used where traffic flows in and out of the firewall through the same port. This means that only one load balancer is needed for both incoming and returning traffic.

Why does it work?

The load balancer uses a hashing method to determine where to send the traffic to. This hashing method can be configured as a 2-tuple hash, or a 5-tuple hash. A 2-tuple hash creates a hash, based on the source IP and the destination IP. A 5-tuple hash create the hash based on the source and destination IPs, source and destination ports and the protocol. Using 5-tuple hash, session affinity is achieved.

In the following example, a packet is sent and returned through the firewalls. For the incoming flow, the hash is calculated on source IP 10.0.0.1 and destination IP 10.0.1.1, resulting in the example hash 123456789ABCDEF. When the recipient answers, the IPs are the same, but the order is reversed. The source IP is now 10.0.1.1 and the destination is now 10.0.0.1, resulting in the same hash and therefore, the same firewall is used.

More information about this topic can be found here: https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-ha-ports-overview

Source code

All examples will be deployed using ARM templates. This way, you could use them as a guide and implement them with minor changes if you want to try it yourself.

The ARM templates can be found on my Github: https://github.com/christofvg/AzureVDC

Conclusion

In this post we looked at the design of the Azure Virtual Datacenter. We covered the design decisions and explained the load balancing in the magical software defined network. In the next posts, we will make our hands dirty and start building our own Virtual Datacenter.