0
votes

I have 2 VMs (CentOS), running in the same VNET (and subnet). They both have a static public IP.

I have a Network Security Group which defines inbound and outbound rules, attached to both NICs as well as to the VNET.

One of the inbound rules is the default-allow-ssh rule. All good so far, using SSH, I can access both VMs from outside Azure, from my own computer from anywhere on the web.

On 1 of the VMs I'm running a webserver.

Exposing the webserver on port 80 and adding a new NSG inbound security rule on port 80 (src: any, src port range: *, dest: any, port: 80, protocol: any) allows met to access the webserver from anywhere: from my pc from anywhere on the web, from my other VM within Azure, so just as I was expecting.

Now when I change the port of the webserver from 80 to for example 7181:

I can still do "curl http://[PUBLIC_IP]:7181" from the server I'm hosting the webserver on AS WELL AS from the other CentOS server sitting in the same VNET (subnet) BUT no longer from my pc or any pc outside the Azure realm (the web).

Firewalld is not running on the webserver, nor do I have iptables set, only NSG rules define inbound and outbound traffic.

The host of the webserver is always accessible from anywhere outside Azure, using ssh. The webservice itself, on port 80, including a proper inbound NSG rule, also works just fine from anywhere out- and inside Azure. The custom port, configured identically as port 80 or 22 in the NSG (except for the port number of course), is accessible only from inside the same VNET.

Anyone?

(the error I get is the well-known: ERR_CONNECTION_REFUSED)

NSG screenshot: enter image description here

3
If possible, copy-paste / screenshot your NSGsFabrizio Accatino
Screenshot added, I have 1 NSG, which is attached to the VNET, VNET's subnet and the webserver's vNIC. (I started of with only 1 port per rule, last thing I tried was 3 ports, comma separated).Dieter Bauwens
1. you cannot attach nsg to vnet. 2. why attach same nsg to subnet and to nic? remove the nic attachment4c74356b41
indeed, it's attached to the subnet, not the vnet itself, in the meantime I removed the NSG from the network interface, the result is still the sameDieter Bauwens
Hi, can you check on port 81 (instead of 7181) by defining it in NSG. Please check, I sense something. I will tell you if that solve your problem.erTugRul

3 Answers

1
votes

Reboot of the VM instance solved the problem. So it looks like adding/updating NSG rules on-the-fly does not affect running instances immediately or something else takes a lot of time sync and to take effect. I must have forgotten about my early Windows days, where reboots were pretty standard when changing configuration or installing new things. Anyway, thank you all for your time and effort on this question.

0
votes

Asking the obious: Have you added a rule for Port 7181 in the NSG?

My tests says: This kind of Error comes from NSG.

A CURL from within the Network might lead to wrong opinions. You should trace the route when connection the IP on Port 7181.

0
votes

Create separate rules for each port you want to open. As far as I know you cannot specify a list of ports in "port" field. Only single port, port range or *.

FYI: the connection from other machine in VNET is working because there is "AllowVnetInBound" rule.