One of the most popular uses for Azure Virtual Machines (VMs) is hosting Web content. For any Web server to work you need to explicitly allow communication to your VM as by default all ports (apart from RDP and/or SSH) are hidden. This is done for two reasons: one – security, the traffic you do not explicitly expect is not even reaching your VM, and two – performance, because this traffic is not reaching your VM, the VM does not need to waste CPU cycles on filtering said traffic using OS’es built-in firewall.
All of this goes to show there are two main steps one needs to take in order to facilitate connectivity: one – allow traffic to the VM, two – allow that traffic in through the VM’s built-in firewall. The latter depends on your operating system so we will not go into details on how to set up your firewall. We will focus instead on the Azure side of things and on allowing the traffic to the VM.
Up until late 2015 there was one deployment model for Azure VMs (now called Classic Deployment Model) while the New Portal and the new Azure Resource Manager Deployment Model were still in preview. In the context of managing traffic, one of the important differences between the models is the fact that with the Classic Deployment Model (CDM) VMs were usually grouped into a Cloud Service which provided a common publicly available IP and in order to reach a particular VM on a particular port one had to create an Endpoint – effectively a port forwarding rule from the Cloud’s public IP/port to the private port of a given VM. With the Azure Resource Manager (ARM) model, in the simplest case, a VM obtains its own, public IP along with a Network Security Group which contains a set of network/firewall rules it can share with other VMs and that filter network traffic even before it reaches any given VM (and thus saving those CPU cycles as well). For a more detailed explanation of the differences, please follow this link.
Having two deployment models and two versions of Azure Portal may be a little confusing at first so that is why we will go over all three available possibilities: CDM VMs in the Classic Portal, CDM VMs in the New Portal, and ARM VMs in the New Portal. And yes, there are only three cases here as ARM VMs cannot be managed in the Classic Portal.
For maximum clarity we will only focus on the absolutely necessary settings whilst leaving all the optional settings default.
Classic Deployment Model VMs in the Classic Portal
Navigate to the Classic Portal’s URL at: https://manage.windowsazure.com/ and, after logging in, select your desired VM from the panel on your left. Then continue on to the “Endpoints” tab and click the “Add” button below:
This will open a new popup allowing you to create a new Endpoint for either a single VM or to add this VM to a balanced set. The latter is used when you have a bunch of VMs and you want to load balance traffic on the same port between them. For simplicity we leave the “Stand-alone” option selected and click continue:
Now you can choose one of the predefined services with their respective port or create a fully custom one:
Your Endpoint for port 80 is now ready and should be listed in the list of Endpoints for your VM:
Classic Deployment Model: VMs in the New Portal
Very similar is the sequence of events in the New Portal which is accessible under: https://portal.azure.com . Select “Virtual Machines (classic)” from the left-hand-side menu, then your desired VM and then the Settings:
From the Settings you need to choose Endpoints and click the “Add” button:
A new blade will open allowing a very similar configuration:
This time we added HTTPS port for a change, and it is immediately visible in the Endpoints list:
Azure Resource Manager: VMs in the New Portal
This time the approach is somewhat different. We mentioned that the Network Security Groups (NSG) take the place of the classical Endpoints. In the ARM Model providing a name of the NSG is the part of VM creation but if you have forgotten the name by now, you can check it easily by selecting the “Virtual Machines” from the left-hand-side menu, then choosing your desired VM (mind that this list will not contain VMs created in the CDM nor vice versa) then click on the “All Settings” and highlight “Network Interfaces”:
In particular we are now looking for the name of the NSG associated with this VM’s network interface:
Take a note of this name and go back to the most left-hand-side menu, choosing “All Resources”. You can filter them using the text field provided and typing the name of your NSG. In our case it was “twanetsecgrp1”:
In particular we are looking for the “Inbound Security Rules” as found in the “All Settings”. Click “Add” to create a new rule:
A new blade opens allowing you to name the new rule and set the protocol and ports among others:
Confirm your settings with the “OK” button and the new rule should be now visible in the list:
Please note that the same rule will apply to all the VMs using the same NSG, which means you can reuse it for all your Web servers for example, while most likely choosing a different one for all your SQL machines.
You can now connect directly to your VM using port 80 and the public IP provided in its Dashboard. Now you only need to allow the traffic through the VM’s built-in firewall.
If you’d like to know more I would highly recommend the article titled: Understanding Resource Manager deployment and classic deployment as well as Azure Compute, Network, and Storage Providers under the Azure Resource Manager.