NSX 4.x VRF Gateways – Part 2: VRF Config Validation & Traffic Flows

31/05/202501/11/2025 manish_jha86

Welcome to part-2 of the NSX VRF series. Part 1 of this series discussed VRF architecture and its use cases and the advantages that VRF offers over traditional routing isolation techniques. In this post, I will demonstrate VRF configuration validation to ensure things are working as expected.

The following configuration was done in vSphere before VRF validation:

VRF-Red VM is deployed and connected to segment “red-ls01” and has IP 192.168.40.2
VRF-Blue VM is deployed and connected to segment “blue-ls01” and has IP 192.168.50.2

Connectivity Test

The blue VRF VM can:

Ping its default gateway.
Uplink interface used for BGP peering.
An IP from the physical network.

However, the Blue VRF VM can’t ping the Red VRF gateway or any of its VMs.

The same tests were performed on the Red VFR VM and validated that it can’t reach the Blue VRF gateway or its VM.

You can run similar tests using the NSX Traceflow tool.… Read More

Spread the Love

NSX 4.x VRF Gateways – Part 1: VRF Architecture & Configuration

30/05/202501/11/2025 manish_jha86

Introduction

VMware NSX has been providing multi-tenancy capabilities to an SDDC since its inception. There are various ways to achieve it, depending on the use cases. In the simplest architecture, multi-tenancy is achieved by creating and connecting various Tier-1 gateways to a Tier-0 gateway, where each Tier-1 gateway belongs to a dedicated tenant with a non-overlapping network. Having several Tier-0 gateways, each owned by a different tenant, is another way of achieving multi-tenancy.

Multi-tenancy without NSX VRF

The concept of VRF is not new with NSX. It has been since v3.x of NSX. The VRF functionality has changed and gained new features with the latest iterations of NSX.

Virtual Routing and Forwarding (VRF) allows NSX admins to virtualize the routing table on a Tier-0 gateway and provide tenant separation from a routing perspective. With VRF, you can configure per-tenant data plane isolation up to the physical network without creating a Tier-0 gateway per tenant.… Read More

Spread the Love

How to Upgrade NSX ALB in a GSLB Setup

16/05/202501/11/2025 manish_jha86

The Global Server Load Balancing (GSLB) function of NSX ALB (Avi) enables load balancing for globally distributed applications/workloads (usually, different data centers and public clouds). GSLB offers efficient traffic distribution across widely scattered application servers. This enables an organization to run several sites in either Active-Active (load balancing and disaster recovery) or Active-Standby (DR) mode.

In a GSLB setup, the corporate DNS server delegates one or more subdomains to Avi GSLB, which then owns these domains and provides responses to DNS queries from clients. DNS based load balancing is implemented by creating a DNS Virtual Service in Avi. In a GSLB setup, one site is designated as the GSLB leader, and the rest of the sites are GSLB followers.

If you are new to GSLB, I encourage you to read about the same from the links below:

1: Avi GSLB in VMware Cloud on AWS

2: Avi GSLB for Containerized Workloads

Upgrading Avi controllers is pretty straightforward and is well documented in the product documentation.… Read More

Spread the Love

NSX Identity Based Firewall – Part 3: Implement IDFW using Guest Introspection

14/05/202501/11/2025 manish_jha86

Welcome to part-3 of the NSX IDFW series. The first post discussed the overview and architecture of NSX IDFW, and the second post discussed implementing NSX IDFW using Active Directory Event Scraping.

If you are not following along, I encourage you to read the earlier parts of this series from the links below:

1: Introduction to NSX Identity Firewall

2: Implement IDFW using Event Log Scraping

In this post, I will discuss NSX Guest Introspection, which is another logon detection method that NSX uses to enforce identity-based firewall rules.

What is NSX Guest Introspection?

Guest Introspection for VMware NSX is a user space agent installed inside a virtual machine to provide network connection control and monitoring capability. This daemon provides network connection control and monitoring capabilities by utilizing the capabilities offered by the netfilter libraries and the netfilter kernel subsystem. For Windows OS, guest introspection is packaged and delivered with VMTools. … Read More

Spread the Love

NSX Identity Based Firewall – Part 2: Implement IDFW using Event Log Scraping

05/05/202501/11/2025 manish_jha86

Welcome to part-2 of the NSX IDFW series. The last post of this series discussed the overview and architecture of NSX IDFW and the logon detection method.

This post discusses how to implement NSX IDFW using Active Directory Event Scraping.

Event Log Scraping provides the logging information from different sources to the NSX Manager. This information is used in the distributed firewall rule and extends IDFW support outside virtual workloads. Event Log Scraping supports the following logging sources:

Active Directory
PAN GlobalProtect
Aruba ClearPass
BYOD (custom attributes)

In an Active Directory environment, NSX reads the security event log for the user from the AD and, based on configured firewall rules, takes the appropriate action. To pull events from the AD security event log, the AD event log scraper is configured in the NSX Manager and points to an instance of the domain controller in the infrastructure.

For other types of logging sources, you need to deploy Aria Operations for Logs (vRLI) to aggregate logs in one place.… Read More

Spread the Love

NSX Identity Based Firewall – Part 1: Introduction

04/05/202501/11/2025 manish_jha86

Introduction

Typically, firewall rules are based on security groups that contain IP addresses, a subnet, or virtual machines. These security groups can be used as a source or destination in an NSX environment, but this doesn’t cover all use cases. Let’s take an example where an NSX admin has to allow/block access to specific applications to a given set of users, independent of the source address of the end-user. How do I implement rules, as the source address can vary for each user (local machine, VDI, terminal server). That’s where NSX Identity Based Firewall (IDFW) helps you.

NSX IDFW allows you to create distributed firewall rules based on Active Directory users and groups. You can allow or deny access to applications based on user identity. IDFW requires integration with Active Directory so that the NSX can consume AD users and groups.

Use Cases for Identity Firewall

Identity Firewall can be used for Virtual Desktops or a Remote Desktop Session Host.… Read More

Spread the Love

NSX 4.2 Multitenancy Series – Part 10: Integration with NSX Advanced Load Balancer

10/04/202504/08/2025 manish_jha86

Welcome to part-10 of the NSX Multi-tenancy series. The last post of this series discussed distributed security in NSX VPC and how to implement gateway and distributed firewall policies.

This post discusses NSX VPC integration with NSX Advanced Load Balancer (ALB).

If you are not following along, I encourage you to read the earlier parts of this series from the below links:

1: NSX Multi-tenancy Introduction

2: Multi-tenancy Design Models

3: Creating NSX Projects

4: Distributed Security in NSX Project

5: NSX Virtual Private Cloud Overview

6: NSX VPC Networking

7: Creating NSX VPCs

8: Resource Sharing in NSX VPC

9: NSX VPC Security

The integration between NSX VPC and NSX Advanced Load Balancer allows application owners to provision load balancers on-demand in a self-service manner. To support NSX multi-tenancy, a new configuration option, “Enable VPC Mode” is introduced in the NSX cloud configuration in NSX ALB. The Enterprise Admin, with the role of System Admin in NSX ALB, configures the NSX cloud configuration with VPC mode and the Service Engine’s networks.… Read More

Spread the Love

Using CA-signed Certificates with SAN Attribute in NSX 4.x – API Method

08/04/202501/11/2025 manish_jha86

In my last post on the NSX SSL certificate rotation, I discussed the types of certificates in NSX and why you should use a certificate with a SAN attribute. The ability to generate a CSR with Subject Alternative Names was first introduced in NSX v4.2. Before NSX v4.2, creating certificates with SAN attributes was possible only through API. This post is focused on demonstrating the certificate generation and replacement procedure through API.

Step 1: Create Certificate Signing Request

Method: POST

URL: https://{nsx_mgr}/api/v1/trust-management/csrs

Headers: Accept: application/json, content-type: application/json

Authentication: Basic

Payload:

{
    "display_name": "<certificate-name>",
    "key_size": 2048,
    "algorithm": "RSA",
    "subject": {
        "attributes": [
            {
                "key": "CN",
                "value": "<nsx-mgr-vip-fqdn>"
            },
            {
                "key": "O",
                "value": "Cloud"
            },
            {
                "key": "OU",
                "value": "Network-Engineering"
            },
            {
                "key": "L",
                "value": "Toronto"
            },
            {
                "key": "ST",
                "value": "Ontario"
            },
            {
                "key": "C",
                "value": "CA"
            }
        ]
    },
    "is_ca": false,
    "extensions": {
        "subject_alt_names": {
            "dns_names": [
                "<nsx-mgr-vip-fqdn>",
                "<nsx-mgr01-fqdn>",
                "<nsx-mgr02-fqdn>",
                "<nsx-mgr03-fqdn>"
            ],
            "ip_addresses": [
                "<nsx-mgr-vip>",
                "<nsx-mgr01-ip>",
                "<nsx-mgr02-ip>",
                "<nsx-mgr03-ip>"
            ]
        }
    }
}

Method: POST

URL: https://{nsx_mgr}/api/v1/trust-management/csrs

Headers: Accept: application/json, content-type: application/json

Authentication: Basic

Payload:

{

"display_name": "<certificate-name>",

"key_size": 2048,

"algorithm": "RSA",

"subject": {

"attributes": [

{

"key": "CN",

"value": "<nsx-mgr-vip-fqdn>"

{

"key": "O",

"value": "Cloud"

{

"key": "OU",

"value": "Network-Engineering"

{

"key": "L",

"value": "Toronto"

{

"key": "ST",

"value": "Ontario"

{

"key": "C",

"value": "CA"

}

]

"is_ca": false,

"extensions": {

"subject_alt_names": {

"dns_names": [

"<nsx-mgr-vip-fqdn>",

"<nsx-mgr01-fqdn>",

"<nsx-mgr02-fqdn>",

"<nsx-mgr03-fqdn>"

"ip_addresses": [

"<nsx-mgr-vip>",

"<nsx-mgr01-ip>",

"<nsx-mgr02-ip>",

"<nsx-mgr03-ip>"

]

}

Step 2: Fetch the ID of the CSR

The CSR ID can be fetched from the response output of the previous API or using the GET call as shown below.

Spread the Love

Using CA-signed Certificates with SAN Attribute in NSX 4.x – GUI Method

08/04/202501/11/2025 manish_jha86

Introduction

In this post, I will discuss replacing NSX self-signed certificates with CA-signed certificates with a Subject Alternative Name (SAN) extended attribute.

Note: This article applies to NSX v4.2 and higher versions. For NSX version >= 4.0/4.1, refer to the next post of this series.

What is a SAN attribute, and why should I use it?

A Subject Alternative Name is an extension used in digital certificates that allows a single certificate to secure multiple domain names, subdomains, or IP addresses. Think of it as a way to tell your web browser, “This certificate is valid for more than just one website.” Instead of providing separate certificates for each domain/machine, a single SAN certificate can cover numerous domains, simplifying maintenance and boosting security.

In a typical NSX deployment, you deploy 3 NSX Manager nodes and configure a VIP address. Each NSX node comes with an out-of-the-box, self-signed SSL certificate. Also, when you configure a VIP address, NSX automatically configures a self-signed certificate for the VIP.… Read More

Spread the Love

NSX 4.2 Multitenancy Series – Part 9: NSX VPC Security

01/04/202502/04/2025 manish_jha86

Welcome to part-9 of the NSX Multi-tenancy series. The last post of this series discussed how resources are shared with a VPC from the default space and the project’s space.

In this post, I will discuss distributed security in NSX VPC.

If you are not following along, I encourage you to read the earlier parts of this series from the below links:

1: NSX Multi-tenancy Introduction

2: Multi-tenancy Design Models

3: Creating NSX Projects

4: Distributed Security in NSX Project

5: NSX Virtual Private Cloud Overview

6: NSX VPC Networking

7: Creating NSX VPCs

8: Resource Sharing in NSX VPC

When the Project/VPC Admin creates a VPC, a default security group is also created with it. This group follows the naming convention “PROJECT-<project_name>-VPC-<vpc-name>-default”.

Members of this security group can be viewed by clicking the View Members button. This group contains subnets and VMs created inside the VPC.

All members of the VPC’s default group are automatically added as members of its parent project’s default group.… Read More

Spread the Love