Every Linux user knows the feeling: the network is gone, error messages are piling up, and the temptation to wipe the system and start from scratch is strong. But sometimes the best solutions are not full restores — they’re small, precise fixes, discovered through patient troubleshooting.

This story revolves around a WireGuard client setup, configured not for a commercial VPN service but for a private remote VPN server. The client’s role was essential: all traffic from the workstation needed to pass through that tunnel, with a killswitch in place so that if the VPN was down, no packets could leak out to the open internet.

The Setup

The system used WireGuard’s wg-quick tool with a configuration file, client1.conf, stored in /etc/wireguard/. To enforce the killswitch, nftables rules were written into /etc/nftables.conf to drop all outgoing packets by default, except for loopback traffic, replies to established connections, the handshake packets to the VPN server’s IP and port, and any packets routed through the client1 interface once the VPN was up.

The intended behavior was three clear states: Boot Safe (VPN down, killswitch active, no outbound traffic), VPN Up (tunnel established with “wg-quick up client1,” traffic flowing securely through the private server), and Open Net (VPN down and killswitch disabled, so traffic goes out over the ISP directly when needed).

The Problem

At some point, the carefully maintained firewall rules were overwritten by an empty ruleset. Initially this wasn’t catastrophic — wiping the rules temporarily restored connectivity. But then WireGuard began refusing commands with the dreaded:

client1 is not a WireGuard client

Connectivity was lost, and the system seemed unusable. Frustrated, the decision was made to reinstall from backup.

The Backup

The backup was thorough: the root filesystem saved to a directory, a copy of the LUKS header from the encrypted system partition, and the partition table recorded by sfdisk. From these, a full restore would be possible.

Booting into a live session, the plan was to wipe the internal disk and rebuild. But before committing to that drastic step, another idea arose: why not try one more repair from within the live session using chroot?

Into the Chroot

The root partition of the home system was mounted, the necessary directories bound, and a chroot opened. Suddenly, the commands being typed were affecting the installed system as if it were booted.

Inside this environment, the troubleshooting process began anew. client1.conf was still present, complete with keys and server settings. WireGuard state was cleared with “wg-quick down client1” and “ip link delete client1.” The firewall was flushed with “nft flush ruleset.” The VPN was brought up again with “wg-quick up client1,” and the killswitch reloaded with “nft -f /etc/nftables.conf.”

A Remarkable Discovery

The chrooted system connected to the internet — not through the live OS, but through the mounted home system and its WireGuard tunnel. The live kernel was carrying traffic for the chroot, effectively proving the repaired VPN before a reboot. This was unexpected, and remarkable to observe.

The Mishap

Then came the mistake. The nftables rules were reloaded inside the chroot. Because nftables operates globally at the kernel level, this action cut off networking in the live OS entirely. The connection dropped.

At first this looked like another failure, but on reflection it was a lesson: changes to firewall rules inside a chroot apply to the running host kernel, not just to the mounted system.

Reboot and Final Testing

After rebooting into the home system itself, the tests were repeated. With the VPN down, traffic was blocked as intended. With “wg-quick up client1,” the VPN came up and traffic flowed securely. With both the VPN and killswitch disabled, connectivity returned over the ISP directly.

The three intended states were restored.

Lessons Learned

The path from panic to recovery demonstrated several important truths. A full backup provides peace of mind, but it does not mean that reinstalling should be the first response. Even when the system appears broken, configs may still be intact and recoverable. Chroot is not only a rescue tool but also a way to test and repair live configurations, even to the point of tunneling network traffic through the mounted system. Firewalls operate at the kernel level, so one must remember that changes inside a chroot affect the entire running environment. Most importantly, troubleshooting in steps — verifying configs, clearing stale state, reloading the VPN, and then restoring the killswitch — can return a system to stability without the cost of a full rebuild.

What began as frustration ended as confidence: the VPN was restored, the killswitch was reliable, and the system once again obeyed its intended design. Sometimes the most elegant solution is not to reinstall, but to understand, repair, and carry on.