Ping Through a VPN: Why Echo Reply Rules Miss the Return Path

Ping a host across a VPN and the request leaves as one ICMP type and returns as another, which is enough to confuse any rule written in terms of ports. There is no destination service port in an echo exchange to copy into the return rule, and a filter that expects symmetry will drop the reply while the request sails through. The fix starts with reading the packet as it actually is, then deciding which boundary in the path is making the decision. Two layers are usually working while the third silently drops the reply. The sections below separate them in the order a packet meets them.

The packet changes type, not port

An echo request is ICMP type 8, code 0, carrying an identifier and a sequence number. The reply is type 0, code 0, with the same identifier and sequence, and the IP endpoints swapped. RFC 792 defines those fields, and the identifier is what lets a sender match replies to its own requests.

What is absent is just as important: there is no TCP or UDP header, so there is no port to permit. A rule that names a port for an echo reply describes a packet that will never exist. This is the single most common mistake in VPN ping tickets. The rule looks specific, applies to nothing, and leaves the failure exactly where it was.

Three contexts decide the packet

If the ping targets a host on the far LAN, the request must be forwarded by the gateway. If it targets an address that belongs to the gateway itself, it terminates in the local input path instead. If the gateway originates the ping, the packet starts in its own output path and never crosses the forwarding decision at all.

Those three contexts have different rule chains and different counters, and treating them as one is why "the firewall allows ICMP" can still produce a failed ping. The outer tunnel is a fourth context: permitting the VPN listener does not automatically permit the decapsulated inner request, and an inner allowance says nothing about whether the outer tunnel is up.

Stateful and stateless filters handle the reply differently

A stateful firewall that saw the request leave can associate the reply with that flow and admit it without a second rule. A stateless filter has no such memory, so the return direction needs its own explicit allowance, with the source and destination reversed.

Check which model the product actually implements before writing anything. A rule for echo request does not necessarily cover echo reply, and a product that tracks ICMP queries may still apply a different policy to replies that arrive on another interface.

Scope whatever you permit. Allowing every echo reply from anywhere is not the same as completing a stateful association, and a type number does not authenticate the sender.

Translation changes the identifier too

If source translation is intentional, the tuple at the far end does not match the one the client sent. A NAT can translate the ICMP query identifier along with the addresses, so insisting that the same number appear on both sides produces a false mismatch.

Correlate the mapping the translator reports instead. A translator that rewrites the identifier will not preserve the number your client logged, so treat the mapping as the identity rather than the number. Then follow one identifiable request through the path: confirm it reaches the destination with the expected source, confirm the destination emitted a reply, follow that reply's route back, and confirm the client received it rather than merely watching a gateway counter rise.

Do not fold ICMP errors into the echo policy

A fragmentation-needed message used by path MTU discovery is not an echo reply, and its payload quotes the packet that triggered it. An echo-only allowance that quietly discards those errors turns a size problem into a hanging connection, which is the opposite of helpful.

The same caution applies to address families. ICMPv6 uses different message types and carries essential functions that IPv4 does not, so copying these numbers into an IPv6 rule is simply wrong.

When the echo exchange works, test the real application separately. A successful ping proves one protocol's round trip at one size to one destination, and it is not a licence to assume HTTPS, SMB or every other flow is permitted.