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
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.
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.
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.
Related
I am unable to access an azure Ubuntu VM's web app on port 8080. The VM is linked to a Virtual Network, where the network security group has inbount rules configured for 8080, and the ubuntu firewall has been disabled(ufw).
Here are the details:
The VM :
The allowed rules for port 8080 in the network security group :
The firewall has been disabled on the vm :
Any request to http://publicipaddress:8080/service does not work :
Please advise what else is required to make it work.
The request however works if an inbound rule of allow-all (*) is added instead of a particular port (8080), which defeats the purpose of security.
Thanks, Cheers
-Gary
From your description, here are some possible reasons:
Your application or service is not listening on the correct port 8080 for Foreign Address 0.0.0.0:*. You could try to run the command sudo netstat -alpn | grep LISTEN on the Azure VM to validate it. If not, you could find what's real IP of the application consumed.
Your Azure VM is associated with some other NSGs. You could check if there is an extra subnet level or network interface level from virtual machine --- networking.
Try to remove the custom Outbound security rules in your NSG.
Let me know if you need further help.
Thanks Nancy,
The output of the netstat command is :
It appears that the port 8080 is listening to all addresses (but maybe on IPv6?)
The VM and the NSG are part of the same group :
the resource group:
Did remove the outgoing rules, but it still does'nt work :(.
Not sure what else am i missing.
It was my mistake of wrongly configuring the nsg ingress to match the port number (eg : 8080) instead of matching the source port to *.
The protocol - source and destination host:port combination where therefore wrongly setup.
It all works now after correcting it.
I have an Azure NSG that has port 3128 open. I need to be able to block all connection to the port unless the connection comes from within the VNET. How to I achieve this? Every time I try to set source to Virtual Network I am still able to access it from external IPs.
By default NSG allows all traffic within VNET, you can see two rules AllowVnetInBound and AllowVnetOutBound, try to not configure anything to block 3128 port and check if you have access to 3128 from a VM within VNET. You can also try to configure two rules based on source service tags, one for internet which blocks port 3128 and the other one virtual network which allows port 3128.
What can I do to fix this Advisory message?
The VM this relates to is a webserver, which sits behind an Azure LoadBalancer. The NSG rule that is causing this (only 1 'not default rule' ) is:
Type: Allow
Source: Service Tag - Internet, source port range = *
Destination: ASG for this VM, destination port 80,443, protocol tcp
If I remove this rule, the message disappears (after some hours) but than the internet web traffic can not reach the VM anymore.
Should I ignore the Azure Advisory message? Or am I overlooking something? I was looking forward to getting this nice and tidy, AND have a 'satisfied' advisory state.
You can run your webserver on the VMs on different ports than 80 and 443. The load balancer can translate between port 80/443 on your public IP and whatever port you choose inside the VMs. Since Load Balancers are a fairly simple service, this is probably your only option.
As an alternative, you could try Application Gateway instead of your load balancer. It should act as the reverse proxy you need. Be aware that it is a bit more costly than the load balancer, but it also has a lot more features.
I see that your VM is behind an Azure LoadBalancer. So, the network flow might be similar to :
Then, your web server should not be public to the internet. It should only be accessible from the loadbalancer. You can set the source service tag to AzureLoadBalancer. For more information about service tags, you may check the official documentation: Service tags
Update:
By further researching, the AzureLoadBalancer service tag in NSG rule is used to allow Azure health probes. Actually, there is a default rule for allowing load balancer to probe to endpoints.
So, the suggestions are:
You should not assign public IPs to each instances. In this way, your backends can only be accessed by private IPs. In other words, clients can only access your web via load banlacer.
Add NSG inbound rules with 80 and 443 ports for web service. And 22 or 3389 port for remote management.
In this case, your servers should be secure now. If there are still any warnings, I think you may ignore them. The Azure system may just see that you opened 80 and 443 ports to public. However, your instances do not have public IP.
Hope the above would be helpful to you.
I am primarily an AWS developer, and testing a few things out in Azure. I have spun up a Linux VM with authentication through user/pw and am having trouble SSHing unless I allow all sources in my NSG.
In AWS, I would simply create an inbound rule on my SG allowing for port 22 traffic on myip/32. I thought perhaps it's because I had IpV6 enabled, however even after I disabled it I am out of luck.
Other debugging steps I've took is to add larger CIDRs in my NSG such as 172.0.0.0/8 which should be covering my local machine.. however still a time-out. I'm allowing all ports and all protocols, only trying to filter the source IP.
Thanks!
It is the same process with the NSG, but from experience some ISP and big companies NAT there IP so much that the IP you get from whatmyip site is not the actual communication IP.
Example:
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.
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.
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.