WireGuard on Proxmox: Host, VM or LXC, and Why the Container Route Bites

Affiliate disclosure - This post contains Contabo affiliate links. If you grab a VPS through them, we earn a commission at no extra cost to you.

Proxmox gives you three plausible homes for a WireGuard tunnel, and every guide picks one without saying why. The choice matters, because two of them fail in ways that are hard to read the first time.

The three options, and what each one actually costs

On the host. One apt install wireguard, one config, done. It is the fastest route and the one most people take.

The cost is that your VPN and your hypervisor management plane are now the same machine and the same firewall. A mistake in a PostUp rule does not break a service, it locks you out of the box that runs every other service. If you do this, keep IPMI, a console, or physical access available.

There is one case where it is the right answer anyway: when the reason for the tunnel is to reach the Proxmox web interface at port 8006 from outside. A tunnel that terminates inside a VM cannot help you when the VM is down.

In a VM. A small Debian guest with 512 MB of RAM handles a home tunnel without noticing. The isolation is real, snapshots work, and a broken firewall rule costs you one guest rather than the host.

The cost is a little overhead and one more system to patch. For most setups this is the right default.

In an LXC container. Cheapest in resources, and the one that produces the confusing failure described below.

The LXC failure, and the fix

Install WireGuard in a fresh unprivileged container, run wg-quick up wg0, and you get an error about a TUN device rather than about your config. The config is fine. The container has no /dev/net/tun, because unprivileged containers do not get device nodes they were not given.

Shut the container down, then edit /etc/pve/lxc/<CTID>.conf on the host and add:

lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file

Start it again and wg-quick up wg0 works. Check the device arrived with ls -l /dev/net/tun inside the container.

Do not make the container privileged to solve this. It works, and it hands the container a level of access the problem never required. The two lines above are the whole fix.

One more thing that catches people out: the kernel module lives on the host, not in the container. Proxmox ships a kernel with WireGuard built in, so there is normally nothing to load, but if wg complains about a missing module, that is a host problem and installing packages inside the container will not touch it.

Routing your other guests through the tunnel

Once the tunnel is up, you usually want more than the machine holding it to use it.

On the machine running WireGuard, enable forwarding:

sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf

Then, on the peer at the far end, list the local subnets in AllowedIPs so return traffic knows where to go:

[Peer]
PublicKey = <peer public key>
AllowedIPs = 10.10.0.2/32, 192.168.10.0/24

AllowedIPs is doing two different jobs at once here, which is the single most common source of confusion with WireGuard. On the sending side it is a routing table, and on the receiving side it is an access control list. Getting it wrong produces silence rather than an error. The detail is in our AllowedIPs guide.

If the tunnel comes up and traffic then stalls, the next suspect is packet size rather than routing: see WireGuard MTU. If the handshake never completes at all, start with handshake troubleshooting.

Firewall, briefly

Proxmox has its own firewall layer at datacenter, node and guest level, and it sits in front of anything you configure inside a guest. A rule that works when you test it from the host can be dropped before it reaches the container.

If a tunnel refuses connections and the config looks right, check the Proxmox firewall at all three levels before rewriting anything in wg0.conf.

Which one to pick

If the tunnel exists to reach your Proxmox management interface from outside, put it on the host and accept the coupling.

For everything else, a small VM is the boring correct answer, and an LXC container is fine once TUN is passed through. Both keep the hypervisor out of the blast radius, which is the property you will care about the day a rule is wrong.

If you do not have a machine to host the far end of the tunnel, a small VPS is the usual answer: our cheapest VPS for WireGuard comparison covers what the low tiers actually deliver.