When we talk about VMware NSX (formerly VMware NSX-T Data Center), most of us think about abstracting management of the network away from the physical fabric thanks to NSX’s magic sauce and overlay networking capability via Geneve encapsulation. However, overlay networking isn’t always the primary use case, with a high volume of customers only opting for micro-segmentation only.
Some customers, for example, are quite happy to allow management of the network, as well as their physical gateways, to remain within the physical stack. Perhaps their organisation already has an alternative software-defined networking product in play or they simply don’t make that many changes within their network. So, how then, can customers use micro-segmentation via the NSX Distributed Firewall (DFW)? Simply put, by utilising currently existing vSphere environments and VDSs in conjunction with the NSX DFW.
The deployment process to facilitate the micro-segmentation-only use case is often the quickest and most straightforward architecture to deploy and, in this article, we look at the process in detail.
There are two options for deploying the micro-segmentation-only use case.
- Firstly, we have the wizard-driven deployment option, however, this will create rather unfriendly naming conventions for the required NSX constructs. Were a customer to decide to utilise overlay networking at a later date, it would be preferable to start as you mean to go with a structured deployment approach.
- The second option is a manual deployment (which I prefer). This option allows us to configure the required uplink profiles, transport node profiles, etc., with ‘nice’ names, and not automated long identifiers. The manual approach will also enable you to understand the wider deployment process should you, at some point, wish to leverage overlay networking.
Micro-Segmentation Only Deployment Process
1. Firstly, let’s take a look at our environment. This is a lab environment and, as such, I have a vSphere Cluster of two ESXi hosts. Both ESXi hosts have two (2) physical 10 Gbps network adapters and have been added to a vSphere Distributed Switch. This VDS will be utilised by VMware NSX and, as a requirement, must be version 7 or above.
2. Next up, let’s log in to VMware NSX and create a Transport Zone by browsing to System > Fabric > Transport Zones, and by clicking + ADD ZONE.
3. Configure the Transport Zone appropriately, ensuring Traffic Type is set to VLAN. When ready, click ADD.
4. The Transport Zone is successfully created, however, note the Status displays as Unknown. This is expected, as the TZ is not currently utilised within our environment.
5. Next, browse to System > Fabric > Profiles > Uplink Profiles, and click + ADD PROFILE.
6. Configure the Uplink Profile appropriately, ensuring the Teaming Policy is set to Load Balance Source with two uplinks (i.e. – traffic will load balance across both active uplinks on my ESXi hosts). Note, as we will not be utilising Overlay networking we will not be utilising a transport VLAN for GENEVE encapsulation. As such, the Transport VLAN can be left at the default 0, and MTU can be left blank (MTU will be controlled via the VDS). When ready, click ADD.
7. The Uplink Profile is successfully created.
8. Next, browse to System > Fabric > Profiles > Transport Node Profiles, and click + ADD PROFILE.
9. Configure the Transport Profile appropriately, ensuring the Switch Type is set to VDS, Mode is set to Standard, the appropriate Compute Manager and VDS is selected, and our newly created Transport Zone and Uplink Profile are attached. When ready, click ADD.
10. The Transport Node Profile is successfully created.
11. After these several simple steps, all that is left for us to do is to apply the Transport Node Profile to the vSphere Cluster. Browse to System > Fabric > Nodes > Host Transport Nodes, select the vSphere Cluster, and click CONFIGURE NSX.
12. Select the appropriate Transport Node Profile and, when ready, click APPLY.
13. Monitor the NSX Installation process via the NSX Configuration tab.
14. Finally, check that NSX Configuration is successful and that the Transport Node Manager Connectivity, Controller Connectivity and PNIC/Bond Status all report Up. Note, Tunnel Status will remain in an Unknown state as these ESXi hosts do not require GENEVE tunnels due to no overlay networking being utilised.
This completes the deployment process for VLAN-backed micro-segmentation only. Next, we will validate we are able to secure a test VM.
I’ve written and presented on the subject of micro-segmentation several times in the past, so I won’t go into too much detail in this article. However, to validate our deployment, I will quickly secure a VM so that, in reality, I could hand over the solution to a customer.
1. Firstly, let’s create an NSX VLAN-backed Segment so that we can migrate our test VM. Browse to Networking > Connectivity > Segments, and click ADD SEGMENT.
2. Configure the new Segment with an appropriate name, select our recently created VLAN Transport Zone, and allocate the appropriate VLAN ID. When ready, click SAVE.
Remember, the gateway will continue to reside on the physical network, so no gateway or subnet details need to be configured here. As an example, the below Segment ties to VLAN ID 100, which has a subnet of 10.0.100.0/24 and a gateway of 10.0.100.1.
3. The VLAN-backed Segment is successfully created.
4. If we jump back to vSphere, we can now see the NSX Segment has been created and is visible, albeit read-only as an NSX-owned Port Group.
5. Finally, I have moved a test VM over to the new NSX Segment and amended its IP configuration to align with the subnet. Specifically, IP address 10.0.100.20/24 with the gateway mentioned above (10.0.100.1).
6. ICMP tests to/from this VM are successful. Any duplicate packets can be ignored as this is a nested lab environment.
7. Now that we have a test workload VM running on an NSX Segment, let’s secure it. Browse to Security > East West Security > Distributed Firewall and expand the Default Layer3 Section. Note that this rule, by default, is set to Any/Any/Any/Allow.
8. To drop all traffic to/from this VM (and everything else sat on an NSX Segment), simply change the Action to Drop and click PUBLISH. Of course, in a real environment, you would opt to configure VM/application-based DFW rules.
9. Running the same basic connectivity tests as we did in Step 6 now shows that all traffic to this VM is dropped.
This concludes the micro-segmentation test to validate the micro-segmentation-only deployment process.
In this article, we looked at the process of preparing a vSphere Cluster for micro-segmentation only via VMware NSX. Where overlay networking is not required, NSX can still be utilised to perform micro-segmentation.
- Securing Physical Workloads via the VMware NSX-T Gateway Firewall and Service Interface
- Securing Workloads on Bare-Metal Windows Servers via the VMware NSX-T Agent (Kernel Module)
- VMware NSX-T Micro-Segmentation via vRealize Log Insight
- VMware vRealize Network Insight (vRNI) series focussing on Application Micro-Segmentation