Azure Virtual Networks provide a great way of allowing cloud services, websites, and virtual machines to communicate with each other, much like in an on-premise intranet. As a novice on the networking side, I had to learn some basics about these networks, and I'd like to pass on some of these lessons.
In this article, I will cover how to set up an Azure virtual network ("VNET"), how to set up an Azure virtual machine ("VM") on that VNET, and then how to configure that VM for web traffic, including endpoint and ACL configuration. As an added bonus, you'll see how to configure an Azure Web Role cloud service on the VNET, as well as how to restrict web traffic to only allow other VMs and services on the VNET.
Create the Azure Virtual Network
Obviously, since we are adding VMs to a VNET, we need to create both. To start, click New –> Network Services –> Virtual Network –> Custom Create, which allows us to specify detailed information on the address spaces and ranges.
Step 1: Specify VNET name and location
Specify a meaningful name, then select the appropriate location. Here, I’ve specified “vnet-md-demo1”, and the South Central US location, since I’m closest to it.
Remember, you’ll get less latency if your storage accounts, services, VMs, and VNETs are in the same location (data center).
Step 2: Leave the DNS server information as-is
Although it is not covered in the scope of this article, you can configure a custom DNS server, which can provide additional benefits. For this article, we will use Azure-provided name resolution. For more information on the features and considerations of each, go to http://msdn.microsoft.com/library/azure/jj156088.aspx
Step 3: Configure the address spaces, or IP ranges
The address space configuration allows you to set up the IP ranges for the VNET, with multiple parent address spaces, each with multiple subnets. You need to specify the CIDR, but Azure provides the address count that each represents. You can do the same for the subnets, up to the number of addresses allocated in the subnet’s address space. If you are interested in learning more about CIDR: http://ip2cidr.com/cidr.php
For this article, I’ve created a single address space with 128 addresses, and the default starting IP. I’ve also created 2 subnets, each with 16 possible addresses and the default names (“Subnet-1”, “Subnet-2”), as next I’ll be creating a VM on each. You can build your network as you see fit, and even across subnets, the machines will be able to communicate with each other. This also applies to cloud services, both Web Roles and Worker Roles.
Create the Azure Virtual Machines
As mentioned above, we are going to create two VMs on our newly-created VNET, so we can demonstrate how they communicate with each other. To start, click New –> Compute –> Virtual Machine –> From Gallery, which allows us to specify the VNET before the VM is provisioned.
Step 1: Select the image
For this article, we’ll select Windows Server 2012 R2 Datacenter, which supports a wide variety of applications and web functionality. Plus it’s the data center edition, and that just sounds fun.
Step 2: Configure the VM
Provide a meaningful name, but make sure it is DNS-compatible – use letters, numbers, and hyphens. For this article, I’ve selected the latest version of the OS, the VM name “vm-md-demo1a”, I’ve selected A1, since I can run it all month without going over my credit limit. Provide the user name and password, and continue.
NOTE: Another great thing about VMs is that you only pay for what you use, meaning that if you shut the VM down, you don’t pay for it, even though the image still retains whatever you have installed. If you want to try out the beefy machines, like the A7, which has 8 cores and 56 GB RAM, you can run it for a few hours, then shut it down.
Step 3: Configure the VM for the VNET
Here, I left the Cloud Service DNS Name the same as the VM name, since it was DNS-compatible. Also, rather than selecting a Region, we will select the VNET, which then allows us to select which Subnet the VM will live in (I’ve selected “Subnet-1”). For now, leave the Endpoints alone, as we will come back to them in more detail.
Step 4: Finish the wizard
You can select other features, but finish creating the VM, and Azure will begin provisioning the machine.
Step 5: Configure the second VM
Follow the same steps to create another VM, except on Subnet-2 (or whatever name you specified for the second subnet), and wait until both VMs have been provisioned.
Configure VM as Web Server
So that I can test connectivity, I’m setting up the first VM as a web server, as this will likely be a common use for future Azure VMs you configure.
Step 1: Configure Windows
Connect to the VM with RDP, which you can do through the Azure management portal by clicking “Connect”.
Setting up the web server entails adding the additional Windows features for IIS, and the necessary extensions for ASP.NET, etc. These specific steps are outside the scope of this article, but there is an abundance of information on how to do so.
Step 2: Create a test page
Let’s create a test web page we can hit from our other VM and from our local PCs. By default, you’ll create the default web page in C:\Inetpub\wwwroot\. You can test with http://localhost/. Here, you can see I’m rocking the classic ASP:
Step 3: Try to browse to the web VM from your home PC
Open up a browser, and try to hit [your-vm-name].cloudapp.net. It probably looked like this:
Why didn’t it work? We were able to connect via RDP…
Because we need to open up the appropriate endpoint!
Add an Endpoint to an Azure Virtual Machine
Endpoints are like the firewall. We need to configure which ports are open, and they even support port redirects, just like a router. To start, go to your VM in the Azure management portal, and click the Endpoints option near the top, under the VM name. Once there, click Add.
Step 1: Select type of endpoint
For this article, we are configuring a stand-alone endpoint, but the Azure endpoints support load-balanced configurations.
Step 2: Configure the endpoint ports
Azure predefines quite a few commonly-used ports, including HTTP and HTTPS, but you can also create custom port endpoints. For example, a VM running Elasticsearch will need port 9200 opened.
NOTE: For non-typical ports like Elasticsearch, you may also have to configure the Windows Firewall to open up that specific port.
Step 3: Try again from your PC
After the endpoint has been created, try browsing to the VM again, and you should succeed.
Adding a Cloud Service to an Azure Virtual Network
Before we move further, I think it is helpful to explain how to get a cloud server onto your VNET. After all, we can’t do it through the management portal; we have to do it at deployment.
Step 1: Get the Fully-Qualified Domain Name (FQDN)
To communicate between VMs and services in a VNET, you can use IP addresses or Azure-provided name resolution. Azure-provided name resolution in a VNET requires the FQDN, which you can get in the command prompt.
The “hostname” command gives you the expected VM name, in this case “vm-md-demo1a”.
The “nslookup [hostname]” command provides the FQDN, which is the internal DNS name (“…internal.cloudapp.net”) for this VM’s IP address, in this case “10.0.0.4”.
Step 2: Modify the Azure project’s service configuration
You will need to add the Network Configuration to the Service Configuration (.cscfg) document:
<VirtualNetworkSite name="vnet-md-demo1" />
<Subnet name="Subnet-2" />
Once the cloud service is on the VNET, you can reference other members of the network by FQDN or IP address.
Limiting Access to a Virtual Machine
We successfully hit our first VM through the browser from our home PC, but now we should try from our second VM. Try the following 3 test cases, which should all work:
- Using external DNS name (i.e., http://vm-md-demo1a.cloudapp.net)
- Using FQDN (i.e., http://vm-md-demo1a.vm-md-demo1a.j1.internal.cloudapp.net)
- Using VNET IP address (i.e., http://10.0.0.4)
Now, we are going to prevent access to our first VM from our PC, while retaining access for anything on the VNET. Before we begin, review the address space and subnets, because you will need the CIDR information that provides the IP address ranges.
For this article, we will specify the permitted IP addresses for the HTTP endpoint we previously created; not just for an individual subnet, which we could easily do, but for the entire address space. To start, navigate to the HTTP endpoint for the first VM in the Azure management portal, and click Manage ACL, at the bottom.
Here, I provided a meaningful name, set the Action to “Permit”, and the Remote Subnet to the CIDR of my VNET’s address space (“10.0.0.0/25”). Optionally, I could specify individual subnets to Permit or Deny.
NOTE: The ACL rules are evaluated in order, so you could allow a larger subnet, then restrict smaller pools of IP addresses. For more information, go to http://msdn.microsoft.com/library/azure/dn376541.aspx
Now, after the ACL configuration is applied, try accessing the VM from your home PC. It should fail.
Try now from the second VM.
- Using external DNS name (i.e., http://vm-md-demo1a.cloudapp.net) should FAIL
- Using FQDN (i.e., http://vm-md-demo1a.vm-md-demo1a.j1.internal.cloudapp.net) should SUCCEED
- Using VNET IP address (i.e., http://10.0.0.4) should SUCCEED
So, we have successfully blocked outside network traffic from accessing our VM.
Why prevent access to your VM?
Great question. If you are building an API for consumption by your cloud services, or you have an Elasticsearch implementation with sensitive data, you surely don’t want to expose that functionality or data to the outside world. The endpoint ACLs are an excellent way to prevent that access and secure your services.
I had to pull a lot of this information together, but now you can see how to:
- Create an Azure Virtual Network
- Create and configure an Azure Virtual Machine on a Virtual Network
- Deploy a Cloud Service inside an Azure Virtual Network
- Manage Endpoints and ACLs to control access to a Virtual Machine
Hope this helps!
Mark Doyle is Software Architect at Collabroscape [collabroscape.com], and Founder & President of Scruddle [scruddle.com]. You can follow him on Twitter [@mark_doyle_ftw], or connect with him on LinkedIn [www.linkedin.com/in/spencermarkdoyle/].