Incoming traffic TCP allowed in nsg and server firewall is getting blocked

maram 1 Reputation point
2020-05-05T11:36:38.453+00:00

I have enabled incoming TCP port 8080 via nsg config for my VM and the VM has firewalls enabled for the same port.

I can already see traffic is able to get in if source is in the same server.

But if source is external and access is via public IP the traffic is getting refused.

Can someone in azure support assist? Problem looks like it is in Azure net as localhost server access is fine.

my VM name is lamp01 and public ip 13.90.34.179

Azure Virtual Network
Azure Virtual Network
An Azure networking service that is used to provision private networks and optionally to connect to on-premises datacenters.
2,132 questions
0 comments No comments
{count} votes

10 answers

Sort by: Most helpful
  1. Christopher Hähnel 21 Reputation points
    2020-05-26T18:15:02.343+00:00

    Did you try to specify TCP Protocol, and Inbound from Inet? Maybe you already get a solution. Maybe you can tell us. Did you try to increase priority?

    Regards Chris

    0 comments No comments

  2. maram 1 Reputation point
    2020-05-30T09:59:57.107+00:00

    Did you try to specify TCP Protocol, and Inbound from Inet?

    Yes I have and I have provided a screenshot of my NSG settings: https://imgur.com/a/QPdxVHx

    Maybe you already get a solution.

    No. And there has not been any Azure support response.

    Maybe you can tell us. Did you try to increase priority?

    Yes. No effect.

    0 comments No comments

  3. TravisCragg-MSFT 5,676 Reputation points Microsoft Employee
    2020-06-09T04:01:43.67+00:00

    As you have already stated, the main places for traffic to be blocked are NSGs, or a firewall on the VM. If you have additional parts to your network like an Azure Firewall, Load Balancer, or custom routes that might alter traffic, it can get more complicated. If you simply have a VM with a Public IP address, and no User Defined Routes that could alter the traffic, then it is being blocked by an NSG, or by the VM itself.

    In situations like these, I like to double check everything. Lets start with NSGs:

    In the NSG you provided a screenshot of 'lamp01-nsg', port 8080 to 8090 is allowed on any protocol. An outbound rule is not needed with TCP connectivity, so this NSG is not blocking the traffic.

    NSGs can be applied to the NIC of a VM, and the subnet that the VM is in. Make sure that you do not also have an NSG on the subnet that is blocking the traffic.

    Next, we need to check the machine itself to make sure that it is listening on port 8080. I assume with the 'lamp' name of your NSG, that you are using a Linux VM. I like to use 'netstat -tl' to output listening ports on the OS. Make sure that your VM is listening on port 8080.

    Next, try to establish a connection. First, try from within the VM using CURL on the VM's private IP address. Next, try to connect from the same VNET via the private IP(If you have another VM running in the VNET), and last, try to connect from a computer outside the VNET via the public IP. Make sure you are connecting via port 8080. Depending upon where the failure occurs will give you additional information on where the block is occurring.

    You can also try a TCP ping test, I like to use PSPING to check for TCP connectivity on an address. If you are able to establish external TCP connectivity but unable to get a website, it is likely a configuration issue with the web hosting software on your VM.

    0 comments No comments

  4. maram 1 Reputation point
    2020-06-24T01:41:19.933+00:00

    As you have already stated, the main places for traffic to be blocked are NSGs, or a firewall on the VM. If you have additional parts to your network like an Azure Firewall, Load Balancer, or custom routes that might alter traffic, it can get more complicated. If you simply have a VM with a Public IP address, and no User Defined Routes that could alter the traffic, then it is being blocked by an NSG, or by the VM itself.

    Ok

    In situations like these, I like to double check everything. Lets start with NSGs:

    Ok

    In the NSG you provided a screenshot of 'lamp01-nsg', port 8080 to 8090 is allowed on any protocol. An outbound rule is not needed with TCP connectivity, so this NSG is not blocking the traffic.

    Ok

    NSGs can be applied to the NIC of a VM, and the subnet that the VM is in. Make sure that you do not also have an NSG on the subnet that is blocking the traffic.

    I have not setup any additional NSGs

    Next, we need to check the machine itself to make sure that it is listening on port 8080. I assume with the 'lamp' name of your NSG, that you are using a Linux VM. I like to use 'netstat -tl' to output listening ports on the OS. Make sure that your VM is listening on port 8080.

    Yes it is. I have tested by using a local app to connect.

    Next, try to establish a connection. First, try from within the VM using CURL on the VM's private IP address. Next, try to connect from the same VNET via the private IP(If you have another VM running in the VNET), and last, try to connect from a computer outside the VNET via the public IP. Make sure you are connecting via port 8080. Depending upon where the failure occurs will give you additional information on where the block is occurring.

    I am able to connect to the machine via port 80 from a public source only port 8080 is not working.

    You can also try a TCP ping test, I like to use PSPING to check for TCP connectivity on an address. If you are able to establish external TCP connectivity but unable to get a website, it is likely a configuration issue with the web hosting software on your VM.

    From all information available, the issue seems to be with NSG rules and network of Azure. Everything else is correct but the NSG is not implementing the allow port 8080 rule correctly. Hopefully you can investigate this possibility.

    0 comments No comments

  5. Abish, Kanat 1 Reputation point
    2021-01-11T08:59:23.927+00:00

    Hi! Try to run Network Watcher, IP Flow Verify blade. ![55226-networkwatcher.png][1] [1]: /api/attachments/55226-networkwatcher.png?platform=QnA

    0 comments No comments