Inbound ICMP failure from Azure P2S VPN to VM - no return path despite correct setup

Question

Description: I am facing a persistent routing issue when using Azure VPN Gateway (VpnGw1) with Point-to-Site (P2S) IKEv2/EAP authentication. The VPN client (Windows 11) successfully connects and receives an IP from the pool 192.168.16.0/24, and can initiate outbound ICMP (ping) to an Azure VM (192.168.1.4) within VNet1. However, the reverse direction—from the VM to the VPN client—fails completely with 100% packet loss. Tracert from the VM also fails, showing no route beyond the local network.

Environment Summary:

• VPN Gateway: VpnGw1 (IKEv2 tunnel only, with RADIUS authentication).
• VPN Client: Windows 11 (IP: 192.168.16.2, connected successfully).
• VM: Windows Server 2022 Core (192.168.1.4), deployed in VNet1Sub1.
• NSG: Applied at subnet level (nsg1), allows full ICMP in/out from both 192.168.16.0/24 and dynamic IP ranges.
• UDRs: No explicit UDRs at the time of testing; default system routes are injected as expected.
• Diagnostics: Full logging enabled (IKE, Gateway, Route, Tunnel, P2S). Results forwarded to Log Analytics.

Testing & Findings:

• From VPN client to VM: ICMP Echo Requests reach the VM.
• From VM to VPN client: All requests time out. Wireshark confirms no replies ever leave the VM.
• System routing table on the VM confirms an active system route:

192.168.16.0/24 -> next hop 131.189.102.130 (VPN gateway public IP)

This route appears to be automatically injected.

• NSGs do not block traffic; Windows Firewall allows ICMP both ways.
• Creating UDRs (VPN Pool → Virtual Network Gateway) made no difference.
• Adding a test UDR caused loop scenarios (TTL expired in transit), confirming that traffic at least exits the VM.

Diagnostics Result:

• No errors found in the IKEDiagnosticLog.
• No failed tunnel negotiations or dropped connections.
• Uploaded CSV file shows clean IKE session establishment and traffic selectors.

Conclusion: Everything indicates that traffic routing from the VM to the VPN client is being misrouted, dropped, or not returned due to asymmetric routing. As the VPN gateway successfully handles the initial tunnel and selector negotiation, the issue appears to lie in the internal platform routing logic between the VNet and P2S client IP pool.

Any idea why the default system routing does not return VPN-originated traffic properly. I would appreciate confirmation whether this is a platform-level limitation or a known issue with IKEv2-based P2S in this configuration.

Normally it is supposed to work properly as it is a simple configuration. This issue have kept me busy for days now.

---

Answer 1

Hello Harald Goyn

It seems you are experiencing a routing issue between your Azure P2S VPN and your VM.

Consider the possibility of asymmetric routing. Since you're using IKEv2 with RADIUS authentication, ensure both directions of the traffic understand how to return correctly. Multiple paths might cause incorrect routing of traffic.

The issue you are experiencing VMs in Azure cannot initiate traffic to P2S VPN clients is a recognized platform-level limitation in Azure when using IKEv2-based Point-to-Site (P2S) VPN connections.

• Outbound traffic from VPN client to VM works because Azure injects system routes to allow this.
• Inbound traffic from VM to VPN client fails due to asymmetric routing: Azure does not route return traffic correctly from VNet to the P2S client IP pool.

Azure’s internal routing logic for P2S VPN clients:

• P2S clients are not treated as routable endpoints like VMs or peered VNets.
• Traffic selectors negotiated during IKEv2 setup are respected for outbound traffic, but return traffic is not symmetrically routed unless NAT or custom routing logic is applied.

Although the VM sees a route to the VPN client subnet via the gateway’s public IP, Azure does not forward traffic from the VM back to the VPN client unless the client initiates the session

Ensure the routing table on the Azure side is correctly set up. Verify that there are no conflicting routes or Network Security Groups (NSGs) on the VM or subnet level that might block return traffic, even if a route was automatically injected for the VPN client pool.

Although full diagnostics are enabled and no apparent issues were found, check Azure's logs through Network Watcher to identify any dropped packets or anomalies that could provide clues.

Please go through my recommended suggestions:

Use OpenVPN instead of IKEv2: OpenVPN-based P2S connections often handle bidirectional traffic better in certain scenarios.

Enable NAT on the VPN Gateway: If supported in your region and SKU, NAT can help rewrite source/destination IPs to ensure symmetric routing.

Use Azure Virtual WAN: Offers better routing control and may resolve asymmetric routing issues by treating P2S clients more like branch endpoints.

Reverse Proxy or Relay: Deploy a relay VM or service inside the VNet that the VPN client connects to, and have the VM communicate with the relay instead of directly with the client.
Enable BGP on the VPN Gateway (if not already): BGP can help advertise the P2S address pool back into the VNet, potentially resolving the asymmetric routing issue.

Use Forced Tunneling with Custom Routes: Although you've tried UDRs, consider using a forced tunneling setup with a 0.0.0.0/0 route pointing to the VPN gateway. This may help Azure recognize the return path more explicitly.

In the meantime, please share the below information for further investigation:

1. Have you tested connectivity with other VMs to determine if the issue is isolated to just one VM?
2. Could you provide more details about any specific configurations of the VM, such as installed applications or additional firewalls?
3. Are there any other networking resources (like VPN appliances or third-party firewalls) in use, and how are they configured to handle VPN traffic?
4. Can you confirm whether the VPN client is using a static or dynamically assigned IP address?
5. Are there any custom routes or UDRs that you haven't mentioned earlier?

---

Hope the above answer helps! Please let us know do you have any further queries.

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