Azure VPN connected but cannot ping

What “connected but not pingable” typically means

• ICMP is commonly blocked by default in Azure and many on-prem networks.
• The VPN tunnel can be healthy while traffic is being filtered by firewall rules.
• Routes may appear to be in place, but virtual network endpoints don’t have the expected allow rules.
• The issue could be on the client side (PC firewall) or the server side (VM firewall or NSG).

Quick checklist to rule out common blockers

• Check the VM’s firewall (Windows Firewall, UFW on Linux) to ensure ICMP is allowed.
• Inspect the NSG attached to the VM’s network interface and subnet. Verify inbound/outbound ICMP rules.
• Confirm that the VPN gateway/subnet routing is correct and that no custom route blocks ICMP.
• Try alternative tests (TCP-based tests like ping via port 3389 is not ICMP, but you can test RDP port 3389 with a TCP connect test if allowed) to verify reachability beyond ICMP.

Verify the VPN type and the health of the connection

• Identify the VPN type you’re using: Point-to-Site (P2S) or Site-to-Site (S2S). Each has different implications for routing and client configuration.
• Check tunnel status in the Azure portal:
• For S2S: ensure both tunnels are up, have no ongoing flaps, and that the local network gateway and VPN gateway are healthy.
• For P2S: verify the client reconnects successfully, and the client VPN profile includes the correct address space and routes.
• Look for any recent changes in the gateway configuration that could affect routing or access.

How to verify in the portal

• Go to the VPN gateway resource, then check:
• Tunnels: status, uptime, and last reset time.
• Connections: active clients and their last activity.
• Shared keys or certificate status (for S2S) if applicable.
• Cross-check the VPN client’s assigned IP address against the VM’s subnet and route table to ensure traffic is directed correctly.

Check routing and reachability: routes, NSGs, and firewall

• Ensure the VM’s NIC has a private IP in the VNet and that the route table (if you have a custom route table) directs traffic to the VPN gateway when appropriate.
• Inspect NSGs:
• Inbound rules should allow ICMP (protocol ICMP) if you want ping to work. Also ensure TCP/UDP ports you test are allowed if you’re using other probes.
• Outbound rules should allow responses back to the client’s IP range.
• VM Firewall:
• Windows: check inbound rules for File and Printer Sharing (Echo Request) or a generic ICMP rule. Disable or expand as needed to test ICMP, then tighten after testing.
• Linux: verify iptables/nftables or firewalld isn’t blocking ICMP. You can temporarily allow ICMP with appropriate rules for testing.
• Routing tables:
• If you have custom user-defined routes (UDRs), make sure there’s a route for the VPN client network to the VPN gateway and not to a wrong path.

Test methods that help pinpoint the problem

• Ping from a host behind the VPN (another VM in the VNet, or from the on-prem side if S2S) to the target VM:
• If ping fails but a TCP test to a known open port works, the issue is likely ICMP filtering.
• Use TCP-based tests:
• Try to establish a TCP connection to a port you know is open (RDP 3389, SSH 22) to test general reachability.
• If TCP works and ICMP does not, focus on ICMP permissions rather than routing.
• Use traceroute/tracert:
• See where the traffic drops. If it stops at the VPN gateway or a particular hop, you may have a firewall or routing misconfiguration.

A practical, small table: common blockers and how to fix them

A short, practical checklist you can follow now

1. Confirm VPN tunnel health:
   • In Azure, check that the VPN gateway shows tunnels up and there are no errors.
   • If needed, reset the tunnel from both ends (Azure side and on-prem/client side).
2. Validate network security:
   • Check NSGs attached to the VM NIC and subnet. Ensure ICMP is allowed from the VPN client subnet.
3. Inspect VM-side firewall:
   • Windows: allow ICMP (Echo Request) inbound or disable the firewall temporarily for testing.
   • Linux: ensure ICMP is not blocked by iptables/nftables/firewalld.
4. Confirm routing:
   • Ensure there is a route for the VPN client network to the VPN gateway.
   • If you’re using split-tunnel, verify that only desired traffic goes through the VPN and that the rest uses the normal route.
5. Test with multiple methods:
   • Ping the VM from a VPN-connected client.
   • Use a TCP port test (e.g., RDP 3389 or SSH 22) to confirm reachability.
   • Run traceroute to see where the traffic stops.
6. Review recent changes:
   • Any updates to NSGs, firewall rules, or VPN configuration can reintroduce ping failures.

When you might see “connected but ping fails” in common scenarios

• P2S VPN with a client that has no route to the Azure VNet: the tunnel can stay up but you’re not routing traffic correctly.
• S2S VPN where the on-prem firewall or router blocks ICMP or has a mismatch in networks that prevents translating the VPN’s address space to the on-site network.
• A VM with a firewall that blocks ICMP even though the OS allows most traffic, making it seem like the VPN is failing when it’s actually the host firewall.

A quick comparison: ping vs other checks

Final recommendation

If your Azure VPN shows as connected but you cannot ping resources, start by methodically ruling out ICMP-specific blocks (firewalls and NSGs) while also validating that routing is correct for your VPN type. The most common culprits are:

• ICMP being blocked by the VM’s firewall or NSG
• Misconfigured or overly restrictive NSGs or route tables
• A VPN tunnel health issue that masks as “connected” but isn’t carrying traffic to the right destinations

By following the steps above, you can isolate whether the issue is client-side, VM-side, or network-side, and apply the appropriate fix. If you’re still stuck after all checks, collect the gateway/tunnel logs, test results (including traceroutes and port tests), and share them in Azure support forums or with your network team to get targeted help.