8

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:

enter image description here

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:

enter image description here

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.

Nikolaj Dam Larsen
  • 5,455
  • 4
  • 32
  • 45
  • 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 – Michael B Oct 14 '15 at 19:32
  • 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. – Nikolaj Dam Larsen Oct 14 '15 at 20:13
  • 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!) – Michael B Oct 14 '15 at 20:21
  • 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. – Nikolaj Dam Larsen Oct 14 '15 at 21:12
  • 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? – Michael B Oct 14 '15 at 21:17
  • 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. – Nikolaj Dam Larsen Oct 14 '15 at 22:38
  • 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. – RenniePet Apr 07 '17 at 19:48

2 Answers2

12

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.

enter image description here

Dan-Claudiu Gavril
  • 1,206
  • 9
  • 6
8

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.

Eric Spooner
  • 96
  • 2
  • If you see the second image it is Any/Any – Michael B Oct 15 '15 at 15:29
  • 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. – Eric Spooner Oct 15 '15 at 20:16
  • 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. – Nikolaj Dam Larsen Oct 15 '15 at 20:39
  • Oh man, I just spent 20 minutes on this... I'd put 80 in the Source Port field. Thank you! :) – Danny Tuppeny Mar 11 '16 at 14:48