No more internet access on virtual machines.

Question

With this architecture, the organization experiencing problems with all virtual machines accessing the internet (probing fails, no ping) but the private network stills working though.

All the routing and DNS config seems to be ok, but the internet traffic "stucks" inside the NVA. We checked all the NSGs, all the rules seems fine (all internet outbound allowed).

Internet access out of service since yesterday (2026-04-24) in the afternoon.

Thanks for your support !

Answer 1

Hi François Lépine,

Thanks for reaching out in Microsoft Q&A forum,

Your network issue is almost certainly caused by SNAT port exhaustion on your Network Virtual Appliance (NVA) cluster. Because all your spoke virtual machines share the same egress path through the NVA and the Internal Load Balancer, they are rapidly consuming the available SNAT ports.

Once the port limit is reached, new outbound connections to the internet will silently fail, while internal, non-SNAT-dependent traffic continues to function normally.

Think of SNAT ports like a limited pool of "return address" labels. When all your spoke virtual machines send traffic to the internet through one NVA, they have to share that same pool of labels. If those machines open more connections than you have labels, the NVA simply runs out of room to track them, causing new outbound traffic to "stuck" at the appliance. Because your private traffic doesn't need these translation labels, it continues to work without a hitch.

To get things moving again, I recommend these steps:

• The "Bypass" Test: If you can, briefly update your User-Defined Route (UDR) in the spoke subnets to bypass the NVA. If your internet connectivity suddenly jumps back to life, you have definitive proof that the bottleneck is inside the NVA's egress processing.
• Offload to NAT Gateway: Rather than trying to squeeze more capacity out of your NVA, the best modern approach is to associate an Azure NAT Gateway with your NVA subnet. This effectively offloads the heavy lifting of SNAT to a service designed to scale automatically, providing 64,512 ports per IP. This lets your NVA focus on its real job inspecting traffic without being crushed by connection management.

This transition not only solves your current outage but aligns your architecture with current Azure best practices for reliable, explicit outbound connectivity.

Reference:

What is Azure NAT Gateway? | Microsoft Learn

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

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Answer 2

In this hub‑and‑spoke design with an NVA and internal Load Balancer, loss of internet access while private traffic still works almost always points to one of these issues:

1. A route change that force‑tunnels 0.0.0.0/0 away from the intended egress (NAT Gateway / NVA).
2. An NSG or firewall rule on the NVA subnet or NVA itself that now blocks outbound internet.
3. Misconfiguration of the NAT Gateway or load balancer used for outbound.

Use the following checks end‑to‑end, focusing on the NVA path.

1. Validate NAT Gateway / outbound configuration
   • Confirm the NAT Gateway has at least one public IP or prefix and is attached to the correct subnet in the hub.
   • Ensure the VMs that lost internet are on subnets that either:
     • use this NAT Gateway for outbound, or
     • correctly route to the NVA, which then SNATs and sends traffic out.
   • If an IPv6 public IP is configured, verify the VNet/subnet is dual stack; otherwise add an IPv4 public IP.
2. Check effective routes on a VM NIC
   • On one affected VM, inspect the effective routes on its NIC.
   • Verify that 0.0.0.0/0 isn’t being forced to a VPN/ExpressRoute gateway or another NVA by a new user‑defined route. Any such UDR will override the NAT Gateway and can strand traffic at the NVA or gateway.
   • Remove or correct any misroute that sends Azure Storage/Internet traffic to a VPN gateway instead of the internet path, similar to the misroute described in the context.
3. Inspect NSGs on VM, NVA subnet, and hub subnets
   • Confirm there are no deny rules with higher priority than the allow‑internet rules on:
     • VM NICs
     • Spoke subnets
     • NVA subnet
   • For Standard Load Balancer / public IPs, remember inbound is denied by default; NSGs must explicitly allow the traffic.
4. Verify NVA datapath and rules
   • From a source VM, run a connectivity test (for example, using Network Watcher connection troubleshoot) to a known internet endpoint.
   • Capture simultaneous traces on:
     • Source VM
     • NVA
   • If packets reach the NVA but never leave, the NVA routing or firewall policy is blocking or misrouting them; adjust NVA routes/NAT/SNAT rules accordingly.
   • If packets never reach the NVA, a UDR or NSG before the NVA is dropping or redirecting traffic.
5. Check DNS only after routing is confirmed
   • Since probes and ping fail, start with routing and firewall as above. If name resolution also fails, validate DNS settings using the DNS troubleshooting guidance.

By systematically validating NAT Gateway configuration, effective routes (especially 0.0.0.0/0 and any storage or internet prefixes), NSGs, and the NVA’s own routing/SNAT rules, the specific change that started blocking outbound internet can be identified and reverted.

---

References:

• Troubleshoot Azure NAT Gateway connectivity problems
• Troubleshoot Azure Load Balancer
• Troubleshoot Azure VM connectivity problems
• Troubleshoot connectivity problems between Azure virtual machines
• Network virtual appliance issues in Azure
• No Internet access from Azure Windows VM that has multiple IP addresses
• No Internet Access from an Azure Virtual Network with a NAT Gateway - Microsoft Q&A
• Azure Firewall blocking access to Power BI blob storage endpoint despite Network Rule allowing Storage service tag - Microsoft Q&A