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 –> Everything, and then either find Virtual Network in the Virtual Machines gallery, or search for “Virtual Network”.
Step 1: Specify VNET name and location
Specify a meaningful name, then select the appropriate location. Here, I’ve specified “vnet-md-demo2”, 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: 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.
NOTE: 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, by changing the CIDR from 10.0.0.0/16 to 10.0.0.0/25. I’ve also created the first subnet, aptly named “Subnet-1”, that has 16 possible addresses, instead of the default CIDR 10.0.0.0/24. Since I’ll be creating 2 VMs, I will configure another subnet below. 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.
Step 3: Browse to VNET for further configuration
If you did not select the option to add the tile to your Startboard, you can browse to the new VNET by clicking Browse and looking under “Recent”, or click Everything to find the new VNET.
Step 4: Configure additional subnets
Click the Subnets tile to configure the additional subnets.
Click Add subnet to do so.
Provide a meaningful name, choose your existing address space, and then specify the CIDR block. This will provision the additional subnet, which will still be able to communicate to other machines in the address space.
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 –> Everything, and then either find Windows Server in the Virtual Machines gallery, or search for “Windows Server”.
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. Simply select that option from the Windows Server image list, and click Create.
Step 2: Provide VM name and credentials
Provide a meaningful name, but make sure it is DNS-compatible – use letters, numbers, and hyphens. For this article, I’ve chosen the VM name “vm-md-demo2a”.
Step 3: Select pricing tier
For this article, I’ve selected A1, since I can run it all month without going over my credit limit.
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 4: Configure network
Under the Optional Configuration, select Network to select the virtual network and provide the Subnet. Be sure to select the VNET you previously created, then you’ll be able to select the desired subnet.
NOTE: The Azure portal will default to creating a VNET with the same name as your VM. Be sure to change it to the desired VNET.
Step 5: Select location
Finally, select the desired location. For this article, I’ve specified South Central US. In the previous version of the Azure Management portal, the VNET was already associated with a location, thus requiring you to select the location or the VNET. This new portal provides a bit more flexibility.
Step 6: Finish the wizard
Once you have configured the desired options, complete the wizard and Azure will begin provisioning the VM.
Step 7: 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 a 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”, after you browse to the VM.
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 portal, and click Settings.
From there, select Endpoints to begin.
Step 1: Add and specify type of endpoint
Click the Add button, and configure the endpoint settings.
NOTE: Unlike the previous version of the Azure management portal, there are no pre-set values to choose from. You will need to input the endpoint name, select the protocol, and specify the public and private ports. Also, for non-typical ports like Elasticsearch (9200), you may also have to configure the Windows Firewall to open up that specific port.
Step 2: 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-demo2a".
The "nslookup [hostname]" command provides the FQDN, which is the internal DNS name (http://vm-md-demo2a.vm-md-demo2a.j3.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-demo2" />
<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-demo2a.cloudapp.net)
- Using FQDN (i.e., http://vm-md-demo2a.vm-md-demo2a.j3.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 details for the first VM in the Azure portal, and modify the Access control list, 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-demo2a.cloudapp.net) should FAIL
- Using FQDN (i.e., http://vm-md-demo2a.vm-md-demo2a.j3.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/].