NSX Distributed Firewall und vDefend: Lizenzierung in VCF 9, DFW-Regeln und Mikrosegmentierung in Phasen

NSX Distributed Firewall: Funktionsweise und die Rolle von vDefend

Die NSX Distributed Firewall (DFW) ist eine verteilte, zustandsbehaftete Firewall für Layer 2 bis 7, die auf jedem für NSX vorbereiteten ESXi-Host läuft und ihre Regeln an der virtuellen Netzwerkkarte (vNIC) jeder virtuellen Maschine anwendet. Jede vNIC hat einen eigenen Filter, der die auf diese VM angewendeten Regeln enthält, und die Firewall „verwaltet aktive Flows pro VNIC“, so Broadcoms Troubleshooting-Leitfaden zu vDefend 9.1; Verkehr zwischen zwei VMs auf demselben Host wird daher gefiltert, ohne den Host zu verlassen. In VCF 9 wird die Firewall separat gekauft: Die VCF-Lizenz bringt die NSX-Netzwerkfunktionen mit, während Distributed Firewall und Gateway Firewall zu VMware vDefend gehören, dessen Produkte laut Broadcoms Editionsleitfaden zu vDefend, aktualisiert am 1. Oktober 2026, „als Add-ons zu einem Kauf von VMware Cloud Foundation erworben werden können“.

Unter VCF schützt die DFW sowohl VMs auf NSX-Segmenten, VLAN-gestützt oder Overlay, als auch VMs auf Portgruppen des vSphere Distributed Switch, sobald NSX auf diesen aktiviert ist; eine VLAN-basierte Umgebung muss ihre Workloads also nicht zuerst in Overlay-Netze verschieben. VMware vSphere Foundation (VVF) enthält kein NSX und damit keine Distributed Firewall; alles Weitere behandelt unser Vergleich von VVF und VCF 9.1. Zonen, das Erfassen der Verkehrsflüsse und den herstellerneutralen Weg zu Default Deny beschreibt unser Leitfaden zu Netzwerksegmentierung und Mikrosegmentierung.

Was VCF enthält und was das vDefend-Add-on ergänzt

Broadcoms Entitlement-Tabellen zu vDefend 9.1 kennzeichnen die Netzwerk- und Inventarfunktionen mit „Provided by VCF License“; die Funktionen für Firewall und Bedrohungsabwehr gehören zu den vDefend-Editionen.

Broadcom TechDocs: Funktions- und Editionsleitfaden zu vDefend Firewall 9.1, mit der Editionsübersicht und den Entitlement-Tabellen für Distributed Firewall und Gateway Firewall (alle aktualisiert am 1. Oktober 2026); NSX-Übersicht in der Dokumentation zu VCF 9.1 (5. Oktober 2026).

Stand Oktober 2026 führt Broadcoms Editionsleitfaden eine Edition zum Kauf auf, VMware vDefend, die zustandsbehaftetes Firewalling mit IDS/IPS, Malware Prevention, Network Sandboxing, Network Traffic Analysis (NTA) und Network Detection and Response (NDR) verbindet. Das Add-on Advanced Threat Prevention (ATP) gibt Lizenzinhabern der älteren Edition vDefend Firewall die Funktionen zur Bedrohungsabwehr. vDefend Firewall und vDefend Firewall with Advanced Threat Prevention werden „nicht mehr zum Kauf angeboten“. Broadcoms FAQ zu VCF 9.1 vom 3. September 2026 nennt vDefend Firewall unter den erweiterten Diensten, die „weiterhin separat lizenziert werden“.

vDefend-Lizenzierung: Kernzählung, Schlüssel und License Hub

Broadcoms Programmdokumentation zu vDefend vom 13. August 2026 lizenziert vDefend pro Kern. Die Distributed Firewall erfordert „einen (1) Kern von VMware vDefend, um einen (1) Kern der Distributed Firewall auf dem bereitgestellten Host einzusetzen“, mit mindestens 16 Kernen je Prozessor, nach derselben Zählregel wie bei VCF, die unser Leitfaden zum Zählen von VMware-Kernen erklärt. Eine Gateway Firewall erfordert drei vDefend-Kerne für jede ihrer vCPUs. Der Agent für einen physischen Server erfordert einen vDefend-Kern für je vier seiner Kerne, ebenfalls mit dem Minimum von 16 Kernen je Prozessor. Seit vDefend 9.1 lässt sich die DFW je Cluster aktivieren, und das Deaktivieren entfernt die DFW-Filter von den Hosts des Clusters, „mit Auswirkung auf die Kernzahlen der Lizenzierung“; die vDefend-Zählung kann sich also nach den Clustern richten, die Mikrosegmentierung brauchen. NSX Manager erstellt wöchentlich einen Bericht über die Kernnutzung der Sicherheitsfunktionen, der über /api/v1/licenses/security-usage exportiert wird.

Broadcom TechDocs: Voraussetzungen für vDefend Firewall 9.1 (1. Oktober 2026) und Release Notes zu 9.1 (Erstausgabe 12. Mai 2026); Broadcom KB 430651 und KB 446503 (ohne Datumsangabe, abgerufen am 6. Oktober 2026).

Broadcoms Design Blueprint für VCF 9.1 (5. Oktober 2026) platziert die License-Hub-Appliance in der Management-Domain der ersten VCF-Instanz, eine je Fleet; im Disconnected-Modus „muss die Lizenz mindestens alle sechs Monate manuell hochgeladen werden“. KB 451106 beschreibt NSX-9.0-Hosts, die ohne vDefend-Lizenz und nach Ablauf der Karenzzeit nur die Standardregel erhielten; deshalb würden wir License Hub und die umgewandelte Lizenz bereithalten, bevor NSX Manager auf 9.1 aktualisiert wird.

Unsere VMware-Optimierung auditiert Ihre Umgebung und Lizenzen und passt die Broadcom-Editionen an Ihre realen Workloads an. Schicken Sie uns die Kernzahl jedes Clusters und die Cluster, in denen Sie die Distributed Firewall betreiben würden.

Wie NSX die DFW-Regeln verarbeitet

NSX ordnet die Richtlinien der Distributed Firewall fünf Kategorien zu, die von links nach rechts ausgewertet werden: Ethernet, Emergency, Infrastructure, Environment und Application. Innerhalb einer Kategorie werden die Regeln von oben gelesen, und „die erste Regel in der Firewall-Tabelle, die den Paketparametern entspricht, wird durchgesetzt“. Verkehr, auf den nichts passt, erreicht die Standardregel ganz unten, die nach der Host-Vorbereitung Verkehr zulässt und als letzte Regel auf Blockieren umgestellt wird, wie unser Leitfaden zur Segmentierung erklärt.

Layer-3-Regeln sind zustandsbehaftet, sofern nicht anders eingestellt, Layer-2-Regeln können dagegen nur zustandslos sein. Drop verwirft ein Paket stillschweigend, Reject antwortet bei TCP mit einem TCP-Reset und bei anderem Verkehr mit der ICMP-Meldung administratively prohibited, und Jump to Application, nur in der Kategorie Environment verfügbar, übergibt passenden Verkehr an die Kategorie Application.

Jede Richtlinie hat ein Feld Applied To. „Standardmäßig ist das Feld Applied to der Richtlinie auf DFW gesetzt, und die Regeln der Richtlinie werden auf alle Workloads angewendet“, womit jede Regel auf jedem vNIC-Filter liegt. Auf eine Sicherheitsgruppe gesetzt, beschränkt das Feld die Richtlinie auf deren Mitglieder, und ein Applied To auf Ebene der Richtlinie übersteuert das auf Ebene der Regel. IP-Adressen, MAC-Adressen und Verzeichnisobjekte in einer solchen Sicherheitsgruppe werden nicht verarbeitet. Regeln werden mit der Veröffentlichung wirksam, und das Logging ist standardmäßig ausgeschaltet; ist es eingeschaltet, schreibt jeder Host nach /var/log/dfwpktlogs.log.

Regeldesign für die NSX DFW: Tags, Gruppen und Kategorien

Bauen Sie die Regeln auf Gruppen auf, und befüllen Sie die Gruppen über Tags statt über IP-Adressen. NSX versieht VMs, Segmente und Segment-Ports mit Tags, und Gruppen erhalten ihre Mitglieder entweder dynamisch nach Tag, VM-Name oder Segment oder statisch. Wir würden mit drei Tag-Scopes beginnen, Umgebung, Anwendung und Tier, damit eine neue Datenbank-VM beim Taggen in die richtigen Gruppen kommt, ohne dass eine Regel geändert werden muss.

Broadcoms Stufenmodell legt gemeinsam genutzte Dienste in die Kategorie Infrastructure: zuerst Allow-Regeln zu den freigegebenen Verzeichnis-, DNS- und Logging-Servern, dann Lockdown-Regeln, die „Kommunikation zu nicht autorisierten Servern“ blockieren, und Regeln, die Telnet, FTP und TFTP im gesamten Rechenzentrum blockieren. Zonen wie Entwicklung, QA, UAT und Produktion werden in der Kategorie Environment getrennt, mit Jump to Application für Verkehr innerhalb einer Zone. Jede Anwendung erhält dann eine Richtlinie in der Kategorie Application, angewendet auf ihre Sicherheitsgruppe, mit Regeln zwischen ihren Tiers und einer Catch-all-Regel am Ende.

Für FQDN-Regeln schreibt Broadcom, dass „DNS-Verkehr über die Regel laufen muss, in der der DNS-Service definiert ist“, die oberhalb der FQDN-Regeln steht, und dass VMs Namen über einen DNS-Server auflösen müssen, nicht über statische Einträge. Halten Sie die Ausschlussliste, die Segmente, Ports oder Gruppen von der Durchsetzung ausnimmt, kurz. Die DFW filtert den Verkehr der Workloads an den vNICs; die Verwaltungsschnittstellen von ESXi brauchen eigene Kontrollen, die unser Leitfaden zur Härtung von ESXi-Hosts und vCenter gegen Ransomware behandelt.

Monitoring-Modus und Werkzeuge zur Regelanalyse

Die DFW hat keine Regelaktion, die nur überwacht; als Monitoring-Stufe dient daher eine Regel, die mit eingeschaltetem Logging zulässt. Broadcoms Deployment-Leitfaden nutzt Jump to Application in der Security Services Platform auf dieselbe Weise: Die Schutzregel zwischen zwei Zonen lässt Verkehr durch, während ihr Flow-Zähler zeigt, was noch zwischen den Zonen läuft, „Protection Rule Flow: 0“ ist der Indikator dafür, dass nichts mehr läuft, und Broadcom empfiehlt, „jedes Umgebungspaar tagelang zu überwachen“. Ohne diese Plattform zeigen Trefferzahl und Logs der Regel dieselben Flows. Die Trefferzahlen werden verzögert aktualisiert, denn „Statistiken auf Regelebene werden alle 15 Minuten von allen Transportknoten aggregiert“, und ein Zähler, den Sie direkt nach einem Test ablesen, kann noch null zeigen.

Jede Veröffentlichung erzeugt einen automatischen Entwurf, den Sie veröffentlichen können, um zur vorherigen Konfiguration zurückzukehren, und NSX behält bis zu 100 automatische und 10 manuelle Entwürfe. Ein Entwurf enthält die „Richtlinienabschnitte und Regeln“ der Distributed Firewall; dokumentieren Sie Änderungen an Gruppen und Tags daher separat. Broadcoms DFW-Lebenszyklus sieht eine Phase Refine vor, um die Trefferzahlen der Regeln zu prüfen, Regeln anhand der Flow-Sichtbarkeit anzupassen und „einen Firewall Rule Analysis Report auszuführen“, bevor veraltete Regeln deaktiviert oder gelöscht werden.

Security Intelligence, eine Funktion von vDefend, visualisiert Flows zwischen Gruppen, VMs und IP-Adressen und empfiehlt Richtlinien, Gruppen und Dienste. Sie läuft auf der Security Services Platform, die ein eigener Installer als separate Instanz bereitstellt; planen Sie deren Kapazität daher vor dem Assessment. Für die Fehlersuche nennt Broadcoms Lebenszyklus Traceflow, das in VCF enthalten ist; auf einem Host zeigt summarize-dvfilter den Filter jeder VM und vsipioctl getrules -f <filter> die auf diese vNIC angewendeten Regeln.

Leistungsaspekte der NSX DFW

Weil jeder Host seine eigenen VMs filtert, wächst die Kapazität der Firewall mit dem Cluster, und die Filterung nutzt die CPU des Hosts. L7 App ID, FQDN-Regeln und IDS/IPS prüfen mehr als Ports und Protokolle und brauchen je Flow mehr CPU als Port-Regeln; für IDS/IPS machen die Release Notes zu vDefend 9.1 „Turbo Mode IDS/IPS“ auf ESXi-Hosts mit 9.1 zum Standard, für „höhere Inspektionsdurchsätze“. ESXi-8.x-Hosts behalten den Classic Mode, von dem Broadcom „wegen erheblicher Leistungseinbußen“ abrät. Beschränken Sie L7- und IDS/IPS-Regeln auf die Flows, die sie brauchen, und lassen Sie auf diesen Hosts CPU-Reserve.

Broadcoms DFW-Lebenszyklus rät, Regeln über Applied To einzugrenzen, „um die Leistung zu optimieren“: Eine Richtlinie, die auf die Sicherheitsgruppe einer Anwendung angewendet wird, erreicht nur deren VMs und hält die Regeltabellen je vNIC kurz. Das Logging jeder Regel erhöht auf jedem Host die Last für Datenträger und Netzwerk; protokollieren Sie daher die Catch-all-Regeln und die Regeln unter Beobachtung, und leiten Sie die Host-Logs an einen zentralen Log-Server weiter.

NSX-Mikrosegmentierung in Phasen einführen

Broadcoms Dokumentation zu vDefend 9.1 stellt die Einführung als gestufte „Security Journey“ in vier Stufen dar: Security Assessment, Infrastructure Services Protection, Environment-level Protection und Application-level Isolation. Broadcoms Design-Bibliothek macht daraus den Leitfaden „DFW 1-2-3-4“ zur Eigenbereitstellung. Die Schritte unten richten sich nach diesen Stufen, mit einem Wartungsfenster und einem Rollback für jeden Schritt, der Regeln durchsetzt. Wo Mikrosegmentierung neben Identität, Geräten und Zugriff ihren Platz hat, zeigt unser Zero-Trust-Fahrplan für ein mittelständisches Unternehmen.

1. Klären Sie den Lizenzweg: ein vDefend-Schlüssel in NSX Manager unter 4.x und 9.0 oder License Hub und umgewandelte Lizenzdateien unter 9.1, dazu die Cluster, auf denen die DFW laufen wird.
2. Taggen Sie die VMs nach Umgebung, Anwendung und Tier, bauen Sie die Gruppen auf und erfassen Sie Flows über mindestens ein Monatsende hinweg, mit Security Intelligence, sofern bereitgestellt.
3. Veröffentlichen Sie in der Kategorie Infrastructure die Allow-Regeln für Verzeichnisdienst, DNS, Logging und andere gemeinsam genutzte Dienste, danach die Lockdown-Regeln und die Sperre für Telnet, FTP und TFTP.
4. Setzen Sie in der Kategorie Environment je Zonenpaar eine Schutzregel auf Jump to Application, beobachten Sie tagelang ihren Flow-Zähler oder ihre Trefferzahl und stellen Sie sie in einem Wartungsfenster auf Drop oder Reject um, sobald der Wert bei null bleibt.
5. Nehmen Sie sich in der Kategorie Application jeweils eine Anwendung vor: eine Richtlinie, angewendet auf ihre Sicherheitsgruppe, Regeln zwischen den Tiers und eine Catch-all-Regel, die mit Logging zulässt und nach dem nächsten Monatsende auf Drop umgestellt wird.
6. Stellen Sie die Standardregel zuletzt auf Drop um, sobald jede VM unter eine Richtlinie fällt; der automatische Entwurf der vorherigen Veröffentlichung ist das Rollback.
7. Prüfen Sie die Trefferzahlen, führen Sie den Bericht der Regelanalyse aus und kontrollieren Sie, dass neue VMs ihre Tags tragen, denn eine VM ohne Tags fällt aus den tagbasierten Gruppen heraus.

Im Rahmen unserer Leistung Cyber-Resilienz segmentiert unser Engineering-Partner Vixen.UNO das Netzwerk und rollt Änderungen Schritt für Schritt aus, in vereinbarten Wartungsfenstern mit Rollback-Plan. Beschreiben Sie im Formular unten die erste Anwendung, die Sie isolieren würden, und wie ihre VMs heute getaggt sind.

Was wir tun

Eurokommerz hält den Vertrag; das Engineering liefert unser Engineering-Partner Vixen.UNO. Im Rahmen der VMware-Optimierung auditiert Vixen.UNO Ihre Umgebung und Lizenzen, passt die Broadcom-Editionen an Ihre realen Workloads an, modernisiert vSphere, vSAN, NSX und VCF in vereinbarten Wartungsfenstern mit einem Rollback-Plan für jede Etappe und leistet danach Support unter einem vereinbarten SLA. Im Rahmen unserer Leistung Cyber-Resilienz richtet derselbe Partner Netzwerksegmentierung und Zero-Trust-Zugriff nach NIST CSF 2.0 ein, nach einem Assessment, das mit einer Risikokarte und einem priorisierten Maßnahmenplan endet. Das erste Gespräch ist kostenlos; der Preis des technischen Assessments steht vor Beginn fest.

FAQ