Azure VM cannot communicate with the on-premises server

Question

Azure VM cannot communicate with the on-premises server

Riyas Razik 0

We are experiencing an issue with a Site-to-Site IPsec VPN between a FortiGate firewall and an Azure Virtual Network Gateway.

Environment

Azure Region: East US

VPN Gateway SKU: VpnGw1AZ (Route-based)

Azure VNet: 10.0.1.0/24

Azure VM: Ubuntu 22.04 (10.0.1.4)

On-Premises Network: 172.25.16.0/24

On-Premises Server: 172.25.16.122

Firewall: FortiGate

Issue

The VPN tunnel is successfully established and the Azure portal shows the connection as Connected. However, the Azure VM cannot communicate with the on-premises server.

Troubleshooting Completed

We have verified that:

VPN connection status is Connected.

Azure VPN Gateway is Route-based.

Local Network Gateway includes the on-premises subnet (172.25.16.0/24).

No User Defined Routes (UDRs) are associated with the Azure subnet.

NSGs allow the required traffic.

Ubuntu UFW is disabled.

FortiGate Phase 1/Phase 2 configuration, routing, firewall policies, and NAT settings have all been verified.

Packet Capture Results

On the Azure VM, tcpdump shows only ICMP Echo Requests leaving the VM. No Echo Replies are received.

On the FortiGate, packet captures confirm:

ICMP Echo Requests from 10.0.1.4 arrive through the VPN tunnel.

  The on-premises server (**172.25.16.122**) sends ICMP Echo Replies.
  
  However, those Echo Replies never reach the Azure VM.

This suggests the return traffic is being lost somewhere between the Azure VPN Gateway and the Azure VM.

Has anyone encountered a similar issue or can suggest additional Azure-side checks (effective routes, gateway diagnostics, hidden filtering, or other possible causes) that could explain why return traffic is not reaching the VM despite the VPN tunnel being connected?

Bhavani Kamidi 0 Reputation points Microsoft External Staff

2026-08-17T04:59:02.12+00:00
Hi @Riyas Razik
Could you please perform the following Azure-side checks?

Azure VPN Gateway packet capture: Capture traffic while pinging 172.25.16.122 from the Azure VM and verify whether the ICMP reply (172.25.16.122 → 10.0.1.4) is visible at the VPN Gateway.

VM NIC Effective Routes: Verify that 172.25.16.0/24 has Next Hop = Virtual network gateway.

VM NIC Effective Security Rules: Verify that there is no rule blocking traffic from 172.25.16.0/24.

Microsoft reference: https://learn.microsoft.com/en-us/azure/vpn-gateway/packet-capture?

Please share the packet capture result and Effective Routes output with us so we can determine where the return traffic is being dropped.

1 answer

Your answer

Bhavani Kamidi 0 Reputation points Microsoft External Staff

2026-08-17T04:59:02.12+00:00

Hi @Riyas Razik
Could you please perform the following Azure-side checks?

Azure VPN Gateway packet capture: Capture traffic while pinging 172.25.16.122 from the Azure VM and verify whether the ICMP reply (172.25.16.122 → 10.0.1.4) is visible at the VPN Gateway.

VM NIC Effective Routes: Verify that 172.25.16.0/24 has Next Hop = Virtual network gateway.

VM NIC Effective Security Rules: Verify that there is no rule blocking traffic from 172.25.16.0/24.

Microsoft reference: https://learn.microsoft.com/en-us/azure/vpn-gateway/packet-capture?

Please share the packet capture result and Effective Routes output with us so we can determine where the return traffic is being dropped.

Answer 1

Hello @Riyas Razik

To help narrow down the issue, could you share a few additional details about your hybrid connectivity?

Are you using Site-to-Site VPN or ExpressRoute?
Can the Azure VM reach any on-premises hosts, or is the problem isolated to a specific server or subnet?
What are the source and destination IP ranges?

In the meantime, I'd recommend checking the following:

Verify the effective routes on the Azure VM's NIC to ensure the on-premises prefixes are being learned through the Virtual Network Gateway (or ExpressRoute).
Review the effective NSG rules to confirm outbound traffic from the VM and return traffic are allowed.
Validate that the on-premises firewall permits traffic from the Azure VNet address space and that a return route to the Azure subnet exists. A missing return route or firewall policy is a common cause of one-way connectivity.
Use Azure Network Watcher (IP Flow Verify and Connection Troubleshoot) to determine whether Azure is allowing the traffic and where it's being dropped.
If DNS names are being used, test connectivity by IP address first to rule out a DNS resolution issue.

If the VPN/ExpressRoute shows as connected but communication still fails, the issue is often related to routing, firewall policies, or asymmetric routing rather than the Azure VM itself. Microsoft recommends validating effective routes, NSG rules, and on-premises network policies as part of the troubleshooting process.

If you can share the exact error (timeout, connection refused, ping failure, specific port, etc.) and your network topology, the community can provide more targeted guidance.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.