Why Adapter Order Does Not Decide Your Lab VPN Route

Adapter 1 being first in the hypervisor's list is a display order, and the guest's routing table does not read it. What decides the path is the prefix, the metric, and any policy rule that applies before either. Adding a bridged adapter to a lab VM can therefore create a second default path while the old NAT interface still shows as present and numbered second. The result is a VM that sometimes uses the tunnel and sometimes does not, with no configuration change to explain it.

Three conditions decide the path

The three conditions are which prefix is more specific, what the metrics do when prefixes tie, and which rules the guest applied after the hardware edit. Each is answerable with one command, and none of them involves the hypervisor's numbering.

That last point is the decision: if you cannot state which prefix wins for the VPN endpoint's own address, you do not have a routing policy, you have a topology that happens to work today.

Condition one: which prefix wins

A route to 10.8.0.0/24 beats a default route for an address inside it, regardless of metrics and regardless of adapter order. This is why a VPN client that installs a specific route keeps working even when a second adapter appears with a lower metric: specificity wins before cost is considered. Check with ip route show for the table you think is in use, and ip route get 203.0.113.9 for the answer the kernel would actually give for a specific destination.

The endpoint's own address is the test that matters most. If the VPN server's address resolves through a newly added bridged adapter, the tunnel may never establish, or it may establish and then lose its own transport path. Query that address specifically rather than assuming the tunnel interface is the answer.

Condition two: what the metric does and does not do

Its role is narrower than most people expect. Metrics break ties between routes to the same prefix; they do not let a broader route beat a more specific one. A lower number is preferred within a tie, and different operating systems count in opposite directions, which is why advice copied between Linux and Windows often contradicts itself.

In the guest, ip route show prints the metric next to each route, and Get-NetRoute on Windows prints an InterfaceMetric plus a route metric. Read both, because the effective preference can be a sum rather than a single field. If two default routes exist, that is the finding: the guest has two ways out, and which one wins is a function of numbers that a hardware edit can change.

Condition three: what the guest actually applied

Configuration is not the same as applied state. Interface names are not stable across hardware edits on every platform, and a configuration that matched on a name may now apply to nothing.

Check the applied state rather than the intended one. ip -br link shows the interfaces that exist now, and on a NetworkManager host nmcli connection show shows which profile is bound to which device. A profile that failed to bind leaves the interface up with no addressing, which looks like a routing problem and is a naming problem. Restored snapshots make this worse, because the guest's saved state may reference adapter identities that the new hardware no longer provides.

Keep the lab topology reproducible

Save the intended virtual network attachments alongside the guest configuration, so the mapping from role to adapter is written down rather than inferred from a list position.

Four roles are usually enough to name: private link, management, outside transport and tunnel. Each should map to a specific adapter and a specific guest interface, in a file.

Then test the actual application after a hardware edit, a restart or a restored snapshot, and include the route to the VPN endpoint in that test. If a gateway VM is meant to be the only exit, verify that the test VM has no unintended second default path, because a second default is exactly what a bridged adapter adds. Test from the guest, not from the hypervisor console, since the two can disagree about which interface is which.

The VirtualBox networking documentation describes the adapter modes and what each one attaches to, which is the part worth reading before adding a second one. A lab that identifies which adapter serves each role makes a route change explainable. A lab that relies on the hypervisor's numbering makes every change an experiment.