VPN on, VM unreachable? The route was probably never the problem

Connect the VPN, and the development VM that answered a minute ago goes quiet. The obvious story writes itself: the tunnel grabbed the route, the host is now sending guest traffic into the corporate network, and the fix is to add a static route or switch the adapter to bridged mode. That story is sometimes true. It is not the usual cause, and acting on it first tends to break something else.

Host-only networking is a software network owned by the host and shared with its guests, separate from any physical attachment. Nothing about a VPN client's own interface changes that network, so before you touch it, find out which of four layers actually failed.

The route is usually still local

Ask the kernel instead of the routing table's front page. On Linux, ip route get 192.168.56.10 reports the exact route, interface and source address that would be used, which is a different answer from reading a default route and guessing. If the output names the host-only interface, the tunnel is not involved in that path at all.

Two things can genuinely break it, and both are address problems rather than VPN problems. A remote subnet that overlaps the host-only prefix makes the more specific route win, and a VPN client that installs a broad route with a lower metric can pull the prefix away. Both are visible in the same command: the interface named in the output will be the tunnel, and the fix belongs with whoever owns that address plan.

Route selection and packet admission are different decisions

This is the part the mental model usually misses. Even with a perfect local route, a VPN client can refuse the packet. Many clients enforce a local network access policy that decides which destinations are allowed outside the tunnel, and a connected subnet does not automatically update that list.

So the failure looks identical to a routing problem from the application's side, and completely different from the client's side. If ip route get names the right interface and the connection still times out, stop editing routes and read the client's documented local-access behaviour instead. Some clients expose an allow-list for local subnets, some block everything that is not the tunnel, and some only block when a kill switch is enabled.

That distinction matters because the fixes are not interchangeable. Adding a route cannot satisfy a filter, and disabling a filter to reach one guest is a much larger decision than the symptom suggests.

The guest has three ways to say no

A guest that can browse the internet has proved nothing about the service you want. The listener might be bound to 127.0.0.1 inside the guest, in which case no host request can arrive no matter how good the path is. Check with ss -ltn in the guest and look at the local address column rather than only the port.

Next is the guest's own firewall. A development image with a restrictive default can accept the host's packets and drop them at the service boundary, which produces a timeout that looks exactly like a routing black hole. Finally there is the service's own configuration: a web app bound to a specific hostname, or an allow-list of client addresses, will refuse a request from the host-only subnet even when every packet arrives.

Work through those three before you consider changing the VM's network mode. Each is a smaller change than re-architecting the guest's attachment, and each has a clear test.

What a bridge really is, and what it costs

Switching the adapter to bridged mode is not a repair of the host-only path. It is a decision to put the guest on a different network, usually the physical LAN, where it becomes visible to whatever else lives there. That may be exactly what you want. It is not what the original configuration was doing.

Use it when the guest genuinely needs to be a peer on that LAN and the exposure is approved. Do not use it because a single service stopped answering, since the change can move the guest out of the isolation that made it safe to develop against in the first place.

After any approved correction, test in a fixed order: a fresh host-to-guest request, a required corporate resource through the tunnel, and the intended denied behaviour with the tunnel down. If the last one no longer holds, the correction went beyond the problem.

The VirtualBox host-only networking section describes the host-side software interface and how it differs from a bridged attachment, which is the reference worth reading before assuming the two modes are interchangeable.