6

I created a new Windows Server 2012 R2 virtual machine in Microsoft Azure. Among other things installed on that virtual machine is a web site hosted in IIS, but I can't seem to get IIS on that server to respond externally.

I am using the Resource Manager, so on my Public IP Address, I configured the DNS name (from Configuration), so the full DNS name is myapp.eastus2.cloudapp.azure.com where myapp is my actual app.

Then, on my Network Security Group, I added an Inbound security rule with the following settings:

  • Name: HTTP
  • Priority: 1020 (there are no conflicting rules higher in priority)
  • Source: Any
  • Protocol: Any
  • Source port range: * (it was 80, but changed it after reading this post: Connection timeout port 80 on new Azure VM with NSG rules configured, but I would still think 80 should work)
  • Destination: Any
  • Destination port range: 80
  • Action: Allow

It doesn't matter if I try to access it by DNS name or the IP directly, I just get a timeout error. I can navigate to the web site on the local machine using either the machine name (e.g. http://myapp) or localhost. I also cannot navigate to the web site from the local machine using the full name (e.g. http://myapp.eastus2.cloudapp.azure.com).

Moreover, I'm really at a loss as to where to even troubleshoot this. Clicking on the Audit Logs only seems to show actual edits to the item (makes sense) and I did turn on Diagnostics for the NSG (like in this article: https://github.com/Azure/azure-content/blob/master/articles/virtual-network/virtual-network-nsg-manage-log.md), but it doesn't seem to be logging anything when I hit the endpoint (there are no new blobs in my storage account).

Anyone have any ideas?

Community
  • 1
  • 1
Paul Haag
  • 271
  • 3
  • 10
  • 2
    Have you tried detaching the security group, so there isn't one defined and trying like that? If it still doesn't work you know its something else, if it does, you know its the SG. It might be useful if you could attach a picture of your security group rules too. – Michael B Apr 04 '16 at 23:44
  • I'll just mention that you're wrong in thinking the source port should be 80. The source port is the network port number at the other end of the connection, it is typically some random number. – RenniePet Apr 07 '17 at 05:08
  • By the way, 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:46
  • Not sure what the right answer is, but associating/dissociating the NSG worked before, but now that's also not working... – toraritte Aug 13 '21 at 22:45

1 Answers1

11

It definitely was the NSG. Thanks to Michael B for suggesting I disassociate it. When I did that, everything started working. However, that didn't answer the underlying issue. I found, eventually, that deleting the rule and recreating it with exactly the same values worked. Go figure.

Paul Haag
  • 271
  • 3
  • 10
  • 3
    Disassociating and associating the network security group against the network interface did the trick for me too. I think my issue was due to editing the existing NSG, instead of creating a new one (as per the documentation). So it looks like you need to "associate" for it to pick up the new rules. – duFF Jun 15 '17 at 13:44
  • It didn't work for me. My NSG is associated at the subnet and not at NIC level – Brikesh Kumar Feb 19 '23 at 17:08