As you know VMware released NSX-T 3.2 a few weeks ago! You can read a list of the most important new features in this blog post. Since then, I have got questions about an option in the installation wizard of the NSX-T Manager OVA appliance about GRUB root password and in this post, I want to address it. If you wanted to recover a lost or forgotten password of the root account of the NSX-T Manager appliance, you had to reboot the appliance and force the boot process to enter into the GRUB menu.
But to be able to do that, when everything was under control and you had the root’s password, you needed to log in to NSX managers with root and configure the GRUB Hidden Timeout. There was also a default password configured which we could use or change together with the hidden timeout configuration.
After a long wait, VMware finally announced NSX-T 3.2 on November 7th, 2021! There was a lot of buzz around this release for the past 2-3 months. In this article, we will look at the new features of this release. The new capabilities are grouped into three major areas; Security, Advanced Networking, and Simplified Operations, which I will list as the most significant enhancements in this article.
When we look at the new features and capabilities list, security enhancements are very bold. So let’s start with the security features and continue with networking and operations enhancements.
In the first part of NSX-T Distributed Firewall, I explained the importance of embracing NSX-T DFW. In this post, I review how you can create and apply firewall rules to implement Micro-segmentation. To create firewall rules, first you need to define a Policy section which basically contains one or more firewall rules. A policy in NSX-T DFW can be defined as stateful or stateless. In the case of being stateless, you need to define the rules in both directions. Otherwise, the reverse traffic is not allowed to pass. On the other hand, in the default stateful mode, when you define a rule it will apply bidirectionally.
Then you need to define the rules under the policy section which evaluates the criteria of a traffic flow. DFW rules determine whether the traffic should pass or get dropped based on the protocol and ports.
NSX-T Distributed Firewall (DFW) is one of the most comprehensive solutions to provide micro-segmentation from layer 4 to layer 7. It can monitor all the East-West traffic on your virtual machines and build a Zero-trust model. To leverage the DFW, vNIC of virtual machines need to connect to NSX-overlay segment, NSX VLAN backed segments or vDS port group supported from vSphere 7.0. The benefit of using DFW is that firewall rules apply at the vNIC level of virtual machines. In this way, traffic does not need to traverse to a physical firewall to get identified if the traffic can pass or drop, which is more efficient. This article will focus on using DFW to enforce L7 (FQDN/URLs) filtering.
You can give internet access to a VM or a user who login to a VM by Identity Based Firewall or even take one step further and control which specific URL/URLs are allowed to get accessed.
Before jumping to NSX-T Distributed Firewall (DFW) concept and rule creation, I want to point out why this solution is important and what security issues can be addressed by using this powerful solution. Building a zero trust model security has been the biggest concern of network and security teams. In traditional data centers, high-level segmentation is built, which could help to prevent various types of the workload from communicating. But the main challenge of the legacy security model is data centers facing a lack of lateral prevention communication system between workloads within a tier. In other words, traffic can traverse freely inside a network segment and access the crucial information until it reaches the physical firewall to get dropped. In addition, implementing different layers of security and firewalls would cause complexity and cost.
NSX-T Distributed Firewall (DFW) is a hypervisor kernel-based firewall that monitors all the East-West traffic and could be applied to individual workloads like VM and enforce zero-Trust security model. Micro-segmentation logically divides department or set of applications into security segments and distribute firewalls to each VM.
In the previous blogpost we went through Azure VMware Solution(AVS) IPSec VPN setup and to complete hybrid networking between on-prem and AVS we need to configure NSX-T gateway too. As we discussed the target architecture would look like the following diagram.
When it comes to connecting an on-premises VMware environment to Azure VMware Solution(AVS), ExpressRoute is the recommended & preferred connectivity method. But in some cases using a VPN tunnel is the only viable connectivity solution to AVS environment.
NSX-T Tier-0 or Tier-1 gateways could be used to connect on-premises VMware environment to AVS. On the Azure side, Virtual WAN(vWAN HUB) will be provide the transit connectivity through a ExpressRoute Gateway into AVS infrastructure. I am going to walk you through the configuration of both NSX-T Tier-1 GW and Azure Virtual WAN to have a complete setup.
When it come to setting up a hybrid cloud environments, one of the most important topics is networking. It is usually comes down to stretch on-prem network segments to the public cloud environment. This blog post is going to simply describe NSX-T architecture on AVS as the default networking and security stack. If you are new to AVS you can read Introduction to AVS blog post first, and then continue with this article.
In Part 1 of NSX-T SSL Certificate Replacement, the process of certificate template preparation and request has been explained. This blog post will teach you how to import and replace the generated certificate into NSX-T Manager. It is really important to verify the imported certificate before replacing it. I want to point out that if you are using a Virtual IP for you NSX-T management cluster, you should have generated the SSL certificate for management cluster’s Virtual IP address.
NSX-T installation comes with a out of the box self-signed SSL certificate. Because of security and compliance reasons, most of customers want to replace default self-signed certificate with a CA signed certificates. We have been looking for guide that explains how to do this step-by-step but unfortunately we couldn’t find one! There are some very useful guides like this one from VMware but as you read through, you realize the documentation is not complete. So to make story short, we looked around and ran SSL certification replacement.