Building a FortiManager Lab on Proxmox — Part 3: Proxmox Networking, Linux Bridges, VLAN-Aware Bridges and SDN for the Lab

27 April 2026 FortinetFortiManagerProxmoxLabNetworkingLinux

A FortiManager lab is only as realistic as the network underneath it. If everything sits on vmbr0, you’ve built a single broadcast domain and you’ve taught yourself nothing about how FortiManager actually deploys — which is behind a security boundary, on its own management segment, with FortiGuard egress through a controlled path. This part of the series builds the Proxmox networking that supports a proper lab, end-to-end.

The four segments we want:

Bridge	Purpose	VLAN ID	Subnet
`vmbr-mgmt`	Lab management plane — FMG GUI access, FAZ, admin workstation	10	10.20.10.0/24
`vmbr-fgd`	FortiGuard egress — outbound only, sourced through the lab edge FGT	20	10.20.20.0/24
`vmbr-transit`	Transit between lab edge FGT and managed FGTs (the “WAN” of the lab)	30	10.20.30.0/24
`vmbr-cust`	Customer-side network on the managed FGTs (the “LAN” of the lab)	40	10.20.40.0/24

Plus vmbr0 for the Proxmox host’s own management — keep that separate from the lab.

This part covers Linux bridges, VLAN-aware bridges, and Proxmox SDN, then assembles the four segments above using the option that fits each.

Linux bridge vs. VLAN-aware bridge vs. Open vSwitch

Three options on a Proxmox host. They aren’t all equal.

Plain Linux bridge (one bridge per segment)

The simplest pattern. One vmbrX per VLAN; each VM NIC attaches directly to the bridge for the segment it lives on. No VLAN tags inside the guest. Trunk interfaces, if you need them, come up with bridge-vids set explicitly.

Pros: trivial to reason about, easy to audit, every segment is a separate kernel device, every ip link show is unambiguous.

Cons: doesn’t scale past about a dozen VLANs, and any VM that needs multiple VLANs needs multiple NICs.

For this lab — four segments, well-defined NIC counts per VM — this is the pattern that fits.

VLAN-aware Linux bridge (one bridge, many VLANs)

A single bridge with bridge-vlan-aware yes. Each VM NIC carries a VLAN tag (tag=10 in the Proxmox NIC config). The bridge is essentially an access/trunk switch in software.

Pros: one bridge to rule them all, easy to add new VLANs without editing /etc/network/interfaces, plays nicely with downstream physical switches that are already trunking.

Cons: harder to reason about when something breaks. tcpdump -i vmbr0 shows everything on every VLAN. bridge vlan show becomes a required diagnostic.

This is the production pattern at scale. For a lab where you want to see the segments cleanly, it’s overkill.

Open vSwitch

A full software switch with VLAN, LACP, VXLAN, OpenFlow. Pros: powerful, the only realistic choice for a Proxmox cluster running heterogeneous tenant workloads. Cons: another piece of software to learn for no benefit at lab scale.

For this lab: plain Linux bridges, one per segment. I’ll mention the VLAN-aware shape in passing in case you want to consolidate later.

Proxmox SDN — when to bother

Proxmox 8.x ships with a built-in SDN feature that lets you define zones, VNets, and subnets in the GUI and have Proxmox manage /etc/network/interfaces for you. It’s genuinely useful in a cluster — VNets are cluster-wide objects, so adding a new VLAN means defining it once and every node picks it up.

For a single-node lab, SDN adds a layer of abstraction that obscures what’s actually being configured. You learn more by editing /etc/network/interfaces directly and watching what happens. Skip SDN for this lab; revisit it if you grow to a 3-node cluster.

That said: if you want to play with SDN, the four segments above map cleanly to four SDN VNets in a single simple zone. The configuration ends up generating the same Linux bridges underneath. You can always add SDN later without re-IPing anything.

The /etc/network/interfaces shape

This is the configuration I’d put on a Proxmox host running this lab. Substitute your own physical NIC names (eno1, enp1s0, etc. — ip link show will tell you).

auto lo
iface lo inet loopback

# Physical NIC — the only thing that touches a real cable
auto eno1
iface eno1 inet manual

# Host management — Proxmox web UI, SSH to host
auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0
# vmbr0 is the only bridge with a physical port. Everything below is internal.

# Lab management plane — FMG GUI, FAZ, admin workstation
auto vmbr-mgmt
iface vmbr-mgmt inet manual
    bridge-ports none
    bridge-stp off
    bridge-fd 0
# Note: bridge-ports none means this bridge has no uplink — purely virtual.
# That's deliberate. The lab edge FGT in Part 4 connects vmbr-mgmt and vmbr-transit.

# FortiGuard egress segment — outbound only, sourced through lab edge FGT
auto vmbr-fgd
iface vmbr-fgd inet manual
    bridge-ports none
    bridge-stp off
    bridge-fd 0

# Transit between lab edge FGT and managed FGTs — the "WAN"
auto vmbr-transit
iface vmbr-transit inet manual
    bridge-ports none
    bridge-stp off
    bridge-fd 0

# Customer-side network behind managed FGTs — the "LAN"
auto vmbr-cust
iface vmbr-cust inet manual
    bridge-ports none
    bridge-stp off
    bridge-fd 0

Apply with:

ifreload -a
brctl show
ip -br link show type bridge

brctl show is the old tool; ip -br link show type bridge is the modern one. Either confirms the bridges exist. None of them should have an IP address on the host — only vmbr0 does, because the host needs to be reachable on its own management network. The lab bridges are purely L2; the L3 gateway for each lab subnet lives on the lab edge FortiGate, which is the right place for it.

Why bridge-ports none?

A Linux bridge with no physical uplink is exactly what you want for an isolated lab segment. It exists only inside the Proxmox host. VMs attach to it; nothing else does. This is how you build a network that can’t accidentally leak onto the host’s home/office LAN.

The only “uplink” any of these bridges gets is via the lab edge FortiGate VM, which has NICs on multiple bridges and routes between them. The FortiGate becomes the gateway, the firewall, and the NAT boundary all at once — exactly as it would in production.

Connecting the lab to the outside world

The lab edge FortiGate (Part 4) needs one path to the internet for FortiGuard updates, NTP, and DNS. There are three patterns; pick one.

Pattern A — bridge a NIC on `vmbr-fgd` to the host LAN (recommended for a home lab)

Add eno2 (or whatever your second physical NIC is) to vmbr-fgd:

auto vmbr-fgd
iface vmbr-fgd inet manual
    bridge-ports eno2
    bridge-stp off
    bridge-fd 0

Now vmbr-fgd has a physical uplink. The lab edge FGT’s “WAN” interface lives on this bridge and gets DHCP from your home/office router. Outbound NAT happens at your router; the FGT does its own NAT for the lab subnets. Two layers of NAT but it doesn’t matter — FortiGuard is HTTPS to a public CDN.

Pattern B — share `vmbr0` (recommended if you only have one physical NIC)

Skip vmbr-fgd entirely and put the lab edge FGT’s WAN NIC on vmbr0. The FGT will pick up DHCP from your home network. Slightly less clean — host management and lab egress share a bridge — but works fine for a single-NIC mini-PC lab.

If you go this route:

qm set 9100 --net0 virtio,bridge=vmbr0,firewall=0       # WAN on host LAN
qm set 9100 --net1 virtio,bridge=vmbr-mgmt,firewall=0   # mgmt
qm set 9100 --net2 virtio,bridge=vmbr-transit,firewall=0

Where 9100 is the lab edge FortiGate VMID.

Pattern C — fully isolated (no internet)

Skip the uplink entirely. The lab works for everything except FortiGuard updates and FortiManager → Fortinet support portal calls. Useful if you’re on a locked-down network or just want a hermetic environment. You won’t be able to test FortiGuard distribution from FMG to managed FGTs without it.

For the rest of this series I assume Pattern A — separate physical NIC for lab egress. Adjust the FGT WAN config accordingly if you’re on B.

VLAN-aware bridge — the alternative shape

If you’d rather collapse all of this onto a single VLAN-aware bridge, the configuration looks like this:

auto vmbr-lab
iface vmbr-lab inet manual
    bridge-ports none
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 10 20 30 40

Then on each VM NIC you set the VLAN tag at the Proxmox layer:

qm set 9001 --net0 virtio,bridge=vmbr-lab,tag=10,firewall=0       # FMG mgmt
qm set 9001 --net1 virtio,bridge=vmbr-lab,tag=20,firewall=0       # FMG fgd
qm set 9100 --net0 virtio,bridge=vmbr-lab,tag=20,firewall=0       # FGT-edge fgd
qm set 9100 --net1 virtio,bridge=vmbr-lab,tag=10,firewall=0       # FGT-edge mgmt
qm set 9100 --net2 virtio,bridge=vmbr-lab,tag=30,firewall=0       # FGT-edge transit
qm set 9101 --net0 virtio,bridge=vmbr-lab,tag=30,firewall=0       # FGT-managed wan
qm set 9101 --net1 virtio,bridge=vmbr-lab,tag=40,firewall=0       # FGT-managed lan

Same end state, fewer bridges. I prefer the per-segment bridges because tcpdump -i vmbr-mgmt only shows you traffic on that segment — clean blast radius for diagnostics. If you go VLAN-aware, get used to tcpdump -i vmbr-lab vlan 10 and bridge vlan show.

Putting the FortiManager NICs on the right bridges

If you skipped the bridges in Part 2 (or used vmbr0 as a placeholder), update them now:

qm set 9001 --net0 virtio,bridge=vmbr-mgmt,firewall=0
qm set 9001 --net1 virtio,bridge=vmbr-fgd,firewall=0

The VM doesn’t need a reboot — the NIC hot-replug works on FortiManager — but a reboot is cleaner and adds 30 seconds to the build. qm reboot 9001 is fine.

After the reboot, confirm:

qm config 9001 | grep ^net
# net0: virtio=XX:XX:XX:XX:XX:XX,bridge=vmbr-mgmt,firewall=0
# net1: virtio=XX:XX:XX:XX:XX:XX,bridge=vmbr-fgd,firewall=0

And from inside the FortiManager:

get system interface
diagnose hardware deviceinfo nic port1

You should see port1 up, port2 up if you addressed it, and the MAC addresses match what qm config reported.

A note on MTU

Lab MTU is one of those things that bites you exactly once. The defaults all line up — bridges default to 1500, VirtIO NICs default to 1500, FortiOS defaults to 1500 — but if you ever turn on jumbo frames on vmbr0 for storage performance, the lab bridges should not inherit it. Keep the lab bridges at 1500 unless you have a specific reason to do otherwise; FortiGuard CDN responses don’t benefit from jumbo and IPsec overhead inside the lab will fragment unhelpfully.

To pin MTU explicitly on a bridge:

auto vmbr-transit
iface vmbr-transit inet manual
    bridge-ports none
    bridge-stp off
    bridge-fd 0
    mtu 1500

Verification before moving on

Five things to confirm before Part 4:

# 1. All bridges exist
ip -br link show type bridge

# 2. None of the lab bridges have an IP on the host (only vmbr0 should)
ip -br addr show | grep vmbr

# 3. FortiManager is on the correct bridges
qm config 9001 | grep ^net

# 4. There is no DHCP server on any lab bridge yet
#    (the FGT will provide it later — for now nothing should answer)
ip link set vmbr-mgmt up
ip link set vmbr-fgd up
ip link set vmbr-transit up
ip link set vmbr-cust up

# 5. The Proxmox host can still ping out
ping -c 2 1.1.1.1
ping -c 2 update.fortiguard.net

If update.fortiguard.net resolves and responds — even from the host, before any FGT is involved — you’re in good shape for Part 4. If DNS fails on the host, the lab edge FGT can’t fix it; address the host config first.

What’s next

Part 4 builds the lab edge FortiGate VM, drops it on vmbr0/vmbr-fgd (whichever pattern you chose), vmbr-mgmt, and vmbr-transit, and configures it to act as the security boundary in front of the FortiManager. Firewall policy set, FortiGuard pinhole, NAT layout, and the small set of inbound rules that let your admin workstation reach the FMG GUI without exposing it to anything else.

The single-line summary for Part 3: plain Linux bridges with bridge-ports none, one per segment, vmbr0 is the only bridge with a physical uplink, the lab edge FortiGate is the gateway for every lab subnet — not the host.