[UPDATE – RESOLVED]

After extensive troubleshooting and countless hours analyzing packet captures, NSG/UDR configurations, and effective routes, the P2S VPN routing issue has finally been resolved – and the root cause was surprising.

Problem:

Inbound ICMP (or any traffic) from Azure VMs to the VPN client (192.168.16.x) failed when using IKEv2, even though outbound traffic from the VPN client to VMs worked fine. All routes, NSGs, diagnostics, and logs showed expected behavior. Yet, return traffic never reached the VPN client.

Solution:

Switched the Azure VPN Gateway tunnel type from IKEv2 to OpenVPN (SSL) and connected using the OpenVPN client instead. Immediately after connecting, inbound and outbound traffic between the VPN client and Azure VMs started working perfectly.

Key Observations:

No changes were made to the NSG, UDR, or VM firewall after switching protocols.

It appears the IKEv2 connection had an underlying asymmetric routing or encapsulation issue that Azure didn’t route correctly.

OpenVPN (SSL) handled the return traffic properly without additional UDRs or complex tweaks.

Both Linux (Ubuntu VM) and Windows 11 confirmed bidirectional ICMP now works.

Tip for others facing similar issues:

If you're using Azure P2S with IKEv2 and experiencing one-way traffic issues (especially inbound failures), switch to OpenVPN and test again. It might save you days of debugging.

Next Steps:

I'm now migrating the Raspberry Pi VPN client to OpenVPN (CLI-only) and keeping FreeRADIUS on EC2 for centralized auth.