Ubuntu, k3s, and Airvpn Suite

[Titums 3]

I've got an Ubuntu 24 server hosting a k3s node.  The node mostly servers local media services.  There is one website exposed externally via a cloud flair tunnel pod.  This all works and is great.  

I'd like to have airvpn up and running and guarding FireFox and BiglyBT traffic (installed on host os).  When I activate network lock through bluetit, any pod that doesn't use hostnetwork:true is no longer accessible.  They are running, but I just can't get to them.  I've spent a lot of time with Claude and can't get it working right.

Is it even possible to get this working?
Is there another/better way to get this working that would be better?

[Staff 10693]

Hello!

With Bluetit's network lock active, this cannot work, but there is a different approach that is well worth trying.

Why the pods become unreachable: Bluetit's network lock is a kill switch for the whole host. It sets the default policy of the FORWARD chain to drop and only accepts forwarded traffic coming from the VPN tunnel. Pods that don't use hostNetwork are reached through forwarding (LAN or ingress, then NAT to the pod address on the cni0/flannel interfaces), so their traffic is dropped, while hostNetwork pods use the host's own input/output path and keep working. The "allow private network" exception only covers input and output on the host, not forwarding, and when the lock is applied Bluetit replaces the whole firewall ruleset, k3s rules included. There is no Bluetit option to exempt container interfaces or forwarded traffic.

The better approach is to turn it around: leave the host and k3s outside the VPN, and put only Firefox and BiglyBT inside it, in a dedicated network namespace whose only way out is a WireGuard interface. If the tunnel goes down, the applications in the namespace simply have no network, so you get a kill switch by design without touching the host firewall, and k3s, the Cloudflare tunnel and your LAN are not affected at all.

Please note that this is a suggestion we believe is worth a try, but we have not tested it on a setup like yours, so treat it as a starting point and let us know what happens.

1. Generate a WireGuard configuration file with our Configuration Generator (Client Area > Config Generator, Linux, WireGuard, one specific server) and save it, for example, as /etc/wireguard/airvpn.conf. Take note of the Address, DNS and MTU lines in its [Interface] section. Stop Bluetit or at least disable its network lock.

2. Create the namespace and the tunnel, as root and in bash (the wg setconf line uses a bash feature that plain sh does not support). The WireGuard interface is created and configured in the main namespace, so its encrypted UDP traffic leaves through your normal connection, and then it is moved into the namespace:
 

ip netns add vpn
ip -n vpn link set lo up
ip link add wg0 type wireguard
wg setconf wg0 <(wg-quick strip /etc/wireguard/airvpn.conf)
ip link set wg0 netns vpn
ip -n vpn addr add <IPv4 Address from the file> dev wg0
ip -n vpn addr add <IPv6 Address from the file> dev wg0
ip -n vpn link set wg0 mtu <MTU from the file> up
ip -n vpn route add default dev wg0
ip -n vpn -6 route add default dev wg0
mkdir -p /etc/netns/vpn
echo "nameserver 10.128.0.1" > /etc/netns/vpn/resolv.conf

Use the Address and DNS values from your own file if they differ. "ip netns exec" mounts /etc/netns/vpn/resolv.conf in place of /etc/resolv.conf, so programs in the namespace use our DNS through the tunnel. Please also check that the "hosts:" line in /etc/nsswitch.conf does not contain "resolve": that module asks systemd-resolved on the host directly and would bypass the namespace resolver.

3. Check that it works:

ip netns exec vpn wg show
ip netns exec vpn curl https://ipleak.net/json/

wg show should report a recent handshake and curl should show the AirVPN exit address.

4. Start the applications inside the namespace, as your normal user:
 

sudo ip netns exec vpn sudo -u $USER env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY WAYLAND_DISPLAY=$WAYLAND_DISPLAY XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR firefox --no-remote -P vpn

--no-remote and a separate profile (create "vpn" once with firefox -P) are important: otherwise, if Firefox is already running outside the namespace, the command just opens a new window of the existing instance, outside the VPN. The snap version of Firefox shipped with Ubuntu may not like being started this way; if it fails, the Mozilla .deb or tarball build should behave better. BiglyBT can be started the same way. If you use port forwarding, set the forwarded port from your Client Area as BiglyBT's incoming port: it reaches the namespace through the tunnel.

To remove everything: ip netns del vpn (wg0 is deleted with it). The commands in step 2 can later go into a small script or systemd unit to run at boot.

As an alternative for BiglyBT only, since you already run k3s: you can run it as a pod together with a VPN sidecar container such as Gluetun configured for AirVPN WireGuard, so that the pod can only reach the Internet through the tunnel. Firefox would still need the namespace approach above.

Please let us know how it goes, especially if something in the steps above needs adjusting on your system.

Kind regards