In Part 1 of NSX 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 Manager. It is essential to verify the imported certificate before replacing it. I want to point out that if you are using a Virtual IP for your NSX management cluster, you should have generated the SSL certificate for the management cluster’s Virtual IP address.
NSX 4 installation comes with an out-of-the-box self-signed SSL certificate. For security and compliance reasons, most customers want to replace the default self-signed certificates with CA-signed certificates. In this two-part blog post, I’ll explain how to prepare your certificate infrastructure, request the certificate, and finally replace the SSL certificate. There are some very useful guides, like this one from VMware, but I will explain the whole certificate replacement process in the following blog posts.
Since the release of NSX-T 3.2, I have had questions about an option in the installation wizard of the NSX Manager OVA appliance regarding the GRUB root password, and in this post, I want to address it. If you wanted to recover a lost or forgotten password for the root account of the NSX Manager appliance, you had to reboot the appliance and force the boot process to enter 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.
Continue reading “GRUB Root Password – NSX Installation”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.
Continue reading “What’s New in NSX-T 3.2”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.
Continue reading “NSX-T Distributed Firewall – Part 2”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.
Continue reading “NSX-T FQDN/URL Filtering”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.
Continue reading “NSX-T Distributed Firewall – Part 1”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.
One of the new features which has been added to NSX-T 3.0 is supporting RBAC with Native Active Directory. In previous version of NSX-T we had to use VMware Identity Manager (vIDM) to be able to add users and groups from Active Directory for RBAC purposes. In set posts I have already described how to install and configure vIDM with NSX-T. I still believe configuring RBAC through vIDM has some added value like Multi-Factor Authentication(MFA).
To setup NSX-T Role-based Access Control(RBAC) it’s better to create groups in Active Directory and add users into the group for two reasons. First it’s easier to add a group with couple of users as members rather than assign role to many users in NSX-T. Second, with help of Group Policy you can define a “Restricted Group” and it locks down membership to that group. As a result it provides a layer of security.
Continue reading “Configure NSX-T 3.0 RBAC with Native Active Directory Integration”