We are experiencing an issue where network traffic is reaching our Virtual Machine, even though our Network Security Group (NSG) is configured to block this traffic. For example, traffic on port 80 is being logged by UFW on the VM, despite the NSG rules explicitly denying this port. Configuration Details: NSG rules are set to deny all incoming traffic on port 80. UFW on the VM confirms that traffic on port 80 is being blocked, but it still shows incoming packets. Issue: We observe incoming traffic on port 80 in the VM logs. This occurs even when the NSG configurations should be blocking it. This raises questions about the efficiency of the NSG --Why is traffic reaching the VM despite the NSG rules?

Unexpected Network Traffic Reaching VM Despite NSG Configuration in Azure

nma 5

We are experiencing an issue where network traffic is reaching our Virtual Machine, even though our Network Security Group (NSG) is configured to block this traffic. For example, traffic on port 80 is being logged by UFW on the VM, despite the NSG rules explicitly denying this port.
Configuration Details:

NSG rules are set to deny all incoming traffic on port 80.
UFW on the VM confirms that traffic on port 80 is being blocked, but it still shows incoming packets. Issue:
- We observe incoming traffic on port 80 in the VM logs.
- This occurs even when the NSG configurations should be blocking it.
- This raises questions about the efficiency of the NSG

--Why is traffic reaching the VM despite the NSG rules?

Sai Prasanna Sinde 3,920 Reputation points Microsoft Vendor

2025-02-13T08:53:16.74+00:00
Hi @nma

Welcome to the Microsoft Q&A Platform! Thank you for asking your question here.

Please go through the below troubleshooting steps:

First make sure that the NSG is correctly associated with the VM's network interface or subnet. You can verify this in the Azure portal by navigating to the VM's networking settings or the subnet's associated NSGs and diagnose the network security rules by using NSG Diagnostic in Network watcher.

Next, verify if there are any other NSGs applied to the VM or subnet that might be allowing the traffic. Check the priority of the NSG rules to make sure that the deny rule for port 80 has a higher priority than any allow rules.

If an allow rule has a higher priority, it will override the deny rule, allowing traffic on port 80. When creating NSG rules, it's crucial to space the priority numbers to allow for future rule additions without requiring renumbering of existing rules.

Examine the NSG for any application rules or service tags that might be allowing the traffic. Application rules allow traffic based on predefined application types, while service tags represent groups of IP address prefixes for Azure services. If any of these rules or tags allow traffic on port 80, it will bypass the deny rule.

Determine if there are any virtual network appliances or other network devices that might be bypassing the NSG. Some appliances might have their own routing or filtering mechanisms that could override NSG rules Additionally, check for UDRs that might be overriding traffic destined for private endpoints and potentially bypassing NSG rules. UDRs provide a way to customize network traffic routing, and if misconfigured, they can interfere with NSG functionality.

Analyze network logs for insights into the traffic flow and identify the source of the incoming traffic. Azure Network Watcher provides tools like NSG flow logs, which capture information about traffic flowing through an NSG, and IP flow verify, which helps you determine whether a specific NSG rule is blocking traffic. You can also use Connection Troubleshoot to diagnose connectivity issues between a VM and another endpoint.

To isolate whether UFW is causing any conflicts with the NSG rules, temporarily disable it on the VM If the traffic stops after disabling UFW, review your UFW rules to ensure they align with your NSG configuration.

Otherwise temporarily remove all other NSGs and ASGs (if possible) to isolate the issue. Create a single, simple "deny all on port 80" rule at the network interface level. This will help you determine if the problem is with the NSG itself or a conflict.

Kindly let us know if the above helps or you need further assistance on this issue.
nma 5 Reputation points

2025-02-13T19:00:09.2333333+00:00

Hi,

Thank you for your detailed response.

I have verified that the only Network Security Group is the one applied directly to the VM, and no other NSGs are present at the subnet level. The NSG is configured to allow only ports 443 and 8443, with all other traffic implicitly denied by default.
besides the NSG diagnostics confirm that DenyAllInBound is denied

Additionally, I have Packetbeat running inside the VM, which shows packets arriving on port 80, but they are being blocked by UFW. This traffic should not reach the VM in the first place, as the NSG default deny rule should have blocked it.

Also please note that it is impossible for me to send requests on this port 80 unless I whitelist my IP, as it is blocked by the NSG. However, I am seeing successful attempts to bypass the NSG from malicious IPs.

I appreciate your help in understanding this behavior.

Thank you.
Vallepu Venkateswarlu 475 Reputation points Microsoft Vendor

2025-02-17T12:10:03.9033333+00:00
Hi @nma

I can see that the NSG is still allowing traffic on port 80, even though a Deny rule has been created. This is due to the following condition:

If an NSG rule is created with a deny action, the source is the internet or IP address. If the source is set to "Internet," traffic within the same VNet will still be allowed by default because of the AllowVNetInBound rule at priority 65000.

To block port 80 traffic from any source, explicitly set the Deny rule's source to "Any" from all sources or "VirtualNetwork" to ensure traffic within the same VNet. Follow the Ms Doc for more details.

You can check the source of incoming traffic to your virtual machine using NSG Flow Logs. These logs provide detailed insights into network traffic, including source and destination IPs, ports, and whether the traffic was allowed or denied by the NSG rules. Follow the MS Doc about NSG flow log creation.

I hope this helps to resolve your query.

If the above is unclear and/or you are unsure about something, add a comment below.
Vallepu Venkateswarlu 475 Reputation points Microsoft Vendor

2025-02-18T08:46:38.9066667+00:00

Hi @@******@vneuron.com

I just wanted to follow up and see if you had a chance to review my response in the comment to your question. Please let us know if it was helpful, and feel free to reach out if you have any further queries.
Vallepu Venkateswarlu 475 Reputation points Microsoft Vendor

2025-02-19T07:10:20.6166667+00:00

Hi @@******@vneuron.com

I just wanted to follow up and see if you had a chance to review my response in the comment to your question. Please let us know if it was helpful, and feel free to reach out if you have any further queries.
KapilAnanth-MSFT 48,761 Reputation points Microsoft Employee

2025-02-19T13:14:43.2533333+00:00
@******@vneuron.com ,

Greetings.

I see Vallepu Venkateswarlu has explained that virtual machines in the same subnet can communicate based on a default NSG rule allowing intra-subnet traffic.

This is because the default rule of AllowVNetInBound takes precedence over DenyAllInbound and hence the Intra-Subnet traffic is allowed.

I also see you mentioned "successful attempts to bypass the NSG from malicious IPs"

Can you please share the list of source IP(s)

Is this being simulated by you?

Or some random IP(s) you are considering to be malicious?

Next Steps:

You mentioned UFW is logging traffic on Port 80

Can you please share what are the source IPs here? Are they from

private IPs of the VMs from same subnet/VNET

or Public IPs

or 168.63.129.16 (Wireserver) IP?

If they are from Private IPs,

Then you have to create a custom NSG rule and explicitly block the traffic

If they are from 168.63.129.16 (Wireserver) IP,

Then I would recommend you let it be

As certain health checks from platform are done from 168.63.129.16

If they are from Public IP,

Ideally, this should not be happening with default NSG rules.

Can you confirm if this VM is behind an Azure Load Balancer or not?

Can you run the IP flow verify or NSG diagnostics with source IP as the packet logged by UFW (This is important to identify which rule is allowing the packets, please do not test with a random public IP)

Cheers,

Kapil
nma 5 Reputation points

2025-02-19T14:15:16.88+00:00
Hello ,
Thank you for your detailed insights. I appreciate your time in reviewing this.

My VM does not have an NSG rule explicitly allowing traffic on port 80.

This means the observed traffic is not a result of a misconfigured NSG rule.

Source of Traffic (Public IPs):

The incoming traffic is from public IP addresses, not from private VMs within the same subnet/VNet.

These IPs were detected and flagged as malicious by my threat intelligence tool. Examples include:

64.62.197.14

64.62.197.161

184.105.247.235

65.49.1.100

This confirms that the traffic is not originating from Azure's WireServer (168.63.129.16).

2.Detection and Logging:

Our SIEM has recorded multiple network events showing connections to port 80 from these malicious IPs.

UFW logs also confirm blocking attempts, e.g.: [UFW BLOCK] IN=eth0 O= SRC=216.218.206.104 DST=#.#.#.# LEN=131 TOS=0x00 PREC=0x00 TTL=234 ID=54321 PROTO=TCP SPT=52966 DPT=80 WINDOW=65535 RES=0x00 ACK PSH URGP=0

3. Traffic Simulation:

These are real-world attack attempts, not simulated traffic.

I cannot reproduce them as they originate from external malicious sources.

my VM is not running behind an azure load balancer
KapilAnanth-MSFT 48,761 Reputation points Microsoft Employee

2025-02-19T16:18:15.6733333+00:00
@nma ,

You're welcome. Thanks for sharing the information.

As next steps,

Can you try to replicate this using one your Public IPs

You can check what's your Public IP in https://ifconfig.me/ and try to initiate a TCP Connection on Port 80

Either using Telnet or Test-NetConnection from your local machine

Test-NetConnection -ComputerName "<Your VM Public IP>" -Port 80

If this traffic is logged either by your SIEM or your UFW, then we can be sure that the issue is with NSGs irrespective of the source IPs

Can you please share the results of either IP flow verify or NSG diagnostics with one of the IPs you listed and also with your Public IP

Does this VM have multiple NICs? (which maybe part of a different subnet in the same VNET with different NSG)

Cheers,

Kapil
nma 5 Reputation points

2025-02-19T16:56:36.54+00:00
Thank you @KapilAnanth-MSFT for your detailed guidance.

I have tested according to your suggestions:

Test with Public IP:

I attempted to initiate a TCP connection on port 80 from my own public IP using Telnet from my local machine. I was unable to reach the VM on port 80. No traffic was logged on either the SIEM or UFW confirming that the connection was blocked as expected.

IP Flow Verify & NSG Diagnostics:

When running the IP Flow Verify, the result is always "Access Denied"/DenyAllInbound/ DenyAllInbound, whether testing with my own IP or with the other IPs detected.

VM NIC Configuration:

The VM has only a single NIC and does not appear to be part of any additional subnets.
nma 5 Reputation points

2025-02-19T16:59:44.96+00:00

Thank you @KapilAnanth-MSFT for your detailed guidance.
KapilAnanth-MSFT 48,761 Reputation points Microsoft Employee

2025-02-20T04:21:13.57+00:00

@nma , This is strange, especially when the IP Flow Verify & NSG Diagnostics are not allowing the malicious IPs while your local OS logs it.

In this case, to troubleshoot further, we will need a specialized 1:1 session, where a support engineer can check the backend logs to pinpoint the issue.

If you have a support plan you may file a support ticket, else please do let us know, we will try and help you get a one-time free technical support.

Cheers,

Kapil
nma 5 Reputation points

2025-02-20T12:37:32.4333333+00:00

@KapilAnanth-MSFT I agree that a deeper investigation is needed. I currently don’t have a support plan ... could you assist in arranging the one-time free technical support session? Please let me know the next steps for scheduling it..
KapilAnanth-MSFT 48,761 Reputation points Microsoft Employee

2025-02-20T13:44:05.14+00:00

@nma ,

I have initiated a private message, with the next steps.

Cheers,

Kapil
VIVEK DWIVEDI 105 Reputation points Microsoft Employee

2025-02-21T11:24:34.6033333+00:00
Hi @nma,

That might be some health check traffic.

Would you be able to share the following:

NSG inbound rules screenshot and
2.Logs from VM which has source IP and port information for port 80.

Also, if you can attach effective security rule (Azure Portal-->Nic which is associated to VM-->Help->Effective Security Rules) would be also helpful.

If you see the traffic from 168.63.129.16 that could be related to VM's health but once you share more information, I can guide you about it.

1 answer

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more

Share via

Unexpected Network Traffic Reaching VM Despite NSG Configuration in Azure

1 answer

Your answer