1

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

Dieter Bauwens
  • 41
  • 1
  • 8
  • If possible, copy-paste / screenshot your NSGs – Fabrizio Accatino Apr 06 '18 at 07:44
  • 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 Apr 06 '18 at 08:10
  • 1. you cannot attach nsg to vnet. 2. why attach same nsg to subnet and to nic? remove the nic attachment – 4c74356b41 Apr 06 '18 at 08:11
  • 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 same – Dieter Bauwens Apr 06 '18 at 09:01
  • 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 Apr 06 '18 at 09:54
  • I tested port 81, same error: connection refused; I even added a rule with highest prio, which allows any port from any source using any protocol to any destination; still the same problem – Dieter Bauwens Apr 06 '18 at 12:49

3 Answers3

2

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.

Dieter Bauwens
  • 41
  • 1
  • 8
  • This is very very strange. NSG rules do not require reboots or other actions on VM to be effective. – Fabrizio Accatino Apr 08 '18 at 05:30
  • I agree with you. But I'm witnessing the exact same behaviour on Amazon EC2, where Security Group changes (new rules/updated rules) do not take immediate effect and where a reboot of the instance is required or at least a considerable long time is needed to see the changes being in place. – Dieter Bauwens Apr 09 '18 at 07:05
0

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.

TheShadow
  • 581
  • 4
  • 10
  • yes, a dedicated rule was added each time for the respective ports I tested; looks like traceroute is neither giving me useful info: I get * * * for all hops when executed on the Azure network (the subnet my to hosts live in) – Dieter Bauwens Apr 06 '18 at 09:09
  • my rule now is: source: any, port range: *, destination: any, port: 80,7180,7181 protocol: any - exposing my webserver on all 3 ports subsequently only works from the outside for port 80, the 2 other ports result in the connection refused error, connecting from another server to all 3 ports from within the same vnet (from within Azure itself) works fine – Dieter Bauwens Apr 06 '18 at 09:24
0

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.

Fabrizio Accatino
  • 2,284
  • 20
  • 24
  • thank you for your tip, unfortunately it did not work out, I even added a rule (highest prio) which opens any port for any protocol for any source, still port 80 OK, as of the moment I run the webserver on another port (I also tested port 81 as indicated in a comment above) I get connection refused – Dieter Bauwens Apr 06 '18 at 12:45
  • also, when creating an NSG security rul, the destination port ranges textbox tells me that you can provide a single port; a port range such as 100-200; or a comma-separated list of single ports and/or port-ranges, suh as 80,124-65000 – Dieter Bauwens Apr 06 '18 at 12:47