Connection timeout port 80 on new Azure VM with NSG rules configured

Question

I just created a new Ubuntu 14.04 virtual machine in Microsoft Azure using the (recommended) resource manager deployment model. The following screenshots show the deployment configuration and the resulting resources:

Once it was deployed, I accessed the VM using SSH through the public IP, logged in and installed nginx. I left it with the default configuration and did a 'curl localhost' to ensure the webserver was running.

Then I went to the Network Security Group resource and added an Allow rule for port 80 to the Inbound rules:

I then opened a browser and tried to request the public IP associated with the NIC and got a connection timeout.

Edit: I can get access by disassociating the NSG from the NIC, but if I re-associate it, I will get blocked again within a few minutes.

I have tried using the same process to set up a Windows Server VM, with IIS, but I'm getting the same result.

What am I missing here?

I get no errors when doing the same setup using the classic deployment model, this only occurs when trying the recommended resource manager model.

Westberry

I've just created a new Win2k3R2 VM (a linux one took too much thinking) using all of the default configurations, added the web server role once it was booted, tested from localhost and it worked, added an any/any/TCP/80 rule and it connected straight through! Could you add an arbitrary port, run nc on it, and telnet to it, see what that does – Benue

No response from neither nc nor telnet. In both cases I get a timeout on both port 80 and the arbitrary port I opened (40000). If I run nc (and telnet) on port 22 (SSH) I get a response though. – Westberry

That is very odd! What happens if you delete the Security Group from the interface all together (go to SG > NIC and change association to none) - Sure you're not doing anything nuts like a typo in the IP Address (we've all been there!) – Benue

If I go and disassociate the NSG, nothing changes. I'm still blocked out even though Azure Portal show that the NSG has no associations what so ever. If I then go ahead and delete it completely I finally get a response on other ports than 22. – Westberry

Well that's a step closer at least! you know where the problem is now. (it might be worth a support call) What if you create a new SG now? – Benue

Alright, disassociating the NSG is actually enough to grant access - I were probably just too impatient to wait for the change to mitigate to the server. I've tried re-associating it the NSG, but after a few minutes it's blocked again. – Westberry

I came to this posting via a Googling of "azure inbound security rule not working". In my case the problem turned out to be me stupidly thinking that priority 1010 was higher than priority 1000. So my rule that denied the general case was executed instead of my rule that allowed the specific case. – Zeitgeist

Answer 1

What is your source port on your NSG? Did you leave it Any/*? If not you are limiting yourself to traffic coming only from that one port.

Oven

If you see the second image it is Any/Any – Benue

You are correct, however in Azure the screenshots don't show Source port range. On the Rule blade they only list the IP Address which in this case Source IP is Any. Source Port is a rule that isn't displayed on this blade. – Oven

This was in fact my issue. I had set port 80 as my source port range. It was the Microsoft Azure support team that pointed that out for me. I've marked your answer as the correct one. – Westberry

Oh man, I just spent 20 minutes on this... I'd put 80 in the Source Port field. Thank you! :) – Bryon

Answer 2

For the ones that still struggle with the inbound rules on the new Portal Azure, you need to set up the Network Security Group (NSG) to:

• allow connections from (source):

any sources

and

* - for the source port range (extremely important as it may seem normal to set 80 or 443 - which is not correct)

• destination:

any

and

80 - as the destination port range (or the port that your webserver is listening to - it could be also 8080 or other)

The same goes for other ports like the 443 for the https connections.

Documentary

I prefer this answer, it's much clearer than the accepted one. – Rampant

This helped a lot but I had to change the Protocol to TCP from Any to finally get my nginx reverse proxy to work. – Frail