Why route -interface Cannot Reach an Off-Link Host

Route accepts the Wi-Fi interface name, exits without complaint, and the host stays unreachable. Nothing is corrupted; the relationship in the route is simply wrong: an interface flag says which link a destination sits on, not which router should receive traffic for a destination that lives somewhere else. The command succeeds because it is syntactically valid, not because it describes a working path.

That distinction decides whether a route exception beside a VPN will work or merely look plausible.

Interface is the exit, next hop is the handoff

On a Mac with address 192.168.50.20 and a router at 192.168.50.1, another machine on the same link can be reached directly. The frame is addressed to that machine and put on the wire. No router is involved, and an interface-scoped route expresses exactly that. Change the far end to a host in another building and the same command stops making sense. The Mac has no layer-two address to put on the wire, so there is nothing for the interface flag to describe.

A destination outside the link is different. The Mac cannot put a frame on the wire addressed to a host it cannot reach at layer two; it hands the packet to a router that can. The route therefore needs a gateway, and the gateway itself has to be reachable on the attached link.

Using the interface flag for an off-link destination tells macOS to treat that destination as if it were on the wire. The kernel then fails to resolve a layer-two address for it, and the packet is dropped with nothing useful in the error.

What the interface flag actually asserts

Apple's route reference defines the interface form for destinations that are directly reachable without an intermediary. It is a statement about the link model, not a preference about which adapter to use. Reaching an internet host through Wi-Fi still requires a router on that Wi-Fi link, and the route has to name it.

Interface scope is a separate attribute. It associates a route with a particular interface for scoping decisions such as which source address applies, but it does not create reachability for a destination that the interface cannot reach on its own. The two attributes answer different questions.

This is why a command can be accepted, appear in the table, and still fail. The kernel is not validating your intent; it is recording what you asserted, and the assertion was that the destination is on-link. A silent success followed by a silent drop is the expected outcome, not a bug. Read the assertion back to yourself before blaming the network.

The route an off-link destination needs

For an approved path to a documentation address such as 198.51.100.25 through the LAN router, the intended relationship is a destination, a next hop of 192.168.50.1, and the LAN interface that reaches that next hop. The interface is implied by the next-hop lookup rather than forced by the route command.

On macOS the read-only inspection is route -n get 198.51.100.25. Read the gateway and interface lines together and check that the gateway is an address the Mac can actually reach. A gateway on a different subnet, or one that has gone away since the last network change, produces a route that looks correct and forwards nothing.

Do not hardcode en0 in a durable instruction. Interface names change with adapters, docks, and VPN clients, and a route that names the wrong one fails in a way that is easy to misread as a broader network fault.

Read the current choice before replacing it

Before adding anything, inspect what the system already selected and why. That output tells you whether traffic is going through the tunnel, through the LAN router, or nowhere, and it gives you a baseline to compare after the change. Without it, you cannot tell whether the new route took effect.

Then check the address family. A route added for IPv4 does nothing for an IPv6 destination, and a service that resolves to both families can appear intermittently reachable. The route table and the resolver answer different questions, and both need to agree with the intended path.

Finally, remember that a route is a selection, not a permission. A managed VPN profile or a client filter can still forbid the direct path even when the table points at it, so test with the actual application rather than assuming a successful table entry ends the investigation.

Tunnels and policy change the shape

Point-to-point interfaces are their own case. A tunnel can carry a route without an Ethernet-style gateway address, and that is not automatically wrong. Apply the interface's real link model instead of extending a Wi-Fi example to every table entry you see.

For change requests, write down the destination, the approved network path, the current gateway and interface, and who is expected to maintain the exception. The owner matters because a one-time route typed at the prompt is not a policy, and the next reconnect will erase it.

If the requirement is "reach this host while the VPN is up", the honest answer is usually a specific host route through the local router, installed by the network manager that owns the interface. If the requirement is "reach anything directly", the requirement itself needs a policy review before it needs a route command.