Vagrant VM Vanishes When the VPN Connects: Whose Route Broke

The box answered a minute ago, the VPN connected, and now the same address times out. Three faults produce that symptom, and they live on different machines. The host can lose the route to the private network, the guest's NAT range can collide with a range the tunnel now advertises, or a full tunnel can take ownership of every route on the host. Find which one happened before changing any configuration, because each fix lives somewhere else.

Watch the route, not the box

Look at the host's routing decision for the guest address while the tunnel is up. A route that still points at the host-only adapter is not the problem. A route that now points at the VPN adapter is the problem, and the client changed it rather than you. The adapter keeping its address tells you the interface survived, which is a different fact from the path surviving.

An SSH session that drops exactly at connect time is expected behaviour. The client recycles adapters and installs routes, so the connection dies for a few seconds. The fault is the connection that never comes back, not the one that blinked.

Capture the table before the tunnel and again after it, then diff those two outputs. The diff is the diagnosis, and it also happens to be the evidence a network owner will ask for.

ip -4 route get 192.168.56.10
ip -brief addr show
ip route show table main | head -20

Read the host's table before and after

On Linux the preference between overlapping routes comes from prefix length and metric, so a more specific VPN route wins even when it is wrong. On Windows the interface metric decides the tie, and the tunnel adapter usually arrives with a lower metric than the virtual one. Either way the visible symptom is identical: packets leave by the tunnel adapter and disappear.

Print the adapters and their metrics next to the route for the guest prefix. That pair of outputs answers the ownership question in one look.

Get-NetAdapter | Select-Object Name, InterfaceIndex, InterfaceMetric
Get-NetRoute -DestinationPrefix 192.168.56.0/24
route print -4 | Select-String '192.168.56'

If the route changed but the adapter metric did not, the client installed a competing route. If the metric changed, the client reordered the adapters. Both are fixable, and they are fixed in different places.

When the guest's NAT range is the collision

VirtualBox NAT uses 10.0.2.0/24 by default, and a tunnel that pushes the same range makes the guest send that traffic to its NAT gateway instead of to the real destination. The packet never leaves the host, so no firewall log on the far side will show it. Docker Machine has the same class of conflict in its host-only plan, and changing that plan can require recreating the machine along with its certificates.

Pick the replacement by listing what the tunnel already advertises, then what the office network uses, then what every virtual adapter on this host has claimed. Overlap is what breaks routing, and resemblance is irrelevant. One range can sit entirely inside another while looking nothing alike at a glance.

Set the new range when the machine is created, or change it and reload, then test the failing connection again from the guest. The guest's own table is the view that matters.

VBoxManage modifyvm devbox --natnet1 10.77.0.0/24
vagrant reload devbox --provision
vagrant ssh devbox -c 'ip route get 10.20.0.15'

Restore the path without fighting the client

Each platform offers a way to put the host-only prefix back in front. On macOS a static route to the host-only interface works until the next connect. On Windows a lower interface metric on the virtual adapter keeps it preferred. On Linux a replace operation covers a single prefix. All three are workarounds, because a client that reasserts its routes will undo them.

Script the check rather than a blind reconnect at boot. A small script that prints the route for the guest prefix after every connect turns a mystery into a line in a log.

If the profile is a full tunnel, ask the network owner for split tunnelling or a documented exception. Quietly adding routes that bypass a security policy is not a fix, it is a second problem that arrives later with an auditor attached.

Check the fix on both sides

Verify three paths after the change: host to guest, guest to the corporate host, and guest to the internet. A fix that restores one of them and breaks another is a configuration change masquerading as a repair. Capture the same outputs you collected before the change so the comparison is like for like.

Record the interface, the metric and the route that changed, together with the time, so the next occurrence is a lookup rather than a rebuild. That note is worth more than a long ticket thread.

ip -4 route get 192.168.56.10
traceroute -n -m 4 10.20.0.15
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

When the host reaches the guest again and the guest reaches the LAN, you have restored the path you started with. When only one of those works, the remaining fault is in the other owner's territory, and the diff tells you which territory that is.