FIPS Kernel Swap Took the Wi-Fi and VPN Modules With It

Enable fips-updates, reboot, and the machine comes back without a wireless interface while the VPN client refuses to start because its kernel module is absent. Nothing was uninstalled in the ordinary package sense, which is why reinstalling the client changes nothing at all. The machine is running a kernel its drivers were never built for. Two symptoms, one cause, and the cause shows up in a single command.

What the reboot actually switched

Ubuntu Pro's FIPS updates install a certified kernel variant and make it the default boot entry. That variant is a real kernel: it boots, it runs, and it starts the services you already had. What it does not contain is every module built for the generic kernel, including a wireless driver compiled out of tree and a tunnel module delivered through DKMS. The driver set moves with the kernel, not with the package manager. So the hardware is still present and the software that talks to it is not.

Compare the running kernel against the installed packages before you open any network setting. The version string carries a marker the generic kernel does not have, and that one detail accounts for both missing pieces.

Read the boot entry too, because a machine can have the certified kernel installed without running it. In that case the module story is completely different, and the ports and drivers you were about to reinstall are fine.

Read the module state before the client configuration

A module that cannot be found and a module that exists but refuses to load are different faults with different fixes. modinfo reports which one you have, and lsmod reports what is loaded right now. Do both before touching the VPN client's configuration, because the client's own error rarely separates them.

Wireless needs the same split. An interface that never appears points at the driver, while one that exists but stays blocked points at rfkill or at the network manager. Those two look identical in a desktop applet and share nothing underneath.

Run the checks on the machine itself while the fault is still reproducible. Output pasted from another host is not a substitute for this one.

uname -r
pro status --all | grep -E 'fips|kernel'
modinfo wireguard 2>&1 | head -3
rfkill list

When modinfo cannot find the module at all, reinstalling the userspace package will not help, because userspace was never the missing part. That observation saves an hour of package churn and points straight at the kernel.

Roll back in an order that leaves you a kernel

If FIPS was enabled by mistake, the documented recovery path disables the service, purges its packages and then restores the generic kernel. The order is not cosmetic. The purge refuses to continue when it cannot find another Ubuntu kernel, because removing the only one would leave a machine that cannot boot. That check is the difference between a rollback and a rebuild. It is also the reason the sequence fails when the generic kernel was already removed.

Run it while the generic kernel is still installed, accept the warning about removing a kernel, and reboot afterwards. Then confirm that no FIPS package remains in the installed state and that the running kernel is the one you expected.

On a remote host, arrange console or out-of-band access first. Removing a kernel over SSH is fine right up to the reboot that does not come back.

dpkg -l | grep -E 'linux-image|fips'
sudo pro disable fips-updates --purge
sudo apt install --reinstall linux-generic
sudo reboot

When the certification is the requirement

Rolling back is the wrong move when the certification is contractual, because the machine then leaves the configuration the audit describes. In that case the driver gap is a hardware selection question: pick a wireless adapter whose driver ships with the certified kernel, accept a wired-only machine, or move the tunnel to a component the certified kernel already supports.

Building an out-of-tree module into the certified kernel is not a neutral workaround. It changes what the kernel executes, and that is precisely the property the certification describes.

Record the decision with the owner's name next to it, because the request to just make the Wi-Fi work will return in a few months with less context. A short note now prevents the same argument later.

Check the stack in layers after the change

After the rollback or the hardware change, verify from the bottom up instead of from the VPN client down. The interface has to exist, the link has to be up, the resolver has to work, and only then does the tunnel matter. Each layer fails with its own message, and reading them in order keeps the diagnosis honest.

Leftover DNS state from the previous boot is a common false positive, so read the resolver before concluding that the tunnel broke.

nmcli device status
ip -brief link
resolvectl status | head -12
systemctl --failed

If the tunnel still fails once the kernel is back, read the failing stage rather than the client's summary line. A module that never loaded, a certificate the peer rejected and a credential the server refused are three separate problems, and a reboot will not tell them apart on your behalf. Capture the stage name in the ticket, and the next engineer starts where you stopped.