Why a /32 Host Route Keeps the VPN Endpoint Reachable

A host route selects one address, not a subnet. It can keep a tunnel endpoint reachable or pin one resource, but it goes stale as addresses change.

You open the routing table after connecting and find a single address routed through the tunnel while the subnet around it still goes to the local gateway. That entry is a host route: one address, matched by a prefix of all ones. It matters because routing decisions use the longest matching prefix, so a /32 can override a /24 or a default without changing either of them. Whether that is a careful exception or a future outage depends on which address it names and who maintains it.

One Address, One Entry in the Table

An IPv4 host route carries a /32 prefix and an IPv6 host route carries /128, which means the entry can match exactly one destination address. Nothing else in the table moves: the covering subnet and the default route stay where they were. The narrow entry wins for that address because its prefix is longer, not because it was added later.

That property makes a host route a good exception and a poor habit. Two /32 entries naming a service's front door do not cover its second address, its IPv6 address, or the address it moves to next month. A table full of unexplained single-address entries usually means somebody kept patching around a subnet decision instead of making one. Read the prefix length first, then ask what the entry is supposed to protect.

Read the Entry From the Client Outward

Start at the machine with the problem, because the same address can be routed differently on a laptop and on the gateway in front of it. Ask the kernel which path it would choose for the exact address the application uses, instead of reading the table from the top. The answer includes the interface and the next hop, which together are the decision.

ip route get 203.0.113.25
ip -6 route get 2001:db8:4::25
ip route show | grep -F 203.0.113.25
Find-NetRoute -RemoteIPAddress 203.0.113.25

Repeat the query for the address family the application actually selects, since a client can prefer IPv6 and quietly bypass an IPv4 exception. Compare the result before and after the tunnel comes up, and keep both outputs. That comparison shows whether the client added the entry at connect time or whether it was already there.

A persistent entry and a runtime entry fail differently. The runtime one disappears with the session, while the persistent one survives a reboot and keeps sending traffic to a gateway that no longer exists.

The Endpoint Exception and the Recursion Trap

VPN clients commonly install a host route to the server's outer address through the original gateway before they redirect the default route. Without that entry the encrypted packets would be sent into the tunnel they are trying to build, and the connection would loop until it timed out.

The trap appears when the tunnel's accepted subnets happen to include that endpoint address, or when a second profile adds a wider route afterwards. The endpoint entry then loses to a longer prefix and the session collapses as soon as it starts passing traffic. Writing the endpoint address beside the accepted subnets is the cheapest way to notice the collision before users do. It also explains why the same profile works from one network and fails from another.

Verify the Path the Application Really Uses

A successful ping to the hostname is weak evidence when the application connects to a different address or a different family. Verify the exact tuple of address, family, port and interface, from the machine that runs the client.

ip route get 203.0.113.25
sudo nft list ruleset | grep -A 4 'chain output'
curl -sS --max-time 8 -o /dev/null -w '%{remote_ip}
' https://app.example.net

If the path is wrong, decide whether the requirement is a network or one address before editing anything. A single-address requirement justifies a host route with a comment and an owner; a service with rotating addresses needs domain-based routing or an honest subnet decision.

Remove entries that no longer map to a real destination and note the ones you keep. An unexplained /32 is indistinguishable from a bug three months later, and the next person will delete it without knowing what depended on it.

Erthyglow kevrennek