NSG Connectivity Issue: Inbound Rules Allow Traffic but Connection Fails

Question

NSG Connectivity Issue: Inbound Rules Allow Traffic but Connection Fails

rain purple 340

Hello, support team:

  Thanks for your professional support, two VMs can communicate now, but face another issue.

Describe the Issue: We are experiencing connectivity issues between two VMs located in a peering subnet. Although the inbound rules allow traffic on ports 80 and 3389, the connection is being denied.

![VM connect feedback](/api/attachments/e5cbda31-8d6a-46ba-853f-d06b90fcc6e5?platform=QnA)

VM Details:

    **VM**: Spot VM located in Location 01

             Firewall has allowed inbound rule with ICMP,RDP,80,443 port.

   **VM02**: Spot VM located in Location 02

              Firewall has allowed inbound rule with ICMP,RDP,80,443 port.

Network Configuration:

    **VNet**: Peering is configured between the subnets.

     **NSG:** The NSG is bound to the subnet, not the NIC.

NSG Inbound Rule:

     Basic rule allowing traffic from any to any through RDP, 80, 443 ports.

NSG Outbound Rule:

      Allow from VNet to VNet through RDP, 80, 443 ports.

Issue:

     Connectivity test from Network Watcher shows connection is reachable but faces inbound rule deny.

     Changing NSG to connect with NIC results in the same feedback.

Additional Context:

        We are using the default Azure Basic Firewall and Load Balancer.

Questions:

  1.  How can I get the inbound rule to allow when two VMs communicate?

   2.  What kind of service or application needs this inbound rule deny?

   3. What kind of service or application/situation needs this inbound rule allow?

Thanks, have a good weekend.

User from Azure portal

0 comments

1 answer

Your answer

Answer 1

The most likely cause is that traffic is allowed on one NSG scope but denied on the other, or an inbound allow rule is being shadowed by a higher-priority deny rule.

For peered VNet VM-to-VM traffic, the packet must pass both:

the subnet-level NSG
the NIC-level NSG if one is attached

Even if one side allows port 80 or 3389, the connection still fails if the other scope denies it. Azure also has a default inbound deny rule, DenyAllInbound priority 65500, so traffic is blocked unless there is an explicit allow rule with a lower priority number.

Recommended checks:

In Azure portal, open the destination VM.
Go to Networking or Network settings.
Open the VM’s network interface and check Effective security rules.
Verify whether port 80 or 3389 inbound is denied, and identify the exact rule name.
Check the subnet NSG and the NIC NSG separately.
Confirm that the inbound allow rule has a lower priority number than any matching deny rule.
Confirm the source in the allow rule matches the real traffic source. For peered VNet traffic, verify that the rule uses the correct source IP range or an appropriate service tag such as VirtualNetwork.

A direct way to identify the blocking rule is Network Watcher > IP flow verify:

Direction: Inbound
Protocol: TCP
Local port: 80 or 3389
Remote IP address: source VM private IP
Remote port: * or any source port

This returns whether traffic is Allowed or Denied and shows the exact NSG rule responsible.

About the questions:

How to get the inbound rule to allow when two VMs communicate?
- Add or correct an inbound allow rule on the blocking NSG.
- Make sure it exists on the required scope: subnet NSG, NIC NSG, or both.
- Set the rule priority lower than any conflicting deny rule.
- Verify the source matches the peered VNet traffic.
- Recheck with IP flow verify or Connection troubleshoot.
What kind of service or application needs inbound deny?
- An inbound deny rule is used when traffic to a VM or port should be blocked. A higher-priority deny rule overrides a lower-priority allow rule.
What kind of service or application/situation needs inbound allow?
- Any workload that must accept inbound connections needs an inbound allow rule for the required protocol and port. Examples from the scenario are:
  - 3389/TCP for RDP
  - 80/TCP for HTTP

If the test shows Connectivity test = Reachable but Inbound NSG diagnostic = Deny, focus on the destination side effective rules first. That usually means the route is fine, but the destination NSG evaluation still has a deny match for that port.

References: