Windows VPN Installed, Linux Boot Has No Network: What to Check

You install a VPN in Windows, reboot into Linux, and the wired connection is dead. The obvious story writes itself: the VPN left something behind. The story is wrong, because the two boots run separate kernels with separate drivers, separate routing tables and separate resolvers. A Windows network filter does not execute inside Linux, so the fault is either in the Linux stack or in something both boots genuinely share, such as hardware, firmware or the router.

The symptom and the wrong conclusion

The useful part of the observation is timing: the failure appeared after a change. The useless part is the causal leap to the Windows VPN, which cannot run in the other operating system. Separating the two is the whole job. Write the timeline down before you touch a cable.

What both boots do share is the physical adapter, the cable, the switch port and whatever sits upstream. Those are real shared variables, and they deserve a check after the Linux stack has been inspected.

Snapshot the Linux stack in four commands

Start read-only and capture state before changing anything: ip -br link for interface presence, ip -br address for addresses, ip route for IPv4 routes and ip -6 route where IPv6 matters. The ip utility reference distinguishes these objects, and an interface appearing in the list is not proof that it has a working address or a usable route.

Save the output to a file so you can compare it with a working boot later. A snapshot you cannot reproduce is only a memory of a state.

Is it link, address, route or name?

Four different failures look similar from a browser. The device may be missing entirely, present without carrier, linked but without its expected address, or addressed with no route to the destination. Name resolution failing while raw addresses work is a fifth case, and it belongs to the resolver rather than the driver.

Each case points at different work: driver or firmware for a missing device, cabling or switch for no carrier, DHCP or static configuration for a missing address, and routing or policy for a missing path. A resolver problem points at systemd-resolved, NetworkManager or a local DNS configuration.

Check whether the Linux installation has its own VPN or persistent firewall configuration. A local tunnel or nftables rule set is a Linux-side owner, and it is far more likely to explain the failure than a Windows program that is not running.

Then compare the boot transition

Windows Fast Startup is a hybrid shutdown that retains kernel session state instead of performing a full boot. Microsoft's power-state documentation distinguishes it from a restart and from a full shutdown, which is why the same hardware can behave differently across the two transitions.

If the failure depends on moving from one operating system to the other, compare a documented restart or full shutdown against the normal path, after saving work. A result that follows the transition justifies examining driver, device or firmware state, and it does not by itself prove that Fast Startup caused a particular adapter failure.

Record which OS used the adapter last, the transition type, the Linux link state and the first operation that failed. A repeatable cold-start versus warm-transition difference is worth far more than removing VPN software from both installations without knowing which stack broke.

What not to change

Do not reset both network stacks as a first move. That destroys the comparison and often fixes nothing, because the actual owner was never identified. Do not reinstall the Windows VPN to repair Linux, and do not change firmware settings at random because a boot transition correlated with a failure.

The ip utility reference documents the link, address and route objects used above. Read the Linux side first, keep the snapshot, and only then decide whether the shared hardware layer is worth investigating.