Linux EHOSTUNREACH with OpenVPN: which next hop failed?

EHOSTUNREACH is a local decision as often as a remote failure. The kernel can reject a packet because a route says the destination is unreachable, because the Ethernet next hop never answered, or because an ICMP host-unreachable report arrived from further along the path. Each source lives in a different table or cache, and each is fixed in a different place. Read the selected route and the next-hop state before you touch ciphers or reinstall the tunnel.

Pick the address and namespace the client actually uses

Start by pinning the destination and the network namespace that produced the error. A VPN client may run in its own namespace, and a lookup from the default one consults a different routing table with different policy rules.

The lookup must use the same source, mark and table context as the failing application, or it may answer a question nobody asked. For an illustrative IPv4 peer, the read-only checks are:

ip -4 route get 198.51.100.25
ip -4 neigh show 198.51.100.1
ip -4 route show table all | grep -w unreachable

A result from an administrative shell proves only what that shell would do. If the client sets a firewall mark or binds to a VRF, repeat the lookup with the matching mark or inside the VRF, and compare the selected route and next hop. The first address to confirm is the peer address in the profile, not the cluster or service the user names.

An explicit unreachable route rejects the packet locally

A route of type unreachable is a deliberate local answer. It tells the kernel to discard the packet and return EHOSTUNREACH to the sender, which is why the error appears instantly and without any traffic leaving the machine. Someone, or some automation, put that route there on purpose.

The route types are not interchangeable. Blackhole drops the packet without an error to the sender, prohibit returns EACCES, and unreachable returns EHOSTUNREACH. A VPN helper that installs a sink route during reconnect can therefore produce a burst of host-unreachable errors that disappear once the tunnel is up, while a blackhole route would produce silent timeouts instead.

Search all tables for the type before blaming the remote end. The rule that selects the table matters as much as the route inside it, and a route added to the main table will not help a client whose policy rule sends its traffic elsewhere.

A dead neighbor produces the same error on Ethernet

When the selected route uses an on-link gateway, delivery needs a resolved link-layer address. The kernel sends an ARP or IPv6 neighbor solicitation, and if no reply arrives the packet cannot be framed. The send then fails with EHOSTUNREACH even though the route itself is valid.

The neighbor table names the stage. INCOMPLETE means a resolution is still in progress, FAILED means the last attempt got no answer, and REACHABLE or STALE means the kernel has a usable address. A FAILED entry for the VPN gateway is a local delivery problem, not evidence about the far side of the tunnel.

Read the entry for the actual next hop, not for the remote internet address. A remote address is normally reached through a router, so it will not have its own ARP record; asking for one is a category error that sends people looking for a missing entry that was never supposed to exist.

Remote reports and asynchronous UDP errors

EHOSTUNREACH can also arrive from outside. A router that cannot forward the packet may send ICMP host unreachable, and the kernel passes that report to the socket that owns the flow. In that case the route and neighbor are fine, and the failure belongs to a hop beyond the local network.

UDP makes attribution harder. An error returned by a later send or receive call can refer to an earlier datagram, so the address and time of the failing call may not match the packet that triggered the report. A connected UDP socket receives the error once, and an unconnected socket may never see it at all.

That is why timing belongs in the evidence. Note when the error appeared, which peer address the socket used, and whether the tunnel had just reconnected. A burst right after a route change points at the local table; a single error minutes into a stable flow points at a path report.

Separate the layers before changing crypto

Three questions classify the error. Did the kernel choose a route that rejects the destination? Did it choose a valid route but fail to resolve the next hop? Or did a report arrive from beyond the local network? Only the third case can implicate the tunnel's far end, and even then it does not implicate encryption.

Authentication and negotiation problems surface as their own errors after the transport reaches the peer. Changing a cipher or reinstalling the client cannot fix a local unreachable route, and it destroys the route and neighbor evidence you would need for the real cause.

Record the destination, namespace, selected table, next hop, neighbor state and error time before the first change. Rerun the same lookup after the fix; a route that now points at the tunnel and a neighbor entry that now resolves are stronger proof than a successful ping to an unrelated address.