[Proxmox Series Part 7] Designing Networks with Bridges, Private Segments, and VPN

With VM and LXC templates ready, the next bottleneck is network design. The default vmbr0 that ships with Proxmox can host every workload, but as services grow the traffic blends together and exposure becomes hard to control. You need a deliberate plan for splitting bridges, carving private segments, inserting a firewall, and choosing how VPN-based remote access affects the topology.

This article lays out a single-host progression: how vmbr bridges behave, when to use VLANs versus dedicated bridges, where to place an OPNsense firewall VM, how WireGuard or OpenVPN change the flow, and which services should be public, private, or VPN-only. Each section adds a short checklist so you can adapt the plan to your own hardware.

How this post flows

1. How Proxmox bridges (vmbr) work
2. Extending the base bridge: VLANs vs dedicated bridges
3. Private networks and OPNsense placement
4. How VPN access changes the design
5. Exposure criteria, segmentation, and common mistakes

Terms introduced here

1. vmbr: The Linux bridge interface Proxmox creates, binding a physical NIC and virtual NICs into one Layer 2 domain.
2. VLAN: Tag-based logical segmentation inside one bridge.
3. OPNsense: A FreeBSD-based firewall/router distro often deployed as a Proxmox VM to split internal networks.
4. WireGuard: A lightweight VPN protocol used for remote access or site-to-site tunnels.
5. East-West traffic: Traffic between workloads inside the homelab, contrasted with North-South traffic that enters or exits the lab.

Reading card

• Estimated time: 17 minutes
• Prereqs: Baseline Proxmox install, a dual-port NIC or a VLAN-capable switch, access to your router/switch configuration
• After reading: you can diagram bridges, private segments, VPN entry points, and explain where OPNsense fits.

5-step design checklist

1. Document existing physical links (router, switch, NIC count)
2. Choose how to extend vmbr (VLAN tags vs additional bridges)
3. Place your virtual firewall and define LAN subnets
4. Decide where the VPN terminates and who can access it
5. Classify services into public, private, and management tiers

How Proxmox bridges work

After installation, vmbr0 bridges the physical NIC (for example eno1) to the host and every guest, keeping them on the same subnet. The bridge behaves like a virtual switch.

Internet ↔ Router ↔ (eno1) Proxmox Host (vmbr0) ↔ VM/LXC NICs

This is simple but carries downsides:

• Internal services live on the same subnet as the outside world, so scans or stray traffic hit them directly.
• Experiments with DHCP or DNS can disrupt the actual household or office network.
• Introducing a virtual firewall such as OPNsense requires additional bridges or VLAN awareness.

Reality check

• Does your switch/router support 802.1Q VLAN trunks?
• Is vmbr0 backed by a single NIC, a bond, or a switch stack?
• Will you enable the built-in PVE firewall for host/guest rules?

Extending the base bridge: VLANs vs dedicated bridges

You have two main options for segmentation:

1. VLAN tagging: Keep vmbr0 but assign VLAN IDs to guest NICs. The physical switch must pass those VLAN tags.
2. Dedicated bridges: Create vmbr1, vmbr2, etc., and connect them to additional NICs or leave them as host-only bridges for internal traffic.

Dedicated bridges feel straightforward when you have spare NICs. For example, map eno2 to vmbr1 and dedicate it to an OPNsense LAN interface so everything behind it is isolated automatically. Just remember to configure the switch port as an isolated VLAN or access port so LAN traffic does not leak back into the WAN.

If ports are scarce or your switch already supports VLANs, use tagged VLANs. Add a Linux VLAN interface in Proxmox and set the VLAN Tag field on each guest NIC to keep traffic separated inside the same bridge. Configure the physical switch as a trunk and make sure your router/firewall knows how to route each VLAN subnet.

Decision prompts

• No spare NICs? VLANs are your only choice—can the switch handle it?
• Need a dedicated management network? Plan an extra vmbr or VLAN just for the host.

Private networks and OPNsense placement

Introducing a virtual firewall changes the flow:

Internet ↔ Router ↔ vmbr0 (WAN) ↔ OPNsense VM ↔ vmbr1 (LAN) ↔ other VM/LXC guests

Key points when designing this layout:

1. Separate WAN/LAN interfaces: Give the OPNsense VM at least two NICs—one connected to vmbr0, another to vmbr1.
2. Choose LAN subnets: Pick a private range such as 10.10.0.0/24 and let OPNsense run DHCP for that segment.
3. Place guests intentionally: Any VM or LXC that should remain private connects only to vmbr1 behind OPNsense.
4. Management access: Keep the Proxmox host reachable via vmbr0, but optionally add a secondary management NIC on vmbr1 so you can manage it from the internal network too.
5. Firewall availability: If OPNsense/pfSense runs as a VM, it shares fate with the hypervisor. Plan for UPS power, auto-boot order, config backups, and—if uptime matters—a physical firewall fallback.

This structure keeps databases, admin tools, and internal APIs safely tucked behind the firewall, while only designated services pass outward through port forwarding or a reverse proxy. You can also enable Proxmox’s per-guest firewall rules to add a second layer of protection.

How VPN access changes the design

Adding WireGuard or OpenVPN—either inside OPNsense or on a dedicated VM/LXC—alters exposure again.

• VPN location: Running VPN inside OPNsense keeps firewall policies in one place. Running it on a separate VM or LXC simplifies updates but requires extra firewall rules. Whichever you pick, document which VLAN/subnet the tunnel terminates on.
• Access path: VPN clients join the LAN subnet (for example 10.10.0.0/24), so you can close most public-facing management ports. Decide up front whether you want split tunnel (only some traffic) or full tunnel (all traffic) behavior.
• Segmentation: Create a VPN-specific subnet and apply rules per resource so remote users only reach what they need. Example: 10.99.0.0/24 for internal staff, 10.99.1.0/24 for contractors.

With VPN in place, you rarely need to expose Proxmox, backup dashboards, or internal Git servers to the Internet. Keep those services VPN-only and publish only the web applications that truly need external traffic.

Exposure criteria, segmentation, and common mistakes

Exposure decisions

1. Public services: Expose them through a hardened HTTPS reverse proxy with TLS and authentication. Examples: customer-facing web apps, public APIs.
2. Internal-only services: Restrict them to the VPN or OPNsense-protected LAN. Examples: GitLab, Grafana, internal message brokers.
3. Management planes: Always keep Proxmox, OPNsense UI, and backup systems behind the VPN, ideally on a dedicated mgmt VLAN with MFA.

Common mistakes

1. Leaving guests on the WAN bridge: If other VMs stay on vmbr0 while OPNsense handles LAN traffic, those VMs bypass the firewall entirely.
2. Forgetting VLAN trunks: When the switch is not configured for VLAN trunks, tagged traffic stalls and workloads lose connectivity.
3. Replacing VPN with ad-hoc SSH holes: Opening per-service SSH ports explodes the attack surface compared to a single VPN entry.
4. Ignoring MTU alignment: VLANs or tunnels change packet size; mismatched MTUs cause mysterious drops for specific services.
5. Making the virtual firewall a single point of failure: If OPNsense is the only firewall and the hypervisor reboots or loses power, everything behind it goes dark. Plan for HA, fast restores, or a physical fallback.

Wrap-up

Proxmox networking starts with one bridge but matures into a layered design that mixes bridges, VLANs, virtual firewalls, and VPN entry points. Following the sequence above clarifies which services belong on the public edge and which should stay inside private segments, giving you a predictable operational and security posture. In the next article we will build on this network foundation to plan backup paths and eventual multi-node expansion strategies.