Overview

WolfStack network interface management

WolfStack includes comprehensive networking tools for managing IPs, WolfNet mesh connections, VLANs, routed public IPs, container networking, and integration with cloud edge load balancers.

Global WolfNet

The Global WolfNet view shows all WolfNet IPs and peer connections across your entire infrastructure. See which IPs belong to nodes, LXC containers, Docker containers, and VMs at a glance.

Container Networking

  • Each LXC container gets a bridge IP on lxcbr0 for local communication
  • WolfNet IPs (10.10.10.x) enable encrypted cross-node communication
  • Automatic route management — containers can ping each other across nodes
  • VIP (Virtual IP) support for load balancing

Docker DNS & Outbound Self-Heal New in v24.37

On hosts using systemd-resolved, Docker famously copies the unreachable 127.0.0.53 stub resolver into containers and they lose DNS. WolfStack detects the host's real upstream nameservers, writes them into Docker's daemon.json, and continuously re-checks that every Docker bridge network has working NAT and forwarding rules — healing them if a firewall reload wipes them. Containers just keep resolving and reaching the internet; nothing to configure.

WolfNet Mesh

WolfNet creates an encrypted mesh network between all your nodes automatically. Uses X25519 + ChaCha20-Poly1305 encryption (WireGuard-class). Works even if machines are on different networks or behind NAT. Each cluster runs its own mesh: WolfNet IP allocation and start-time conflict checks are scoped to the cluster, so separate clusters can reuse the same address space without tripping over each other.

Provider-agnostic vSwitch (VLAN + routed public IPs)

Bring up VLANs and routed public IP subnets directly from the dashboard, with persistence across reboots on whatever Linux distro you’re running.

  • VLAN management — Create, edit, and remove 802.1Q VLANs on any host interface. Per-VLAN IP / netmask / gateway / MTU. Validated against existing routes so you don’t accidentally black-hole the management interface.
  • Routed public IP subnets — Attach an additional public /29 or larger subnet to a host (Hetzner vSwitch, OVH additional IPs, DigitalOcean reserved IPs) and route it to containers / VMs. WolfStack handles the gateway, ARP / NDP proxying, and per-distro persistence.
  • Multi-distro persistence — Writes /etc/network/interfaces.d/ on Debian/Ubuntu, /etc/sysconfig/network-scripts/ on RHEL/Rocky, systemd-networkd drop-ins on Arch / openSUSE / Alpine. Same UI, right config for your distro.
  • Pre-flight safety — Validates VLAN ID range, subnet collisions, gateway reachability, and MTU consistency before applying. Refuses changes that would brick the management interface.
  • VLAN import — Discover existing local VLAN configuration with one click, or paste a config from another server to replicate it. Useful when standardising VLANs across a new node.

Attaching containers & VMs to a vSwitch

Once a VLAN exists, any LXC container, Docker container, or VM can join it — and for containers and VMs you can do the whole thing from the workload’s own network settings, without visiting the Networking page first.

One-step setup from a container

In an LXC container’s network-interface editor, choose a vSwitch uplink NIC from the dropdown and enter the VLAN ID your provider assigned (for a Hetzner vSwitch, the 4000–4091 tag from Robot → vSwitches). Leave the bridge field blank and fill in the container’s IP and gateway as usual. On save, WolfStack:

  • creates the tagged sub-interface (<uplink>.<vlan>, e.g. enp6s0.4000) and a bridge (vmbr<vlan>) if they don’t already exist;
  • attaches the container to that bridge — the 802.1Q tag rides on the sub-interface, so the container itself carries no tag;
  • reuses the existing sub-interface and bridge when another workload is already on that VLAN.

L2-only bridges (no host IP)

A vSwitch bridge does not have to carry a host address. Leave the subnet and host IP blank to create a pure Layer-2 bridge — the host simply switches the VLAN and only the guests on it hold addresses. This is the natural fit for a public-IP subnet routed to a vSwitch, where the public addresses belong to the containers and VMs rather than the host.

VMs on a vSwitch

Virtual machines join a vSwitch the same way. Because a VM’s address lives inside the guest OS, WolfStack stages it through cloud-init — qm set --ipconfigN on Proxmox VMs (adding a cloud-init drive if the VM lacks one), or a NoCloud seed ISO for libvirt VMs — and the guest applies it on its next boot. The attach dialog includes a per-VM “reboot now” option so the address can take effect immediately or on your own schedule.

The model — a bridge per VLAN

WolfStack uses a dedicated bridge per VLAN: the 802.1Q tagging happens on the sub-interface and the bridge is a plain Layer-2 bridge. This keeps the host’s primary NIC untouched — no risk of locking yourself out — and means a workload joins a VLAN simply by attaching to its bridge. Proxmox-style VLAN-aware bridges (one bridge, per-port tags) continue to work unchanged for imported Proxmox containers and VMs.

Edge integration (Cloud LBs + Cloudflare Tunnel)

WolfStack’s HTTP proxy supports four edge strategies for exposing services to the public internet, picked per site:

  • Direct (port forward) — Default. Your firewall forwards 80/443 to the WolfStack node.
  • Hetzner Cloud Load Balancer — WolfStack provisions a Hetzner LB pointing at your nodes, configures health checks, and tears it down when no longer needed.
  • DigitalOcean Load Balancer — Same flow on DO; provisions, monitors, and reaps the LB when the site is removed.
  • Cloudflare Tunnel — Zero-port-forward exposure via cloudflared. Provisions a named tunnel, configures the DNS, and tears down when the site is removed.

Credentials for each provider are stored under Settings → Cloud Providers, XOR-obfuscated at rest, never returned to the browser. Auto-teardown prevents orphan resources from racking up cloud bills.

Esc