An Azure service that delivers high availability and network performance to applications.
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:
- A route change that force‑tunnels 0.0.0.0/0 away from the intended egress (NAT Gateway / NVA).
- An NSG or firewall rule on the NVA subnet or NVA itself that now blocks outbound internet.
- Misconfiguration of the NAT Gateway or load balancer used for outbound.
Use the following checks end‑to‑end, focusing on the NVA path.
- 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.
- 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.
- 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.
- Confirm there are no deny rules with higher priority than the allow‑internet rules on:
- 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.
- 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
and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.