Ping works one way: why Windows drops the server echo

Your client pings the server, the server cannot ping the client, and the tunnel is plainly carrying packets in both of those statements. What differs is not the path but the first packet of each test: one is a reply to a flow Windows already tracks, the other is a fresh inbound request that no rule has admitted. That difference explains most one-way ping reports and points straight at the rule you have to write. Two tests run in opposite directions separate the cases in about a minute.

Two Directions, Two Different Decisions

When the client sends the echo request, the Windows firewall sees an outbound connection it has decided to permit. The reply comes back inside that established flow, so the stateful engine admits it without consulting any inbound rule for ICMP. That is what stateful filtering means in practice, and the rule nobody wrote is not involved. The client's success therefore says nothing about the inbound policy.

When the server sends the request first, no state matches it. Windows treats the packet as a new inbound connection and asks the inbound policy, which by default has no provision for echo requests arriving from arbitrary sources.

So the client's success proved that outbound ICMP and the return path work. It never exercised the inbound decision, and the natural conclusion, that the firewall is fine, is reasonable and wrong. That is why the mistake keeps repeating in tickets that already contain the evidence.

Follow the Packet Until It Disappears

Confirm the addresses before changing anything: use the tunnel address the client actually holds, and check that the server routes to it rather than to a LAN address behind the client. The two failures look identical from the server's prompt, because both end in a timeout. Where the packet dies is the only fact that decides what to change.

If the request reaches the tunnel interface and nothing leaves, the local firewall is the likely reason. If it never reaches the interface, the answer is upstream: a server route, an outbound policy, or the VPN's own peer delivery.

Capture on the client's tunnel interface while the server pings. Seeing the request arrive with no reply beside it is the evidence that justifies writing a Windows rule. Seeing nothing at all sends you upstream, and a rule added in that state only makes the machine more permissive for a packet that never arrived. Either way the capture costs less than the guesswork it replaces.

Scope One Rule Instead of Opening ICMP

Identify the adapter and its current category before writing anything, because both appear in the scope you are about to set. That alias is the Windows interface name, which is not necessarily the name of the VPN profile you imported. The commands below list what exists, then preview a scoped rule without applying it.

Get-NetConnectionProfile
Get-NetAdapter | Where-Object Status -eq 'Up'
New-NetFirewallRule -DisplayName "VPN server echo" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 10.63.0.1 -InterfaceAlias "Office VPN" -Profile Private -Action Allow -WhatIf

ICMPv4 type 8 is the echo request, the only message the server needs answered. Scope it to the server's tunnel address and to the tunnel interface, and leave the profile as whatever the adapter really is. Relabelling a network to fit an example is a separate change with consequences of its own.

What the Rule Does Not Cover

IPv6 echo is a different protocol with a different message type, so an ICMPv4 rule says nothing about it, and a tunnel carrying both families needs its own rule for the other one. Nor does this rule open anything else: RDP, file sharing and every other service still depend on their own policy. That is the whole point of scoping one narrow rule instead of enabling a broad ICMP allowance. The broad allowance is the easy fix and the one that survives longest, because nobody notices it afterwards.

On a managed device the rule can be replaced at the next policy refresh, so the policy owner has to make the equivalent change rather than a local administrator. Write the intent into the ticket as well as the command, because a refresh will erase the command and leave the requirement intact. The two are not the same artefact, and only one of them survives.

Read the Result in the Right Direction

After the rule applies, ping from the server and confirm that a reply reaches the client, then ping from a source that should still be excluded and confirm that it does not. Repeat the reachability test on the other address family if the tunnel carries one.

Get-NetFirewallRule -DisplayName "VPN server echo" | Get-NetFirewallAddressFilter
ping 10.63.4.17
ping -6 fd00:63::17

Printing the rule that took effect is more useful than trusting the command that created it, because a preview and an applied rule are different states. If the address filter shows the source you intended and the excluded source still times out, the rule does exactly what its scope says. A successful client-originated ping would never have demonstrated that, which is why the direction of each test belongs in the record beside its result. Keep both directions in the ticket, or the next reader will repeat the test that cannot fail.