Or: how I almost locked myself out of my own EC2 box, and the guard that fixed it.
I needed one process on a box in us-east-1 to egress through a WireGuard peer in a different geographic location. Everything else on the host had to keep behaving normally: SSH from my laptop, SSM from the AWS console, the package manager, the metrics agent. The host was fine where it was. Only this one workload needed a different exit.
The obvious move is wg-quick up on the host with your provider's config. Don't do that. WireGuard's default AllowedIPs = 0.0.0.0/0 rewrites the host's main routing table, which means every outbound packet now goes through the tunnel, including the SSH session you're typing into. If the tunnel doesn't fully come up, or if the peer can't reach you back on the new path, you've just dropped yourself off the network. On a VM with no serial console enabled, you're calling support.
So the actual question is: how do you scope a tunnel to a single process and guarantee the host's networking is untouched?
The wrong answer: policy routing
If you've spent any time in Linux networking, your first instinct is ip rule: mark packets from a specific user or cgroup with iptables -j MARK, then ip rule add fwmark X lookup vpn-table, then put a WireGuard default route in that table.
It works. It's also fragile in ways you only discover later. You're modifying the kernel's routing logic for everyone, then trusting that your mark-and-route rules will only catch the traffic you meant to catch. The first time NetworkManager restarts, or someone flushes iptables, or a future-you adds a rule that conflicts at a higher priority, you've got a leak. You probably won't notice until production. Debugging it means staring at ip rule show, ip route show table all, and conntrack output, swearing.
There's a cleaner primitive.
The right answer: network namespaces
A network namespace is its own independent copy of the kernel's networking stack: its own routing table, its own iptables, its own interface list. Processes inside see only that stack. Processes outside don't see it at all.
So the model is:
The host's root namespace doesn't change. Default route via eth0, SSH on its usual path, no ip rule shenanigans. A separate namespace, egress, has its own default route through a WireGuard tunnel, and only processes I explicitly drop into that namespace use it. A veth pair bridges the two, with one end in each namespace, on a small underlay subnet (10.200.0.0/24). The host masquerades that subnet out its normal interface.
Root namespace (control plane) egress namespace (egress plane)
eth0 -> Internet (untouched) wg-egress -> WireGuard peer -> Internet
\ /
veth underlay (10.200.0.0/24)
WireGuard lives inside the namespace, full-tunnel, AllowedIPs = 0.0.0.0/0. From inside the namespace, everything goes through the tunnel. From outside, nothing changed. Verification is two lines:
ip netns exec egress curl -4 ifconfig.me # the peer's IP
curl -4 ifconfig.me # the AWS Elastic IP
That's the whole pattern. The control plane stays on its native AWS path; the egress plane lives somewhere else entirely. Logical presence wherever the peer is, physical stability in us-east-1.
One detail that bites people: once WireGuard installs its 0.0.0.0/0 route inside the namespace, that route also tries to catch traffic going to the WireGuard endpoint itself, which is a routing loop. The fix is a /32 route for the endpoint's public IP via the underlay gateway, installed after the tunnel comes up. Three lines of ip route and easy to forget, and when you forget you spend forty minutes wondering why your handshakes silently fail.
Then I almost bricked the server
This is where it gets uncomfortable.
wg-quick is almost namespace-native. You run it under ip netns exec and most of the time it does the right thing: interface comes up inside the namespace, default route lands in the namespace's routing table, everyone goes home.
Most of the time.
First time I built this, on the EC2 box, over SSH from my laptop: something in my wireguard.conf (I never fully chased it down, probably a PostUp hook interacting badly with how Ubuntu patches wg-quick) caused the WireGuard interface to come up in the root namespace instead of the egress one. The 0.0.0.0/0 route landed on the host. My SSH session was suddenly trying to exit through a tunnel that had no return path back to my laptop. Frozen terminal. No response to anything.
I got lucky. SSM Session Manager was enabled on that instance, I got in through the AWS console, ran ip link delete wg-egress, watched the host's default route restore itself, and my heart rate came back down.
The fix is now the most important code in the repo: a host-integrity guard wrapped around wg-quick up. It does three things.
Before the tunnel comes up, if the WireGuard interface already exists in the root namespace, refuse to do anything. Something already went wrong on a previous run; don't make it worse. Then snapshot the host's IPv4 default route as a string, immediately before invoking wg-quick. After wg-quick returns, check two invariants: the WireGuard interface is not in the root namespace, and the host's default route is byte-identical to the snapshot. If either check fails, tear the tunnel back down and exit non-zero.
HOST_DEFAULT_BEFORE="$(ip -4 route show default | head -1)"
ip netns exec "$NS_NAME" wg-quick up "$WG_CONF"
if ip link show "$WG_IFACE" >/dev/null 2>&1; then
abort_rollback "ABORT: $WG_IFACE appeared in ROOT namespace"
fi
HOST_DEFAULT_AFTER="$(ip -4 route show default | head -1)"
if [[ "$HOST_DEFAULT_BEFORE" != "$HOST_DEFAULT_AFTER" ]]; then
abort_rollback "ABORT: host default route changed during wg-quick up"
fi
The guard doesn't prevent the bug. wg-quick does what wg-quick does, and the configuration that triggers the leak lives in user files I can't audit. What the guard does is detect the leak fast enough that the SSH session running the script doesn't die. The window between wg-quick returning and the next outbound SSH packet trying to use the new (broken) route is small but not zero, somewhere around a hundred milliseconds in my testing. Long enough to check, roll back, and exit with a loud error instead of leaving you locked out.
This is what turns the project from a weekend experiment into something I'd actually run on a server I care about. WireGuard-in-a-namespace as a concept has been written up plenty of times. The guard is the part that makes it safe to run on a remote host where the cost of a bad five seconds is calling support to mount your root volume on a rescue instance.
What this doesn't try to do
Worth being honest about scope.
IPv4 only. If you don't disable IPv6 in the namespace you'll leak the host's address through it; the repo does the disable for you but it's a real footgun if you fork without reading. It controls IP-layer routing. Applications that learn the host's identity through other channels (WebRTC STUN, browser fingerprinting, OS telemetry) will still leak it. You trust the WireGuard peer: encrypted to them, cleartext after. And only networking is isolated. A process in the namespace can still read your home directory and talk to your SSH agent. If you need more, layer firejail, bwrap, or a container on top.
That's the trade. Per-process egress, host networking untouched, with a guard that makes the failure mode loud instead of lethal.
The repo
Setup, scripts, docs, the guard: see ambifore-org/remote-egress. MIT licensed, a few hundred lines of bash.
If you've solved this differently (or, more useful, if you know of a wg-quick replacement that's strictly namespace-native), I'd genuinely like to hear about it.
