Proxmox VE · M6

Virtualisierte Netzwerkumgebung

Virtuelle Switches, VLANs, Firewalls als VM – die häufigste Fehlerquelle bei der Migration

Netzwerk-Topologie: Internet über Firewall-VM zur Bridge, getrennte VLANs für Management, Server und Gäste

Virtuelle Switches

Linux Bridge, Standard und robust, im Vergleich zu Open vSwitch mit erweiterten Funktionen

Linux Bridge Standardmäßig bei der Installation angelegt (vmbr0), robust, für die meisten Setups völlig ausreichend

Open vSwitch Per apt nachinstallierbar, erweiterte Funktionen wie LACP-Bonding und flexibleres VLAN-Tagging

Jede physische Netzwerkkarte lässt sich einer Bridge zuordnen, mehrere VMs teilen sich anschließend dieselbe Bridge wie an einem physischen Switch
Vergleichbar mit dem vSphere Distributed Switch (vDS) bzw. dem Hyper-V-vSwitch, funktional aber ohne separate Lizenzstufe
Für die meisten KMU-Umgebungen reicht die einfache Linux Bridge völlig aus, Open vSwitch lohnt sich erst bei fortgeschrittenen Netzwerk-Anforderungen

🎧 Block 1: Virtuelle Switches & SDN

SDN-Feature

Eine SDN-Zone mit mehreren VNets erstreckt sich zentral über mehrere Nodes

SDN steht für Software Defined Networking – Netzsegmente werden zentral definiert statt auf jedem Node einzeln von Hand konfiguriert
Zonen bündeln die Netzwerktechnik: Simple (isoliertes NAT-Netz), VLAN (klassisches Tagging), QinQ (doppeltes VLAN-Tagging für Provider-Szenarien) und VXLAN/EVPN (Layer-2-Overlay über Layer-3-Routing hinweg, auch über Standortgrenzen hinweg)
VNets sind die eigentlichen virtuellen Netze innerhalb einer Zone, denen VMs zugewiesen werden – vergleichbar mit einer Portgroup
Konfiguration gilt clusterweit über mehrere Nodes hinweg – einmal definieren, überall im Cluster verfügbar
Sinnvoll für komplexere oder mandantenfähige Setups, etwa wenn mehrere Kunden strikt getrennte Netze auf derselben Cluster-Hardware erhalten sollen
Für eine Handvoll VMs auf einem Host ist SDN Überdimensionierung – hier reicht die klassische Bridge-Konfiguration

Multi-VLAN-Design

Ein getaggter Trunk-Port führt mehrere VLANs in die VLAN-aware Bridge, jede VM bekommt ihr eigenes Tag

VLANs sind bei Migrationen die häufigste Fehlerquelle: Stimmt das Tagging irgendwo zwischen physischem Switch, Bridge und VM nicht, ist die VM stumm, obwohl scheinbar alles läuft
Bridge dazu als VLAN-aware markieren – dann kommt der getaggte Trunk vom physischen Switch mit allen VLANs geschlossen bei der Bridge an
Tagging erfolgt am Trunk-Port des physischen Switches; in Proxmox trägt man je VM-NIC lediglich das gewünschte VLAN-Tag ein, die Bridge übernimmt das Sortieren
Ein einziges Kabel genügt so für zwanzig oder mehr VLANs gleichzeitig
Management- und Nutz-VLAN unbedingt trennen – Management und Kundenverkehr im selben VLAN sind gleichzeitig ein Sicherheits- und ein Ausfallrisiko

Nach jeder Migration wirklich jedes VLAN einzeln durchtesten, nicht nur eines: Ein vergessenes oder falsch gesetztes Tag versteckt sich erfahrungsgemäß gern im dritten oder vierten VLAN – und fällt dann erst Tage später auf, wenn genau dieses Segment gebraucht wird.

🎧 Block 2: Multi-VLAN-Design

Virtualisierte Firewalls

Firewall-VM mit zwei getrennten Bridges, eine zum WAN, eine zum LAN

pfSense, OPNsense oder auch Sophos laufen problemlos als VM auf demselben Host wie die übrigen Workloads – ein etabliertes, weit verbreitetes Muster
WAN und LAN als zwei getrennte Bridges führen, damit die Firewall wirklich zwischen den Netzen steht statt nur virtuell danebenzustehen
Die Firewall-VM erhält entsprechend zwei virtuelle NICs – eine Richtung Internet/Uplink, eine Richtung internes Netz
VirtIO-NICs für Durchsatz und geringen Overhead einplanen, dazu ausreichend vCPUs – viele Firewall-Distributionen verarbeiten Pakete eher seriell pro Kern, eine unterdimensionierte Firewall-VM wird schnell selbst zum Flaschenhals
Für das KMU-Referenz-Szenario dieses Lernbereichs (1–2 Nodes, 4–6 VMs, siehe Modul 0) reicht eine einzelne Firewall-VM mit moderater Ausstattung (2–4 vCPUs) in aller Regel aus – zusätzlich spart die Netzwerksegmentierung über VLANs, die eine solche Firewall-VM durchsetzt, direkt auf die Risikomanagement-Maßnahmen ein, die NIS2 von vielen Unternehmen verlangt (siehe Modul 4)

🎧 Block 3: Virtualisierte Firewalls

Design: Firewall-on-a-Stick

Eine physische NIC als VLAN-Trunk, die Firewall routet zwischen VLANs inklusive DMZ

Eine einzige physische NIC als VLAN-Trunk genügt – alle benötigten VLANs laufen getaggt über diesen einen Uplink
Die Firewall-VM selbst übernimmt das Routing zwischen den VLANs, inklusive Filterregeln pro Segment
DMZ-Segmentierung ist damit inklusive, ganz ohne zusätzliche Verkabelung oder weitere physische NICs
Kehrseite: der gesamte Verkehr aller VLANs läuft über diesen einen Trunk und durch diese eine Firewall-Instanz – für die meisten KMU-Umgebungen ausreichend dimensioniert, bei hohem Durchsatzbedarf aber bewusst einplanen
Fällt dieser eine Uplink oder die Firewall-VM aus, steht das komplette geroutete Netz – ein Grund, warum bei höheren Verfügbarkeitsanforderungen die doppelt ausgelegte HA-Firewall aus dem nächsten Block sinnvoll wird

HA-Firewall

Zwei Firewall-VMs auf zwei Nodes synchronisieren sich per CARP

Zwei Firewall-VMs auf zwei unterschiedlichen Nodes betreiben – auf demselben Node hätte ein Node-Ausfall beide gleichzeitig lahmgelegt, das wäre keine echte Hochverfügbarkeit, nur doppelter Aufwand
Synchronisation über CARP (Common Address Redundancy Protocol) für die virtuelle IP sowie Konfigurations- und State-Sync (bei pfSense/OPNsense z. B. via pfsync) zwischen den beiden Instanzen
Fällt ein Node aus, übernimmt die zweite Firewall binnen Sekunden, ohne dass bestehende Verbindungen abreißen
Wichtig: nicht nur die Konfiguration, auch der Verbindungsstatus (State Table) sollte repliziert werden, sonst müssen aktive Sessions nach dem Failover neu aufgebaut werden

🎧 Block 4: HA-Firewall & Fallstricke

Fallstricke

Warn-Checkliste: VirtIO vs. Passthrough, Offloading, MAC-Spoofing/Promiscuous, Loop-Vermeidung

VirtIO meist die beste Wahl für Netzwerkkarten – schnell, stabil, ohne Sonderkonfiguration; NIC-Passthrough nur in Sonderfällen (z. B. sehr hohe Durchsatzanforderungen), kostet aber Flexibilität wie Live-Migration
Hardware-Offloading (TSO, GSO, GRO, Checksum-Offload) kann in virtualisierten Firewalls Durchsatz-Probleme verursachen – bei mysteriösen Performance-Einbrüchen im Zweifel einzeln per ethtool -K abschalten und testen
MAC-Spoofing und Promiscuous-Mode gezielt erlauben, wenn die Firewall Pakete für andere MAC-Adressen verarbeiten muss (Netzwerkoptionen der jeweiligen VM-NIC) – ohne diese Freigabe verwirft die Bridge solche Pakete stillschweigend

Netzwerkschleifen (Loops) unbedingt vermeiden: Werden versehentlich zwei Uplinks ohne Spanning Tree zusammen gebridged, kann ein einziger Loop das komplette Netzwerksegment lahmlegen – Broadcast-Sturm statt Ausfallsicherheit. Physische Switches mit aktiviertem STP/RSTP fangen solche Fehlkonfigurationen zusätzlich ab.

Tastenkürzel