Getting started Azure Networking
Are you new to Azure networking and trying to find your way through the networking documentation on Azure.com? It can be a challenge, because that site’s navigation is built around the names of the products, and these product names do not always make it easy for you to understand exactly what that product or feature actually does. Many websites present that same dilemma; you’ll see a similar layout on Amazon’s AWS site. The problem is that if you aren’t familiar with the product or feature name, and you’re looking for information about a particular networking capability, you might have to wander around for a while to find what you’re looking for.
So we’re going to talk here about some of the networking capabilities first, and tell you the names of the products or services that go with those capabilities. Here’s a quick “cheat sheet”:
- Virtual network infrastructure (Azure Virtual Networks)
- Network access control (Network Security Groups)
- Remote access (Azure gateway/point-to-site VPN/RDP/Remote PowerShell/SSH)
- Cross premises connectivity (site-to-site VPN/dedicated WAN link)
Now let’s take a look at each of these and get an overview of how they work.
Virtual network infrastructure (Azure Virtual Networks)
An Azure Virtual Network is your little piece of the Cloud – a representation of your own isolated network within the multi-tenant infrastructure. You can subnet it, control IP address blocks, deploy servers, set security policies and routing tables and DNS configurations as you do with an on-premise network. You can even connect it to your on-premise network.
The machines on your Azure Virtual Network are, of course, virtual machines (VMs). The Azure VMs are built on Hyper-V, like the VMs in many on-premise datacenters. Because Azure is a multi-tenant environment, Microsoft has to isolate customers’ networks from one another. They do this using Hyper-V Network Virtualization (HNV in the Windows Server software defined networking stack, which encapsulates each customer’s network communications inside a GRE header with a field specific to each individual customer.)
Find out more about Hyper-V network virtualization in this article, Hyper-V Network Virtualization Overview.
You must create an Azure Virtual Network before you create a virtual machine, as all virtual machines have to be placed on an Azure Virtual Network. Most customers, when creating an Azure Virtual Network, use a large block of IP addresses and then subnet that range, just as you do on-premise. You can assign dynamic or static IP addresses to VMs.
Find out more about Azure Virtual Networks, in this article, Virtual Network Overview.
Network access control (Network Security Groups)
Access controls are key to restricting access of network resources to those who are authorized to use them, whether that network is on-premise or in the cloud. In Azure, Network Security Groups (NSG) are the method by which you implement and enforce access controls on an Azure Virtual Network.
Network Security Groups are not groups of VMs or groups of users; rather, they are groups of firewall rules that define whether traffic is to be allowed or denied for a specific source or destination. NSGs work like a simple stateful packet filtering firewall or router; they use a 5-tuple consisting of source and destination IP address, source and destination port, and the protocol (TCP or UDP). You can use NSGs to control access between two VMs, between one VM and a group of VMs, or between subnets.
Network Security Groups come with the following built-in rules:
- ALLOW all traffic within a specific virtual network. Allows all virtual machines on the same Azure Virtual Network to communicate with each other.
- ALLOW Azure load balancing inbound. Allows traffic from any source address to any destination address for the Azure load balancer.
- DENY all inbound. Blocks all traffic sourcing from the Internet that you haven’t explicitly allowed.
- ALLOW all traffic outbound to the Internet. Allows virtual machines to initiate connections to the Internet. If you do not want virtual machines to initiate connections to the Internet, you can create a rule to block those connections or you can enforce forced tunneling.
Find about more about Network Security Groups in this article, What is a Network Security Group (NSG)?
Remote access (RDP/SSH/Azure gateway/point-to-site VPN)
When you run your own virtualization infrastructure, you can directly access the virtual machines over the virtual machine bus (VMbus). You don’t need to go over the virtual networking infrastructure. Owners of the virtual machines or the services that run on the virtual machines typically aren’t allowed access over the VMbus. If they are, this level of access is often temporary and revoked when it’s no longer needed.
When you’re in the public cloud, things are different. Now you’re not the administrator of the virtualization platform so you don’t have direct virtual machine access over the virtualization platform’s VMbus. If you want to configure and manage the VM, you must do it over a remote network connection – typically the Internet or a dedicated WAN link. Let’s look at the types of remote access connections that you would use over the Internet to manage virtual machines and the services running on the virtual machines. Basically, you have three choices:
- Remote Desktop Protocol (RDP) – This is usually the easiest way to remotely access a VM on an Azure Virtual Network. You can create a NSG rule that allows access from the Internet to a VM using RDP. However, RDP ports are a frequent target of attackers who try to obtain credentials through a brute force attack, so using RDP might not be the best option from a security-conscious point of view.
- Secure Shell Protocol (SSH) – You can use SSH to access both Windows and Linux virtual machines on an Azure Virtual Network. However, as with RDP, user names and passwords can be compromise through a brute forced attack, so might not be the most secure option.
- Point-to-Site VPN using Secure Sockets Tunneling Protocol (SSTP) – The SSTP protocol tunnels communications over the Internet using a TLS encrypted HTTP header, which means SSTP can be used across firewalls and web proxies. In order to establish the point-to-site VPN connection, you have to authenticate with the VPN gateway. The Azure VPN gateway and VPN client both use certificates to authenticate with each other. Certificate authentication isn’t susceptible to brute force attacks like direct RDP or SSH connections over the Internet can be. This is a nice security advantage.
Cross premises connectivity (site-to-site VPN)
Cross-premises (or cross-site) connectivity refers to a connection between one site (such as your on-premise network) and another site (such as an Azure Virtual Network). This allows traffic to move between these two networks. You can accomplish cross-site connectivity with Azure via a site-to-site VPN or through a dedicated WAN link.
In contrast to a point-to-site VPN, with a site-to-site VPN you can connect an entire network to an Azure Virtual Network instead of just a single device (endpoint). Another term for site-to-site VPNs is “gateway-to-gateway” VPNs; that’s because each end of the VPN connection is a VPN gateway device. A VPN gateway acts like a router that uses a VPN tunnel to route connections from the on-premise network to the Azure Virtual Network. The Azure VPN gateway is compatible with most standard on-premise VPN gateways, as long as they use IPsec tunnel mode (as most do).
The drawbacks to the site-to-site VPN are that they’re limited in transfer rate, maxing out at approximately 200Mbps, and the VPN connection goes across the Internet (as opposed to a dedicated WAN link). Depending on your performance needs, the first might or might not present a serious problem. Anytime traffic goes across the Internet, it’s exposed to the potential for interception or attack. However, the IPsec tunnel is considered to be very secure. Unless you’re dealing with information that requires the very highest level of security, this might not be an issue; that’s something that must be decided through a comprehensive data classification and risk assessment system.
Find out more about site-to-site VPN with Azure in this article, Create a virtual network with a Site-to-Site VPN Connection using the Azure classic portal.
Cross premises connectivity (dedicated WAN link with ExpressRoute)
If you do, in fact, need the absolutely most secure connection between your on-premise network and the Azure Virtual Network, and/or you need top performance/speed, and you’re willing to pay for it, you can purchase a dedicated WAN link from the telephone company that provides a direct physical connection that doesn’t go over the Internet. Microsoft offers the option of using ExpressRoute to establish a dedicated WAN link between your network and the Azure Virtual Network. This gives you the following advantages:
- Faster connection – up to 10Gbps, which is 50 times faster than the site-to-site VPN maximum.
- More secure connection – a private, direct connection that doesn’t go over the Internet.
- SLA – a Service Level Agreement that provides guaranteed levels of uptime and performance.
There are two different types of WAN links supported by ExpressRoute: Multiprotocol Line Switching (MPLS) and Exchange Provider connectivity. Exchange Provider is faster (up to 10Gbps in comparison to 1Gbps for MPLS.
Find out more about dedicated WAN links with Azure Virtual Networks in this article, ExpressRoute Technical Overview.
In this article, we’ve given you a “quick and dirty” look at some of the networking capabilities of Azure, but we’re only touched upon the tip of the iceberg. Azure is a powerful and flexible infrastructure that gives you many options. We hope this gets you started on a long and happy journey into the cloud.