WireGuard Fabric Zones in Proxmox VE 9.2 Setup Guide

WireGuard fabric zones in Proxmox VE 9.2 give you an encrypted, routed Layer-3 link between two clusters straight from the SDN tab in the web UI, with Proxmox generating the keys and managing the peers for you. Do this once and every VM and container on either side gets an IP in the tunnel range and can reach the other site without a single manual wg command. This post walks through connecting two sites end to end, then looks at why that setup beats running WireGuard as a service inside a guest VM.

Key Takeaways

• Keys, auto-managed — Proxmox generates the WireGuard keypair and stores it for you; there is no wg-keygen and no hand-copied public key.
• UI-only build — create the zone, assign local IPs, add the peer, and attach guests, all from Datacenter → SDN.
• Host-level, not guest-level — every VM and container on the fabric subnet crosses the tunnel, not just one guest.
• Shrink the MTU — overlay tunnels blackhole large packets unless you drop the tunnel MTU to around 1420.
• Simplicity over isolation — the tunnel runs on the hypervisor, so guests share it and you give up a layer of network isolation.

What exactly is a WireGuard fabric zone?

Proxmox's SDN (Software-Defined Networking) lets you describe networks at the datacenter level and have the configuration propagate to every node. If you have not looked at SDN yet, Build a Software-Defined Datacenter with Proxmox VE covers the model well.

SDN has two broad families of zones. A bridge zone is essentially a Linux bridge the hypervisor maintains for you — guests attach to it and share an L2 segment, the same idea as Configuring VLANs on Proxmox with Linux Bridges but managed centrally. A fabric zone is a different beast: it is an overlay, and the WireGuard fabric type turns that overlay into an encrypted L3 link between nodes.

The practical upshot matters for how you think about it. With a bridge zone, guests on the same bridge can only talk to each other on the local host. With a WireGuard fabric zone, the tunnel extends that reach across sites, and the guests riding on the fabric subnet reach each other as if on the same routed network — just encrypted and off your public internet path.

This is a site-to-site link, so it is a different job from Cloudflare Tunnel on Proxmox for Zero-Trust Remote Access, which sends a single app out to remote users. Fabric zones move whole subnets between machines; a cloudflare tunnel moves one service to one person.

How to build the encrypted link between two clusters

You need two nodes (or two separate clusters) both running 9.2. Confirm the version before you start, because the fabric wireguard type is a 9.x feature:

pveversion

That should return something like Proxmox Virtual Environment: 9.2-.... SDN is cluster-scoped, so you create the zone once at the datacenter level and it lands on every node.

Create the fabric zone

Go to Datacenter → SDN → Add → Fabric Zone. Name it something obvious like site-link, set the fabric type to WireGuard, and give it a subnet. On each node, assign a local_ip in that subnet — node-a gets 10.100.0.1, node-b gets 10.100.0.2.

Proxmox generates the WireGuard keypair the moment you save, and writes it to a key file under /etc/pve/sdn/. You never touch that file. The on-disk config for the zone looks like this on node-a:

[fabric]
fabric wireguard
local_ip 10.100.0.1/24

The only field you actually set is local_ip. The fabric wireguard line just declares the type, and the keys are handled underneath it.

Give your guests an IP in the tunnel range

Attach each VM or container to the fabric zone by pointing its bridge at the zone name, then hand it an address in the 10.100.0.0/24 range. On node-a, a VM might look like this in /etc/pve/qemu-server/100.conf:

net0: virtio=52:54:00:ab:cd:ef,bridge=site-link,ip4=10.100.0.10/24

Do the same on node-b with an address in the same range, say 10.100.0.11. Proxmox's fabric takes care of neighbor discovery across the tunnel, so you do not have to configure static routes or proxy ARP by hand — the two guests reach each other as soon as the peer is in place.

Add the peer

Now point the two nodes at each other. On node-a, open the site-link zone and go to the Peers tab → Add Peer, then pick node-b as the peer.

Because Proxmox owns both keypairs, the peer's public key is populated for you — no copying and pasting base64. You only supply the endpoint, which is the routable public IP of node-b and the listening port (51820 by default), plus the allowed IPs, which is the fabric subnet:

• Endpoint: 198.51.100.20:51820
• Allowed IPs: 10.100.0.0/24

Repeat on node-b with node-a's public IP as the endpoint. The relationship is symmetric, and WireGuard keeps both directions in a single peer entry each. If you want site-a's other subnets reachable at site-b, add those CIDRs to allowed IPs as well.

Confirming the tunnel is up

Hop to the shell on node-a and check that the kernel sees the interface and the peer:

ip -br link | grep -i wg

You should see a wireguard interface listed. Then:

wg show

That prints each peer with its public key, the endpoint, and the last handshake time. A recent handshake timestamp means the link is live. From node-a's guest, ping node-b's guest:

ping -c 4 10.100.0.11

If that comes back, the encrypted L3 link is working end to end.

The one gotcha you will hit: MTU

Overlay tunnels wrap every packet in an extra UDP/IP header plus the WireGuard header, which adds roughly 60 to 80 bytes on top of the original frame. If the tunnel interface keeps the default 1500 MTU, any guest packet larger than the reduced budget gets silently dropped partway across the link. That shows up as "small packets work, large ones hang," which is a reliable way to spend an afternoon.

Set the tunnel MTU lower — 1420 is the usual safe value, 1400 if you want headroom. With a fabric zone you do not manage the interface directly the way you would with wg-quick, so this is worth flagging up front: if you see intermittent blackholing of big transfers across the site link, drop the fabric tunnel MTU first before anything else.

WireGuard fabric zone vs WireGuard in a VM

You could equally install WireGuard inside a dedicated VM and route traffic through it. That works, and it is the right call when you want the tunnel fully contained behind its own firewall rules. But it is more moving parts for the same outcome, and here is where the two setups really differ:

Aspect	WireGuard fabric zone (host)	WireGuard inside a VM
Where the tunnel runs	Hypervisor kernel, one shared tunnel	Guest userspace, per VM
Guests that get connectivity	All VMs and CTs on the fabric subnet	Only guests behind the WireGuard VM
Key management	Auto-generated and managed by SDN	You generate and distribute keys
Where it is configured	Datacenter → SDN, centralized	Inside each guest VM's config
Network isolation	Weaker — guests share the host tunnel	Stronger — traffic contained in the guest
Setup effort	A few clicks, no CLI	Install the package, write a wg config, wire routing

For a homelab or a small multi-site link, the fabric zone wins on effort: one tunnel covers every guest, and the keys and peers are managed centrally. If you are already running WireGuard in a VM for other reasons, or you specifically want the tunnel behind its own hardened firewall, the guest approach keeps that isolation. Either way, Automate Proxmox VE: Essential Scripts for Homelab Backups, Health Checks & VLANs is a good place to bolt a handshake and latency check onto the tunnel so you notice a dead link before a person does.

Conclusion

WireGuard fabric zones turn a site-to-site encrypted link into a few clicks in the SDN tab, with keys and peers managed for you and every guest on the fabric subnet crossing the tunnel automatically. The trade is that the tunnel lives on the hypervisor, so you give up a layer of guest-side isolation for a lot less fiddling — and remember to shrink the tunnel MTU or large packets will blackhole. Next, add a health check that pings the far-side guest and alerts on a lost handshake, so a broken site link surfaces before your users do.