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.
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.
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.
Now that we have finalize deploying three managers in NSX-T management cluster we can go ahead and configure a Virtual IP(VIP) on it. We can use NSX-T internal mechanism to set an IP address on the cluster or setup an external load balancer in front of NSX-T managers. Configuring VIP which is recommended by VMware is more simple but using a LB would load balance traffic among NSX-T managers. This is a design question and should be chosen based on requirements and customer needs.
Please keep in mind that if you want to choose this approach, you need to have all NSX-T managers are on the same subnet. In this case, managers are attached to SDDC Management network. To configure Virtual IP, login to NSX-T Manager UI, choose System and on the left panel select Appliances then click on SET VIRTUAL IP option.
In the previous articles, we deployed first NSX-T Manager and then we added vCenter Server as Compute Manager in NSX-T Web UI. In this post we are going to finalize NSX-T Management cluster. In production environment for high availability and performance reasons, it is recommended to have three NSX-T Managers in the cluster. Second and third NSX-T Managers should be added from NSX-T Web UI. To deploy additional NSX-T manager appliances, go to System menu and choose Appliances and click on “ADD NSX APPLIANCE”.