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 opting for micro-segmentation only.
Some customers, for example, are happy to allow the network’s management and physical gateways to remain within the physical fabric. Perhaps their organisation already has an alternative software-defined networking product, or they simply don’t make that many changes within their network. So, how 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. In this article, we look at the process in detail.
There are two options for deploying the Security Only use case:
- Firstly, we have the wizard-driven Security Only deployment option available via the Quick Start option (Quick Start > Prepare Clusters for Networking and Security). This is a great way to get customers up and running quickly and will enable immediate use of the DFW in conjunction with vSphere-owned distributed port groups. However, with its ease and speed comes a few caveats – unfriendly naming conventions for the required NSX constructs will be created (transport zones, uplink and transport node profiles), some of which cannot be edited or deleted, and more importantly, were a customer to decide to leverage networking via NSX (VLAN-backed or overlay) at a later date, they would need to uninstall NSX VIBs from the cluster and reinstall. As it’s best to start as you mean to go one, let’s discuss Option 2.
- The second option is a manual deployment, which in most cases, is preferable. This option gives us more flexibility and allows us to configure transport zones, uplink and transport node profiles, etc., with ‘nice’ names and not the long automated identifiers defined via the quick start approach. The manual approach also enables us to create VLAN-backed networks/segments within NSX itself. Where customers wish to leverage overlay networking in the future, they will be able to build on top of what has already been deployed without the need to strip out the automated Security Only deployment configuration.
Nutshell, where a customer never requires NSX-owned networking (either VLAN-backed or overlay), Option 1 will suffice. If the use case were to change and a requirement for NSX networking is identified in the future, Option 2 every day of the week.
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