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.
I know many customers were waiting for the next release of VMware vSphere to realize the new capabilities and features. So there you go, Let’s check what’s new in vSphere 8!
VMware vSphere is the base solution on which most private cloud datacenters are running on. As VMware defines, vSphere 8 is the enterprise workload platform that brings the benefits of the cloud to on-premises workloads, supercharges performance through DPUs and GPUs, and accelerates innovation with an enterprise-ready integrated Kubernetes runtime.
In this post, I want to introduce the new and unique features that I found useful and interesting in vSphere 8.0!
I am thrilled to announce that I am starting a new position as a Senior Solution Engineer at VMware!
My name is Sadaf, I am originally Iranian, but I live in Sweden! I am a double VCIX, vExpert, and vSAN specialist with more than ten years of experience in Information Technology!
In this post, I want to share my journey with you, especially for women who want to start their career in IT but are hesitant because they are afraid of not being accepted or judged in this man-dominant field! I just forgot! Heh! I am also an expert at being judged and bullied but never get surrendered, thanks to my non-relevant bachelor’s! But you know what? I could do it, so can you!
I have studied Business Administration, but my path crossed with IT when I was on an internship about 12 years ago!
I was part of the sales engineering team responsible for helping customers get certified in the Information Security Management System(ISMS)/ISO 27001.
Continue reading “My IT Journey!”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 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”.
In previous blog post we started NSX-T implementation by deploying first NSX-T Manager. Before deploying other two NSX-T Managers we need to add a Compute Manager. As it defines by VMware, “A Compute Manager is an application that manage resources such as hosts and VMs. One example is vCenter Server”. We do this because other NSX-T Managers will be deployed through Web UI and with help of vCenter Server. We can add up to 16 vCenter Servers in a NSX-T Management cluster.
To add compute manager in NSX-T, It is recommended to create a service account and customized vSphere Role instead of using NSX-T default admin account. The reason behind defining a specific role is because of security reasons. As you can see in the below screen shot I created a vSphere Role call “NSX-T Compute Manager” with the required privileges. I use this Role to assign permission to the service account on vCenter Server.
Continue reading “Add Compute Manager to NSX-T 3.0”As it mentioned in Introduction to VMware NSX , NSX-T Datacenter is built on three integrated layers of components which are Management Plane, Control plane & Data plane. This architecture and separation of key roles enables scalability without impacting workloads.
NSX-T Management cluster which built from three-node NSX-T managers controller nodes. Management plane and control plane are converged on each node. NSX managers provides Web-GUI and REST API for management purposes. This is one of the architectural difference compared to NSX-V which had to integrate into vSphere Client & vCenter server. NSX Manager is also could be consumed by Cloud Management Platform(CMP) like vRealize Automation to integrate SDN into cloud automation platforms. NSX-T Manager can also connect to vSphere infrastructure through integration with vCenter Server(Compute Manager).
Continue reading “NSX-T Architecture & Components”