When I started learning how to use Azure IaaS, I probably spent most of my time learning about Azure virtual networking. I found VMs to be easy; it’s just self-service virtualization and it’s based on Hyper-V so it was an easy evolution for me. But the networking required a bit of learning, especially because there are lots of options, lots of it is driven by PowerShell, and it is constantly evolving.
What are Virtual Networks?
As I’ve said many times before, I used to work in the hosting business, back in a time when the VLAN was the dominant way to deploy customers. If sales signed up a customer, that customer got one or more VLANs, and the network guys panicked. More VLANs were being added, more firewall rules had to be deployed, and NAT had to be configured. We were looking at hours-to-days of waiting before I could drag a few templates from the VMM or vCenter library to have the customer up and running. In Azure, you do not call up Microsoft and say “hey, I need 2 VLANs, please”. Instead, you run some PowerShell or walk through a wizard and deploy your own isolated network address space.
A virtual network is kind of like a LAN. It is am isolated address space that can be divided into automatically routed subnets. You can create virtual networks from each of the following ranges:
- 192.168.0.0
- 172.16.0.0
- 10.0.0.0
We use these virtual networks and subnets to connect virtual machines within a single region. Each virtual network is isolated, so you might create 2 vNETs and they will be completely secure from each other unless you take steps to connect them.
The above diagram shows a deployment of a virtual network with 2 subnets, modelling the concept of a DMZ and back-end subnet. By default, there are no firewall rules or blocks between subnets in the same virtual network. However, you can deploy a policy-based set of rules called network security groups (NSGs) to isolate virtual machines or subnets.
Virtual Network and Subnet Addresses
As you can see, they are private ranges. You can get up to 5 public IP addresses for free (if you use them) to implement NAT-like “end points” with virtual machines, where you specify that if any traffic come in on a port, that traffic is sent to a VM or set of VMs (external load balancing, which is free, as is internal load balancing). This public IP addresses are usually provided by a cloud service, and are called VIPs (virtual IP addresses). Note that VIPs are dynamic by default, but you can reserve them for free (as long as the associated service is active).
You can carve up your address space to create VLANs. I recommend two practices with my customers:
- KISS: Keep it simple, stupid. I might deploy a virtual network with an address of 10.0.0.0/16. I can create plenty of subnets with a /24 address. So subnet 1 might be 10.0.0.0/24 and subnet 2 might be 10.0.1.0/24. If you are subnetting-disabled like me, this is easy to understand, you simply increase the third octet by a decimal 1. Ignore this rule (a) if you do understand subnetting and (b) you need more-smaller subnets or fewer-larger subnets.
- Plan for expansion and connectivity: If a customer is using 192.168.0.0/24 on premises then don’t deploy a virtual network of 192.168.0.0, even if you don’t plan on connecting them at the moment. Things change, and a customer’s plans with Azure will evolve. Treat Azure virtual networks like branch office networks, and plan for connectivity and routing.
Virtual Network Connectivity
As I said before, a virtual network is isolated. You can create endpoints to allow traffic into virtual machines from the Internet. However, you might want private communications between 2 vNETs or between a vNET and an on-premises network. This is made possible using a gateway.
Connecting an on-premises network via VPN to an Azure vNET using a gateway
A gateway is a virtual appliance that you deploy on your vNET, usually in a /29 subnet that supports just 3 IP addresses (default gateway to route, and 2 others); vNET can have one gateway. The gateway is actually a cluster of 2 virtual machines that are managed by Azure – you simply configure gateway settings and you cannot even see these VMs. The purpose of the gateway is to enable private and secure network connections with routing:
- Point-to-Site VPN: This is enables users to VPN into an Azure vNET. Really, this is intended as a backdoor for administrators. End users should use the software layer (Windows Server VPN/DirectAccess or VPN services from a virtual appliance).
- Website-to-vNET VPN: An Azure website can VPN into a vNET, allowing that website to talk to services hosted on a VM, e.g. MySQL for WordPress.
- vNET-to-vNET VPN: Connect two vNETs together even if they are in different regions or subscriptions, enabling VMs in different vNETs to talk to each other.
- Site-to-site VPN: Connect a customer site to an Azure vNET, enabling on-premises machines to talk freely with in-Azure VMs. For example, DCs on the customer site could replicate with DC VMs from the same domain that are running in Azure over this encrypted connection over the Internet.
- ExpressRoute: Get an SLA driven private WAN connection into your virtual networks, using an MPLS WAN or hop via a POP. This service is only supported by a small number of operators, and some of these operators are poor at communicating to their owns staff that this service is available – BT in UK/Ireland is particularly guilty of this.
Connecting multiple sites and Azure vNETs using ExpressRoute
There are 3 models of gateway that you can deploy:
The basic gateway breaks down into two types:
- Static: Also known as a policy-based VPN, this is good for simple deployments, e.g. a 1:1 site-to-site VPN connection, and pretty much nothing else. This type has the most support from 3rd party firewall appliances.
- Dynamic: Also known as a route-based VPN, dynamic routing provides the most compatibility with connection features (site-to-site, point-to-site, vNET-to-vNET, and website-to-vNET)
Long story-short, we always want dynamic routing, but only a small number of on-premises appliances support it.
You can find feature support across the tiers and types of gateway below:
Remember how I said a gateway is a pair of VMs? The basic tier is a VM with 1 vCPU. This limits how many interrupts the VM can handle and this restricts inbound bandwidth to around 80 Mbps (100 is listed but 80 is what is achievable). The next tier up, Standard, uses VMs with 2 x vCPUs and this doubles the interrupt handling capability, increasing the inbound bandwidth to 200 Mbps – thank you Hyper-V vRSS.
Network Security Groups & Force Tunneling
These are two features that are almost related because they are likely to be used together. In the above diagram, NSGs are used to restrict network communications. Force Tunneling could also be used:
- Allow the DMZ VMs to communicate directly with the Internet, according to security policies. Outbound traffic will go directly to the Internet via the Azure fabric.
- Force back-end VMs to route via the Internet via a site-to-site network connection, ensuring that all traffic from these machines is more closely controlled.
Using Forced Tunneling to manage outbound traffic from Azure subnets
IP Addressing
I’ve already talked about how VIPs are used to enable the public Internet to access your vNETs, subject to endpoint rules that you create. What about internal addresses? The Azure vNET will supply the IPv4 configurations to your VMs. From the guest OS point of view, this is DHCP … AND YOU SHOULD LEAVE IT THAT WAY.
The default gateway of a vNET is the first IP address in the range – .1 if you follow my KISS rule. The first VM to come online will be assigned the 4th address (KISS: .4) and then the fifth, etc. VMs will not get static addresses. If you shutdown (de-allocate) a VM then it is not guaranteed the same IP if you reboot it – however you can reserve an IP; I typically do this with DCs.
Name services can also be deployed, e.g. DNS on a DC. You can pre-define the DNS part of the IPv4 stack for VMs in the properties of a vNET.
Multiple NICs in a VM
I dealt with this topic a little while ago in a post about finding specs for Azure VMs. Some VM specs support more than 1 vNIC. From what I can make out, this is intended for vendors who are creating virtual appliances that need to span more than one vNET; consider a firewall that connects the external world and VMs in several vNETs – you don’t want any routing other than the firewall appliance so that appliance needs to be able to communicate directly with each vNET.
Connecting a virtual appliance to multiple subnets in an Azure vNET
Pricing
Some good news: vNETs are free. You can have up to 50 vNETs in a single subscription, with up to 2048 VMs per vNET, and up to 500,000 concurrent TCP connections per VM.
NSGs and Forced Tunneling are both free. You can have up to 100 NSGs with 200 rules each per subscription.
You can have up to 50 reserved VIPs, 5 of which are free (including reservation) if they are being used. The pricing for the additional 15 or unused VIPs are found here. Private IP addresses are free.
Pricing for a gateway is found here – that covers the cost of connecting a VPN, but you also need to account for outbound data transfers (egress data). Note that you’ll need to work with an ExpressRoute partner to figure out the pricing of that solution – here’s the Microsoft element – I know that Microsoft wants to simplify this pricing, as announced at the recent AzureCon online event.
Data Transfers
This is one of the most mis-understood elements of Azure. There are two types of data transfer:
- Inbound (ingress)
- Outbound (egress)
Let’s keep this simple:
ExpressRoute is charged based on bandwidth (no data transfer charges across this private connection) or metered data (contact your ISP).
Everything else is subject to ingress/egress rules. Azure does not charge for inbound data transfers. And now things get complicated.
Despite many myths, outbound data transfer is charged for, but it depends on the service. If you are using Azure Backup, there is no network data transfer charge. If you have VMs sending data to the Internet or outbound via VPN, then that is subject to charge.
Example
Pricing is based on North Europe at the time of writing.
A customer is deploying a web farm in Azure. They want a virtual network that will have 3 subnets: web, application, and database. They need to offer online web services via 2 always active VIPs, and 1 usually de-allocated VIP. There will be 10 load-balanced web servers (external load balancing) and 5 load balanced application servers (internal load balancing). A site-to-site VPN connection is required from on-premises, the firewall is a WatchGuard Firebox, with a 50 Mbps connection. Each vNET must have policy based isolation. Web servers can talk directly to the Internet, but app and database servers must always route via the VPN to anything other than the web servers. The web servers are expected to send 1 TB of data to the Internet and receive 400 GB of data.
OK … let’s break this down:
- Virtual network & subnets: free.
- VIPs: We get up to 5 free if they are used, even if they are reserved. The de-allocated VIP will cost around €3/month.
- External load balancing (web servers): Free
- Internal load balancing (app servers): Free
- Gateway (VPN): The WatchGuard doesn’t support dynamic gateways so a static gateway is required. The static basic gateway supports up to 80 Mbps so it’s fast enough. This will cost around €23/month.
- NSG: Free
- Forced Tunneling: Free
- 1024 GB outbound data transfer: First 5 GB is free, and remaining 1019 charged at €0.0734 per GB, which is around €75/month
- 400 GB inbound data: Free
So that works out at: €3 + €23 + €75 = €101/month.