Networking: Ping is not forwarded through Wireguard Gateway VM

Question

Networking: Ping is not forwarded through Wireguard Gateway VM

David 0

Hello,

I'm having trouble connecting from a VM in my Azure subscription to a machine in my home network over a WireGuard tunnel.

My setup consists of three machines:

Home machine
- Containerized WireGuard installed
- WireGuard IP: 10.20.0.2
WireGuard Gateway VM (Linux) in Azure subnet "Networking"
- Containerized WireGuard installed
- VNet IP: 10.0.1.4
Test VM (Linux) in Azure subnet "AKS"
- VNet IP: 10.0.6.4

Current connectivity:

✅ Gateway VM (2) can successfully ping the home machine (1).
✅ Test VM (3) can successfully ping the Gateway VM (2).
❌ Test VM (3) cannot ping the home machine (1), even though traffic should be routed through the Gateway VM.

I've already verified the following:

User-defined route (UDR) and its association with the subnet.
Network Security Groups (NSGs).
IP forwarding is enabled on the Gateway VM.

I also ran several tests.

Test 1:

On Gateway VM:

sudo tcpdump -i eth0 icmp -n

On Test VM:

ping 10.20.0.2

Result (Gateway VM):

No ICMP packets appear on the Gateway VM. This suggests that the traffic never reaches it.

Test 2:

On Gateway VM:

sudo sysctl net.ipv4.ip_forward

Result (Gateway VM):

net.ipv4.ip_forward = 1

Test 3:

On Test VM:

sudo tcpdump -i eth0 icmp -n

On other session Test VM:

ping 10.20.0.2

Result (Test VM):

 sudo tcpdump -i eth0 icmp -n
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
04:59:21.765631 IP 10.0.6.4 > 10.20.0.2: ICMP echo request, id 1930, seq 1, length 64
04:59:22.777193 IP 10.0.6.4 > 10.20.0.2: ICMP echo request, id 1930, seq 2, length 64
04:59:23.801191 IP 10.0.6.4 > 10.20.0.2: ICMP echo request, id 1930, seq 3, length 64
04:59:24.825204 IP 10.0.6.4 > 10.20.0.2: ICMP echo request, id 1930, seq 4, length 64
04:59:25.849203 IP 10.0.6.4 > 10.20.0.2: ICMP echo request, id 1930, seq 5, length 64
04:59:26.873324 IP 10.0.6.4 > 10.20.0.2: ICMP echo request, id 1930, seq 6, length 64
04:59:27.897217 IP 10.0.6.4 > 10.20.0.2: ICMP echo request, id 1930, seq 7, length 64

The Test VM is clearly generating the ICMP requests.

Test 4:

On Test VM:

ip route get 10.20.0.2

Result (Test VM):

10.20.0.2 via 10.0.6.1 dev eth0 src 10.0.6.4 uid 1000
    cache

This appears to indicate that the route is being used as expected.

Since no packets arrive at the Gateway VM, I'm wondering if Azure is dropping the traffic before it reaches the NIC. Is there something I'm overlooking, such as Azure requiring additional configuration?

Any ideas or suggestions would be greatly appreciated.

Thanks!

P Kamala 0 Microsoft Employee

@David Great troubleshooting so far — your tcpdump captures and route tests pinpoint the problem area clearly. The critical finding is that no ICMP packets arrive on the Gateway VM's eth0, which means Azure's SDN fabric is not delivering the traffic to 10.0.1.4.
Let me walk through the most likely causes, starting with the most common.

1. Verify the UDR is correctly configured AND associated with the "AKS" subnet

Note: The ip route get 10.20.0.2 output showing via 10.0.6.1 is expected and normal in Azure. UDRs are enforced at the Azure SDN/hypervisor layer and are invisible to the guest OS. The guest always sees the subnet's default gateway (x.x.x.1). So that output does NOT confirm your UDR is working — it only confirms the VM sent the packet out.

The #1 cause of "packets never arrive at the NVA" is a UDR misconfiguration. Please verify all of the following:

Setting	Required Value
Address prefix	10.20.0.0/24 (or whatever your WireGuard subnet is — must cover 10.20.0.2)
--------	--------
Address prefix	10.20.0.0/24 (or whatever your WireGuard subnet is — must cover 10.20.0.2)
Next hop type	Virtual appliance
Next hop address	10.0.1.4 (the Gateway VM's VNet IP)
Route table associated with	The "AKS" subnet (10.0.6.0/x), NOT the "Networking" subnet

A common mistake is associating the route table with the Gateway VM's own subnet instead of the source VM's subnet.

To confirm, check the Effective Routes on the Test VM's NIC in the Azure Portal:

Portal → Test VM → Networking → NIC → Effective Routes

Look for an entry matching 10.20.0.0/24 with next hop 10.0.1.4 and source User. If it's missing or shows None/Internet as the next hop, the UDR is not applied correctly.

You can also check via CLI:

az network nic show-effective-route-table \
  --resource-group <your-rg> \
  --name <test-vm-nic-name> \
  --output table

2. Confirm IP Forwarding is enabled on the Azure NIC (not just the OS)

There are two layers of IP forwarding that must both be enabled:

Azure NIC level (Portal → Gateway VM → Networking → NIC → IP forwarding = Enabled)
Guest OS level (sysctl net.ipv4.ip_forward = 1 — you've confirmed this)

If the Azure NIC-level setting is not enabled, Azure drops any packet where the destination IP doesn't match the NIC's own IP. Since 10.20.0.2 is not an IP on the Gateway VM's NIC, Azure will silently drop it before it even reaches the VM. This would perfectly explain your tcpdump showing zero packets.

az network nic show \
  --resource-group <your-rg> \
  --name <gateway-vm-nic-name> \
  --query "enableIPForwarding"

This must return true.

3. Check NSG rules on BOTH subnets

NSGs are evaluated before UDR routing. Verify:

AKS subnet NSG (outbound): Must allow traffic from 10.0.6.0/24 to 10.20.0.0/24
Networking subnet NSG (inbound): Must allow traffic from 10.0.6.0/24 to 10.20.0.0/24

Use NSG Flow Logs or Effective Security Rules on both NICs to confirm traffic isn't being denied. ICMP is often overlooked in NSG rules — ensure you have a rule allowing protocol ICMP (or *).

4. Once traffic reaches the Gateway VM — WireGuard-specific routing

After you fix the above (most likely #1 or #2), traffic will arrive at the Gateway VM. But you'll need to ensure the Gateway VM correctly forwards it into the WireGuard tunnel:

a) Routing inside the Gateway VM: The Gateway VM needs a route for 10.20.0.0/24 pointing to the WireGuard interface (wg0). Since WireGuard is containerized, verify the container's network namespace has the correct routing, or that the host has a route to 10.20.0.0/24 via the wg0 interface.

ip route show | grep 10.20.0

b) WireGuard AllowedIPs on the home machine peer: On the Gateway VM's WireGuard config, the peer entry for the home machine must include 10.20.0.0/24 (or 10.20.0.2/32) in AllowedIPs.

c) Return path — this is often missed: The home machine must know how to route 10.0.6.0/24 back through the WireGuard tunnel. On the home machine's WireGuard config, the peer entry for the Gateway VM must include 10.0.6.0/24 in AllowedIPs. Otherwise, the reply packets won't be sent back through the tunnel.

Alternatively, you can add a masquerade/SNAT rule on the Gateway VM so return traffic appears to originate from the Gateway VM's WireGuard IP (10.20.0.x):

iptables -t nat -A POSTROUTING -s 10.0.6.0/24 -o wg0 -j MASQUERADE

Summary — Recommended action order:

Check Effective Routes on the Test VM NIC → confirms if UDR is applied
Confirm Azure NIC IP Forwarding on the Gateway VM → enableIPForwarding: true
Review NSG effective rules on both NICs → confirm ICMP allowed
Fix whichever is wrong → re-test ping 10.20.0.2 from Test VM while running tcpdump on Gateway VM
Once packets arrive at Gateway VM → verify WireGuard routing + return path

Based on your symptoms (packets leave Test VM but never arrive at Gateway VM), #1 (UDR not associated with the AKS subnet) or #2 (Azure NIC IP forwarding not enabled). These are the two Azure-platform-level controls that would silently drop traffic before it reaches the Gateway VM's NIC.

Let us know what Effective Routes and the NIC IP forwarding setting show, and we can narrow it down further.

Hope this helps — happy to dig deeper once you share the effective routes output.

1 answer

Your answer

Answer 1

Hello @David

If the WireGuard tunnel is established but ICMP (ping) isn't forwarded, the issue is typically related to routing, IP forwarding, or firewall policies, rather than WireGuard itself.

I'd recommend checking the following:

1. IP forwarding

Ensure IP forwarding is enabled on the WireGuard gateway.
On Linux, verify: sysctl net.ipv4.ip_forward It should return 1.

2. AllowedIPs configuration

Confirm that the peer's AllowedIPs includes the remote subnet you're trying to reach, not just the WireGuard tunnel IPs.
An incorrect AllowedIPs entry is one of the most common causes of traffic not being routed through the tunnel.

3. Routing

Verify that both sides have routes for the remote network pointing to the WireGuard interface.
Check the routing tables (ip route on Linux or route print on Windows).

4. Firewall / NSGs

If Azure VMs are involved, ensure:
- Network Security Groups (NSGs) allow ICMP (or test with TCP if ICMP is intentionally blocked).
- The guest OS firewall (Windows Firewall or iptables/nftables) permits ICMP.
Azure blocks some ICMP scenarios by default depending on the networking configuration, so a TCP connectivity test (Test-NetConnection or nc) can sometimes be a better validation.

5. Source/Destination Check (Azure)

If the WireGuard VM is acting as a router, verify that IP forwarding is enabled on the Azure NIC, otherwise Azure drops forwarded packets.

Could you provide a bit more information?

Where is WireGuard running (Azure VM, Linux appliance, Windows, pfSense, etc.)?
Which direction is failing?
- Client → Server
- Server → Client
- LAN ↔ LAN through the tunnel
Can the peers successfully complete the WireGuard handshake (wg show)?
Are only ICMP packets failing, or does TCP traffic (SSH, RDP, HTTP) also fail?

That will help determine whether this is a routing issue, a firewall issue, or an Azure networking configuration issue.

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

Allan Solomon Mejia 3,175 Reputation points

2026-08-10T17:15:28.9466667+00:00

Hello @David

Please let me know if you need any further assistance. Otherwise, if the information provided has resolved your issue, please consider clicking “Accept Answer” to help others who may encounter the same problem.

Thank you!