ICMP Redirects vs Your VPN Routes: What Actually Changes

A flow that should cross the tunnel takes a different next hop, and someone finds an ICMP redirect in a capture. That is a hypothesis, not a diagnosis. A redirect is a router's suggestion about a better next hop, and whether the host acts on it depends on settings that differ by platform, by interface and by address family.

A redirect is a suggestion from a router

IPv4 ICMP redirects have their own message type and a narrow set of conditions: the router forwards a packet out of the interface it arrived on, and it knows a next hop on that same link that is closer to the destination. It then tells the sender to use that next hop directly. The message names the new gateway and includes part of the original packet so the sender can match it to a flow. It is a courtesy message about local topology, and it assumes the sender shares a link with the suggested gateway.

The sender is free to ignore it. Nothing in the protocol requires a host to change its table, and a captured redirect proves only that a router sent one.

That distinction is where most redirect investigations go wrong.

IPv4 and IPv6 deliver it differently

IPv6 has an analogous mechanism inside neighbor discovery rather than in ICMPv4, with different message formats and different validation rules. The concepts rhyme and the packets do not. A capture filter written for ICMP type 5 will show nothing on an IPv6 network, which sometimes gets read as evidence that no redirect occurred.

The policy knobs are separate as well, so a host can accept IPv4 redirects and ignore IPv6 ones, or the reverse.

Check both families if the flow in question could use either.

Acceptance is a host policy, not a network fact

On Linux, redirect acceptance is controlled per interface and globally, and the defaults differ between host and router roles. A tunnel interface that accepts redirects is a strange design, since there is no meaningful same-link alternative next hop inside a point-to-point tunnel. That makes the setting worth reading rather than assuming.

Secure-redirect settings further restrict which gateways may be believed.

If you are tightening a host, those are the knobs to review, and they are also why two machines on the same network can behave differently. Change them as policy, not as a debugging shortcut.

What a redirect cannot explain

Specific routes, policy routing rules and local interfaces explain most unexpected paths without any redirect at all. A more specific prefix, a rule matching the source address, or a second default in another table will each override the route you expected. Check those first, because they are deterministic and visible.

Stale captures are the other trap, since a client that changed networks has a different local gateway.

An old redirect from the previous attachment explains nothing about the current path, so record which interface receives the control traffic now.

Check the route before you blame the tunnel

Ask the kernel which route it would use for the destination, then compare that with the table you intended. If the answer matches the table, no redirect changed anything and the investigation belongs elsewhere. If it does not match, look for a cached redirect, a policy rule or a second table before assuming the tunnel is at fault. The lookup is the ground truth, and everything else is a story about how it got there.

A redirect should never be the reason a protected path silently becomes an unprotected one, which is why acceptance policy belongs in the design review. The RFC 792 definition remains the reference for what the IPv4 message is allowed to say.

Write the route lookup and the capture timestamp together, and the next person can reproduce your conclusion.