VCF NSX VPC Configuration Step-by-Step-Guide

This post is also available in: Englisch

In meinem Blog “https://vrealize.it/de/2025/02/07/vpc-networking-mit-vcf-nsx/” bin ich auf das VPC Konstrukt in VCF NSX eingegangen. In diesem Blog werde ich die Einrichtung auf einer bestehenden VCF NSX Platform beschreiben.

Voraussetzungen

Dieser Blog setzt darauf auf, dass bereits vCenter und NSX über den SDDC Manager oder manuell installiert und konfiguriert wurden. Nachfolgend eine kleine Checkliste:

• vCenter, Datacenter, Cluster,ESXi + VDS konfiguriert
• NSX Manager, NSX Edge-Nodes, IP Routing zwischen T0-Gateway und Datacenter (externer) Router konfiguriert
• Authentication Provider für Role based Access verbunden (in meinem Fall LDAP)
• Sollten auch die Firewall Funktionen in einem VPC getestet werden, wird zusätzlich zu der VCF Lizenz die vDefend AddOn Lizenz benötigt.

Ziel Setup

Nachfolgend ein Schaubild in dem das Ziel-Setup  beschrieben ist.

Nachdem alle Konfigurationsschritte ausgeführt wurden, wird es ein Projekt(Tenant) mit dem Namen ACME geben. 

• In dem Projekt sind die VPCs und in dem VPC die Segmente erstellt. 
• Virtuelle Maschinen an den “Public” Segmenten können von dem Test PC erreicht werden. 
• Virtuelle Maschinen an den “Private” Segmenten sind nur innerhalb des jeweiligen VPCs erreichbar.
• Virtuelle Maschinen an den “Private” Segmenten können über NAT (Network Address Translation) den Test PC erreichen.

Sowohl für die Privaten Segmente und auch die Public Segmente wird jeweils ein (oder mehrere) IP Block(s) erstellt. Der public IP Block wird an den DC (Datacenter/external) Router propagiert sobald ein Public Segment erstellt wurde. Der private IP Block ist nur auf dem jeweiligen VPC-T1 Gateway vorhanden und wird nicht zu dem T0-Gateway propagiert.

• public IP Block = 192.168.24.0/22
• private IP Block = 172.31.0.0/16
• Der Test PC hat die IP Adresse 172.16.112.53 und Ping ist erlaubt

Über Role Based Access Control (RBAC) werden die Zugriffsrechte auf Projekt und VPCs eingeschränkt. Folgende Nutzer werden in meinem Beispiel genutzt. Die Namen können natürlich individuell gewählt werden:

• sylvester =  AD User und Mitglied der Gruppe ent-admin für NSX und vCenter – für die Erstellung der Projekte und einrichten von public/external IP Address Blocks
• daffy = AD User und Mitglied der Gruppe acme-project – für die Erstellung der VPCs und einrichten von private IP Address Blocks
• tweety = AD User und Mitglied der Gruppe acme-vpc1 – Nutzer des ersten VPCs
• porky = AD User und Mitglied der Gruppe acme-vpc2 – Nutzer des ersten VPCs

Hinweis: Die Namen sind frei erfunden und haben keinen Bezug zu real existierenden Personen

Die NSX Basis Konfiguration

Transport Zones

Für die VPCs werden Geneve Overlay Tunnel erstellt. Unter System->Fabric->Transport Zones sind zwei Transport Zonen (eine Overlay-TZ und ein Vlan-TZ) als “Default” markiert. Diese werden automatisch für die VPCs ausgewählt.

Sollten die VPCs in einer anderen Transportzone eingerichtet werden, muss diese Transport Zone als Default festgelegt werden.

Tier-0 Gateway Konfiguration

Das Tier-0 Gateway ist über zwei Edges an einen externen Datacenter Router über BGP verbunden. 

Wenn dynamische Routing Protokolle (BGP/OSPF) genutzt werden, muss auf dem T0 Gateway, “Route re-distribution” für die VPC Netze aktiviert werden. 

Sollte NSX ausschließlich für die VPCs genutzt werden, reicht es aus, wenn die Häkchen wie in dem Bild gesetzt werden. Wenn auch andere routen über das T0-Gateway propagiert werden sollen, können diese natürlich zusätzlich angehakt werden.

Sollten zu diesem Zeitpunkt keine weiteren Netzwerke konfiguriert sein, wird die BGP Verbindung zwischen den NSX Edges und dem Datacenter Router etabliert sein, aber es sollten keine Routen über BGP gelernt worden sein.

Let’s get started!

Wenn alle Vorbereitungen abgeschlossen sind, können wir mit der VPC Konfiguration starten. In der aktuellen Version von NSX wird für die Konfiguration eines VPCs ein extra Projekt benötigt. Dadurch gibt es Aufgaben die der Enterprise Admin durchführt und er kann VPC spezifische Konfigurationen durch einen Projekt Admin ausführen lassen.

01. Erstellen des externen (public) IP Block

Der Enterprise Admin bestimmt (zusammen mit dem Netzwerkteam) welche IP Adress Blöcke in das Unternehmensnetz gerouted werden und somit Zugriff auf Resourcen innerhalb eines VPCs ermöglichen. Aus NSX Sicht wird dieser IP Block “external” genannt. Der definierte IP Block wird unter Networking -> IP Management -> IP Address Pools -> IP Address Blocks -> ADD IP ADDRESS BLOCK erstellt. Der IP Block kann entweder individuell für jedes Project/VPC oder aber auch für mehrere Projekte/VPCs bereit gestellt werden. Je nach Nutzung ist der Name entweder Projekt bezogen oder wie in diesem Bild sehr generisch, da so die Option besteht diesen IP Block auch für andere Projekte zu nutzen.

02. Projekt anlegen

Als nächstes wird ein Projekt angelegt und die Resourcen zugeteilt.

Unser Projekt mit dem Namen “ACME” nutzt das vorhandene T0 Gateway (es können auch mehrere ausgewählt werden), ein Edge Cluster und den zuvor definierten External IP Block (auch hier können mehrere Blöcke ausgewählt werden).

Der Short log identifier (maximal 8 Zeichen) hilf beim späteren Logging. Sollte dieser nicht gesetzt werden, wird ein Identifier durch NSX generiert.

Je nach dem, ob Firewall genutzt werden soll, kann über Activate Default distributed Firewall Rules festgelegt werden ob ein Basisset an Rules erstellt werden soll. 

Es empfiehlt sich, den Schalter bei “Organize NSX Portgroups in vCenter folders” auf “Yes” zu setzen, damit wir auch in vCenter die Netze einzelnen Usern zuordnen können.

Nachdem das Projekt angelegt wurde, könnte man noch Qoutas (Limitierungen) erstellen und dem Projekt zuweisen.

Es können verschiedene Limits von Netzwerk bis zum VPC gesetzt werden, hier lohnt es sich ein wenig rein zu schauen, würde aber diesen Blog Beitrag in der Länge sprengen wenn ich auf alle Funktionen eingehe.

03. Projekt Admin dem Projekt hinzufügen

Als nächstes weisen wir einem Nutzer, beziehungsweise einer Nutzergruppe dieses Projekt zu. In diesem Beispiel sind auf dem Active Directory die Nutzer angelegt und den jeweiligen Gruppen zugewiesen.

Wir wählen die Nutzergruppe (in diesem Fall acme-project) aus und anschließend die Rollen für diese Nutzer Gruppe.

Die Rolle ist “Project Admin” und als Scope wird das zuvor erstellte Projekt ausgewählt.

Je nachdem, ob der Enterprise Admin oder der Projekt Admin die Berechtigungen der VPC Nutzer setzen soll, muss unter Roles noch dem Project Admin die Berechtigung “Role Assignment” gegeben werden.

04. Login als Project Admin und erstellen des private IP Blocks

Sobald man sich als Projekt Admin in meinem Beispiel mit dem Nutzer Daffy eingelogt hat, sieht man dass man direkt in dem Projekt ist und das Tier-0 gateway nicht mehr zur Auswahl steht. Auch in den anderen Tabs wird man sehr schnell Unterschiede feststellen.

Für die VPCs, wird in dem Projekt ein private IP Block angelegt der für die VMs genutzt wird, die nicht außerhalb des VPs erreichbar sein müssen. In diesem Beispiel können sich die Segmente in einem VPC aus dem Subnetz 172.31.0.0/16 ein Netz bedienen.

05. Erstellung der VPCs

Jetzt ist alles vorbereitet um die beiden VPCs zu erstellen. Dazu wechseln wir auf den neu hinzugekommenen Reiter “VPCs” und klicken auf “ADD VPC”.

Neben dem Namen des VPCs wählen wir wieder das T0 Gateway aus, nehmen die zuvor erstellten IP Blöcke für den Externen und den Privaten Bereich und entscheiden anschließen, ob NSX auch gleichzeitig DHCP Server für die angeschlossenen VMs in diesem VPC sein soll.

Wenn man sich für DHCP aus NSX entscheidet wird die DNS Server IP Adresse benötigt.

Die nachfolgenden Service Settings legen fest, ob Firewall Regeln erstellt werden sollen und ob die VMs in den privaten Segmenten über eine NAT Regel nach außen kommunizieren können. Das ist hilfreich, wenn Services außerhalb des VPCs erreicht werden müssen. Das kann ein DNS Server, NTP Server oder weitere Dienste sein. Da wir später testen wollen ob die VMs auch nach außen kommunizieren können lassen wir die Einstellungen auf den Default Werten.

Sollte das vDefend AddOn lizensiert sein und man hat sich entschieden, das Häkchen bei “Activate Default E-W Firewall Rules” aktiviert zu lassen, sollte man sich im klaren darüber sein, dass ohne eine Allow Regel die Kommunikation zu dem VPC verboten ist. Um zu einem späteren Zeitpunkt testen zu können, ob von dem Test PC (außerhalb des VPCs) die VMs in dem VPC erreicht werden können, muss mindestens ICMPv4 auf das VPC erlaubt werden. Dafür wird der Security Bereich in dem VPC ausgeklappt und die E-W Firewall Rules um ICMP ergänzt.

Die Default Regel (ID:1064) erlaubt die Kommunikation von allen VPC Membern (PROJECT-ACME-VPC-VPC-1-default) zu allen Zielen, sowohl innerhalb als auch außerhalb des VPCs. Außerdem ist der Service DHCP freigeschaltet. Die letzte Regel (ID:1066) verbietet jede weitere Kommunikation.

Über “ADD POLICY” wird nun eine Policy oberhalb der Default Policy angelegt. Als Namen können wir “ICMP” eintragen.

Anschließend legen wir in der Policy die Regel “ICMP-INGRESS” an.

Die Source bleibt “Any” und es wird die Destination editiert. Als Auswahl findet man die vordefinierte Gruppe für die VPC Member mit dem Namen “PROJECT-ACME-VPC-VPC1-default”.

Anschließend wird über das “Services” Feld “ICMP ALL” ausgewählt (Dadurch können sowohl IPv4 als auch IPv6 Adressen verwendet werden)

Damit die Firewall Regel keine unnötigen Ressourcen verschwendet und nur auf den VMs angewendet wird, die in dem VPC vorhanden sind, kann anschließend noch dass “Applied To” Feld auf die Gruppe “PROJECT-ACME-VPC-VPC1-default” angewendet werden.

Im letzten Schritt wird die Firewall mit dem “PUBLISH” Button aktiviert.

Nachdem das VPC-1 erfolgreich angelegt wurde, kann ein weiteres VPC mit den selben Einstellungen (außer der Name;-) angelegt werden. Dieser Schritt ist optional und wird nur benötigt wenn man die Verbindungen zwischen zwei VPCs testen möchte.

Sobald ein VPC erstellt wurde, wird automatisch ein Tier-1 Gateway erstellt und ein SNAT Eintrag (Source Network Address Translation) für die VMs die an einem Private Segment hängen erstellt. Die IP Adressen werden aus dem externen IP Pool genommen. Die SNAT Einträge kann man auf Projekt Ebene unter NAT einsehen, wenn “Show VPC realized objects” ausgewählt wird.

Auch auf dem externen Datacenter Router werden diese Netze über BGP gelernt.

06. VPC Zugangsberechtigung vergeben

Wie schon zuvor für das Projekt, wollen wir nun verschiedenen Nutzergruppen, Berechtigung auf das jeweilige VPC geben. Dafür melden wir uns noch einmal mit dem Admin User an, da wir dem Projekt Admin nicht die Berechtigung gegeben haben VPC Nutzer zu berechtigen.

Diesmal wählen wir zuerst die Gruppe acme-vpc-1 aus und danach dieselbe Prozedur für acme-vpc-2. 

Danach können wir uns als VPC-1 User anmelden.

07. VPC Netze erstellen

Sobald man sich als VPC Nutzer angemeldet hat, sind viele Konfigurationsoptionen verschwunden.

Wir wechseln in den Reiter VPCs und Editieren das uns zugeordnete VPC

Anschließend gehen wir auf Connectivity und erstellen ein neues Subnets

Als erstes erstellen wir ein Segment was auch von extern erreichbar sein soll. Als Access Mode wählen wir daher Public aus. Je nachdem wie viele VMs an diesem Segment angeschlossen werden sollen, wählt man die Size (estimated max workloads) aus. !!Achtung!! 4 Adressen werden von diesem Netz reserviert. Das heißt, wenn ich 16 auswähle kann man 12 Adressen nutzen.

Sobald die Konfiguration gespeichert ist, wird ein IP Netz aus dem external IP Pool erstellt und über BGP an den Datacenter Router propagiert.

Als nächstes legen wir noch zwei Private Netzwerke an. Diesmal ist der Access Mode natürlich “Private”

Den Vorgang wiederholen wir mit dem VPC-2 User und erstellen ebenfalls ein Public und 2 private Netzwerke.

Wenn man sich jetzt als Enterprise Administrator die Netzwerk Topologie anschaut wird man die Netze und die Tier-1 Gateways die mit dem Tier-0 Gateway verbunden sind, sehen.

08. vCenter Nutzer anlegen und den VPCs zuordnen

!!Die nachfolgenden Schritte werden für die VPC 1 und VPC 2 Gruppe durchgeführt!!

In NSX ist jetzt alles vorbereitet und die VPC Nutzer können weitere Netze hinzufügen oder löschen. Jetzt ist es Zeit das vCenter zu öffnen um zu sehen, ob die Netze dort auch sichtbar sind und die Nutzer auch hier entsprechend zu hinterlegen. Dafür melden wir uns mit einem vCenter Administrator im vCenter an. In dem Netzwerkreiter sieht man einen Folder mit dem Namen “NSX Managed Folders” und unter diesem Folder die beiden VPC Folder mit den dazugehörigen Netzen.

Wenn auch das vCenter mit dem Active Directory verbunden ist, können wir auf dem Folder VPC-1 (mit rechtem Mausklick) die Berechtigung für die VPC-1 Gruppe hinzufügen. Die Berechtigung sollte auch dan die Children vererbt werden.

Damit die Nutzer auch VMs in ihrem “VPC” oder Resource Pool erstellen können, sind noch ein paar weitere Schritte notwendig.

Resource Pool erstellen

Unter dem reiter Hosts and Clusters werden nun die Recource Pools für VPC 1 und VPC 2 erstellt. Danach bekommt der VPC Nutzer auch dort die Berechtigung als Admin alles zu konfigurieren. Man könnte an dieser Stelle auch Einschränkungen machen, wieviel Resourcen dem Pool zur Verfügung stehen.

VMs and Templates Folder erstellen

Danach muss ein VMs und Templates Folder erstellt werden und dieser bekommt ebenfalls die Berechtigungen.

 

Datastore Access

Und als letztes fügen wir die Nutzer noch als “Datastore Consumer” den jeweiligen Datastores hinzu die genutzt werden dürfen.

09. Als VPC Nutzer VMs im eigenen VPC erstellen

Nachdem auch im vCenter alle Einstellungen gemacht wurden, können wir als nächstes mit einem der beiden VPC Nutzer im vCenter einloggen.

Der VPC Admin kann nur seinen resource Pool sehen…

…und auch nur seine Netzwerke

Der VPC Nutzer kann jetzt virtuelle Maschinen erstellen oder OVA Files hochladen und nur die Netzwerke auswählen die seinem VPC zugeordnet sind. Da wir DHCP über NSX nutzen, sollten die VMs keine statische IP haben sondern sich über DHCP eine Adresse beziehen.

Die Erstellung von virtuellen Maschinen überspringe ich und gehe davon aus, dass dieses Wissen vorhanden ist.

10. Testing

Nachdem nun die VMs installiert sind, sollten mindestens in einem VPC zwei VMs (eine im Public Netz und eine im Private Netz) installiert sein.

Die VM VPC-1-S1 befindet sich an dem Netzwerksegment VPC-1-PUBLIC und hat die IP Adresse 192.168.24.19 erhalten. Wie zu erwarten ist diese Adresse aus dem Bereich genommen worden, den wir vorher als external IPs gewählt haben.

Test 1 – Ping von Test PC (extern) auf VPC-1-S1 (192.168.24.19)

Sollte der Ping nicht erfolgreich sein, sollte geprüft werden ob auch keine Firewall im Wege steht der diesen Ping blockieren könnte. (VPC Firewall, NSX Firewall, Project Firewall, Datacenter Firewall)

Nach dem erfolgreichen Ping schauen wir uns die zweite VM an.

Die VM VPC-1-S2 befindet sich an dem Netzwerksegment VPC-1-PRIV-01 und hat die IP Adresse 172.31.0.3 erhalten. Diesen IP Adress Bereich haben wir zuvor als den privaten bereich festgelegt, der nicht außerhalb des VPCs gerouted wird.

Test 2 – Ping von Test PC (extern) auf VPC-1-S2 (172.31.0.3)

Wie zu erwarten ist der Ping nicht erfolgreich, obwohl keine Firewall es blockiert. Da dieses Netzwerk gar nicht gerouted wird, kann es außerhalb des VPCs auch nicht erreicht werden.

Test 3 – Ping von VPC-1-S2 (172.31.0.3) auf Test PC (extern 172.16.112.53)

Aus dem Netzwerk 172.31.0.0/26 ist ein Ping auf den Test PC möglich, da der PC ausgehend eine NAT Regel hat und somit das Päckchen transportiert werden kann.

Test 4 – Ping von VPC-1-S2(172.31.0.3) auf VPC-1-S1(192.168.24.19)

Der Ping ist aus zwei Gründen erfolgreich. Zum einen weil die Destination eine Public IP hat und zum anderen weil sich beide Server in demselben VPC befinden.

Funktioniert der Test auch andersrum?

Test 5 – Ping von VPC-1-S1(192.168.24.19) auf VPC-1-S2(172.31.0.3)

Der Ping ist auch erfolgreich, da sich beide Server in dem gleichen VPC befinden und damit an dem gleichen T1 Gateway verbunden sind.

Test 6 – VPC-2-S1(192.168.24.35) auf VPC-1-S1(192.168.24.19)

Nachdem die Verbindungen innerhalb eines VPCs und aus einem externen Netz getestet wurden, schauen wir uns an, wie es mit der Kommunikation zwischen VMs in unterschiedlichen VPCs aussieht.

Die Ping von VPC-2 zu der VPC-1 VM im Public Netzwerk sollte auch erfolgreich sein.

Test 7 – VPC-2-S1(192.168.24.35) auf VPC-1-S2(172.31.0.3)

Als nächstes prüfen wir, ob auch die VM an einem privaten Segment in VPC-1 erreichbar ist.

Die Ping von VPC-2 zu der VPC-1 VM im Privaten Netzwerk wird nicht erfolgreich sein, da das VPC-2 keinen Netzwerkpfad zu den privaten Netzwerken eines anderen VPCs hat.

Zusammenfassung

Ein VPC einzurichten muss wie alles andere geplant werden und bedarf ein wenig Vorbereitung. Sobald das VPC aber konfiguriert ist, kann der VPC Nutzer seine eigene Umgebung verwalten, ohne das die Netzwerk Infrastruktur gefährdet ist. Dadurch können dass Netzwerk Team und das Security Team entlastet werden. 

Gerne nehme ich Kommentare und Anregungen entgegen!