169.254 across a VPN: the address was never routable
A link-local destination is dropped before it reaches the tunnel, so adding routes only widens the failure. Choose between fixing the subnet and bridging.
You add the route, the tunnel comes up, and the ping to the far side still dies with total loss rather than "network unreachable". That difference matters, because it points away from your routing table and toward the address itself. A 169.254 destination is link-local, and link-local scope ends at the first hop by design, not by misconfiguration.
The decision that follows is narrow and worth making explicitly: repair the server-side subnet, or extend the Layer 2 segment so the address becomes locally meaningful again. Everything else, including adding a wider route, is a way of making the same failure apply to more destinations.
The address is not unrouted, it is unroutable
Link-local IPv4 addresses are self-assigned when nothing better answers, which is where the automatic private addressing behaviour comes from on Windows and the equivalent fallback comes from on other systems. The range is in use on every link simultaneously, which is exactly why it works: two hosts on the same segment can talk without any coordination.
That same property is why a router must not forward these packets between networks. Receiving a packet addressed to a link-local destination and sending it out another interface would create ambiguity, because the sender's "local" and the receiver's "local" are different places. There is no lookup that could settle which of the two the sender meant. Forwarding is not a policy choice an administrator can enable here; the address class excludes it.
So a gateway that installs 169.254.1.10 as reachable through the tunnel is asking the kernel to do something the address format forbids. The packet is discarded well before it reaches the remote host, and no amount of route specificity changes that outcome.
Why a tunnel makes the scope problem visible
A TUN interface carries IP packets between two peers and has no shared segment behind it. There is no broadcast, no ARP for the far side, and no neighbour discovery that could resolve a link-local destination into a link-layer address. Even if forwarding were permitted, the client has no way to learn which peer should answer.
The symptoms line up neatly once you know what to look for. The route exists in the table, ping reports complete loss instead of an unreachable network, and the neighbour table shows an incomplete or failed entry for the destination. A capture on the tunnel shows the packet leaving, which sends people looking at the far end rather than at the address class.
On Windows there is a second, unrelated-looking symptom with the same root: an adapter left with only a link-local address has no usable gateway, so network identification cannot classify the connection and the firewall profile lands on public. The tunnel is not the cause; the address is.
Decide with three questions
The choice between repairing the subnet and bridging the link turns on three conditions, and any one of them can settle it before you open a configuration file.
| Question | If yes | If no |
|---|---|---|
| Can the far-side host be given a routable address? | Change the host or fix DHCP and route normally | Continue to the next question |
| Does the device accept a static address at all? | Assign one from the site's real prefix | Bridging is the only remaining option |
| Can you accept broadcast crossing the tunnel? | A bridge is viable for a small segment | Replace the device or accept no remote access |
Most cases stop at the first question. A host showing a link-local address usually means DHCP did not answer, a cable or VLAN is wrong, or somebody typed the address by hand. Repairing that is cheaper than any tunnel work, and it removes the problem for every future client rather than for this one. It also leaves the site with a working DHCP scope, which is the thing you actually wanted.
Check the server side before you assume anything. Run ip addr show and ip route on the host, and arp -n or route print -4 on the client, so you can see whether the prefix exists at all or whether a stale entry is the only thing claiming it does.
What a bridge costs when it is the right answer
Bridging a physical adapter with a TAP adapter makes the remote client part of the local broadcast domain. Broadcast and neighbour discovery then work, and a link-local address becomes meaningful again because the client is genuinely local to that link.
The costs are real and should be quoted before anyone agrees. Broadcast traffic crosses the tunnel, the client is exposed to the local segment for every purpose rather than only the services it needs, and the server must now forward frames instead of routing packets. That is a reasonable trade for a lab bench or a device with no routable configuration path, and a poor default for remote access.
When you do bridge, both halves are required: the bridge on the server, and a route in the client profile telling it which destinations live on the far side. A bridge alone leaves the client guessing, and a route alone cannot fix an address class.