Azure P2S VPN Return Traffic Only Works One Way

The tunnel icon is green, the NSG looks permissive, the effective routes look right, and the VM still cannot open a connection back to the connected client. The usual assumption is that a working point-to-site tunnel is symmetric: if the client can reach the VM, the VM can reach the client. That assumption is the bug in the reasoning, not in the configuration. A tunnel can carry one direction of an unsolicited flow while dropping the other, and the fix depends on which layer is dropping it.

Myth: a connected tunnel is a two-way tunnel

A VPN tunnel is a policy path, not a wire. Each direction is matched against selectors, routes, and filters, and any of them can allow one direction while blocking the other.

In practice the asymmetry is common enough that direction belongs in the first test, not the last. The client initiates, the gateway tracks the flow, and the reply follows the state that was created. A VM that starts a new flow has no such state, so it depends on the return path being explicitly routable and permitted. When that path is missing, the connection attempt dies before any application sees it.

Test direction before you test reachability

Pick one client address, one VM address, and one protocol. Connect from the client and record the result; then start the same test from the VM and record that too. If the first succeeds and the second fails, the client pool, the gateway association, and the client-to-VNet path are all working.

The next step is evidence, not more rules. Check the NSG on the VM subnet in both directions, read the effective routes on the VM NIC, and capture packets on the VM while the client sends traffic. A request that arrives with no reply is a filter or a return-route problem; a request that never arrives is a path problem. Do not treat a failed ping as proof that the VM is unreachable, because ICMP policy can drop the reply while TCP works.

The IKEv2 point-to-site return path is the usual suspect

In the Azure report behind this article, a client could reach VMs over IKEv2, but inbound ICMP from the VM to the client failed until the gateway tunnel type was switched to OpenVPN. The reporter states that Microsoft confirmed a limitation in the IKEv2 point-to-site path, where return traffic from a VM to the client is not routed symmetrically unless the client started the session. IKEv2 relies on traffic selectors, and the gateway did not honor the return direction in that case.

That does not make OpenVPN the better tunnel type in general. It makes tunnel type a variable in the test matrix for this workload.

Switching tunnel types is a service change, not a toggle. Every client needs a compatible profile, and the gateway may need a different certificate or authentication setup. Reproduce the one-way behavior with one test client and one test VM, change the type on an approved schedule, and repeat the same directional tests afterwards. If the behavior survives the switch, the tunnel type was not the cause and you have narrowed the problem without touching production.

Myth: broadcast discovery crosses the VNet edge

A second assumption fails for an unrelated reason. An Azure virtual network does not carry broadcast traffic, so a VM cannot receive broadcast frames from an on-premises network over a site-to-site or point-to-site connection. Applications that find peers by broadcast, such as older file browsing or some device-discovery protocols, will never see the remote side no matter how the routes are written.

Replace broadcast discovery with DNS names, a directory service, or an explicit peer list. If the application has no unicast alternative, the design needs a different discovery mechanism, not a wider tunnel.

What to change, and how to prove it

If the directional test fails only on IKEv2, record the gateway tunnel type, the client address pool, and the exact ICMP or TCP test, then evaluate an approved OpenVPN profile for the affected clients. If it fails on every tunnel type, work the return path: the client address must be routable from the VM subnet, any user-defined route must point at a valid next hop, and the client firewall must accept the inbound flow. Attach the NSG and route evidence to the ticket.

Verify with the application, not with ping. A successful ICMP exchange after a change says nothing about the service port, its authentication, or its name resolution. Repeat the test after a reconnect, because a client that receives a different pool address can change the result. Then repeat it once more after the client sleeps and wakes, since a resumed session is where one-way behavior often reappears.