VMware NSX

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

Manish Jha

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

NSX Identity Based Firewall – Part 1: Introduction

Manish Jha

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

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

Manish Jha

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

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

Manish Jha

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
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.
… Read More

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

Manish Jha

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

NSX 4.2 Multitenancy Series – Part 9: NSX VPC Security

Manish Jha

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

NSX 4.2 Multitenancy Series – Part 8: Resource Sharing in NSX VPC

Manish Jha

Welcome to part-8 of the NSX Multi-tenancy series. The last post of this series discussed how NSX VPC is created and how subnets are carved out from the allocated IP blocks. 

In this post, I will discuss how resource sharing works in 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

When a VPC is created, a default share is created automatically in the parent project. This share contains the private and external IP blocks, Tier-0 gateway, and edge cluster, which the VPC can consume.

The public block is created in the default space by the Enterprise Admin and shared to the project/vpc. A private IP block is created and shared by the Project Admin.… Read More

NSX 4.2 Multitenancy Series – Part 7: Creating NSX VPC’s

Manish Jha

Welcome to part-7 of the NSX Multi-tenancy series. The last post of this series discussed how networking works in NSX VPC and the concept of subnets. 

In this post, I will demonstrate how to create an NSX VPC and setup networking for the project workloads. 

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

To recap from the previous post, a VPC can have public and private subnets for workload connectivity.

The Enterprise Admin creates public subnets in the default space and allocates them to the Project, which can then be consumed by the NSX VPC. Also, the Enterprise Admin whitelists the approved subnets for advertising them to the northbound routers. … Read More

NSX 4.2 Multitenancy Series – Part 6: NSX VPC Networking

Manish Jha

Welcome to part-6 of the NSX Multi-tenancy series. The last post of this series discussed NSX VPC architecture and its use cases and the benefits that it provides.

In this post, I will walk you through how networking works inside an 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

VPC Networking Overview

In an NSX Project, each VPC has its own set of networking and security policies. Subnets within an NSX VPC represent independent layer 2 broadcast domains.

The Enterprise Admin creates and allocates IP address blocks (public & private) to the project. These IP blocks are consumed by the workloads in VPC. The application owners do not need to have a thorough understanding of the subnets or know how to create CIDRs for project workloads because the NSX platform handles this automatically.… Read More

NSX 4.2 Multitenancy Series – Part 5: NSX Virtual Private Cloud (VPC) Overview

Manish Jha

Welcome to part-5 of the multi-tenancy series. The last post of this series discussed distributed security in NSX Projects and how to implement DFW rules to allow inbound/outbound connection for the project workloads. In this post, I will discuss NSX Virtual Private Clouds (VPCs).

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

1: NSX Multitenancy Introduction

2: Multitenancy Design Models

3: Creating NSX Projects

4: Distributed Security in NSX Project

NSX Virtual Private Clouds (VPCs)

NSX VPC is an abstraction layer that makes it easier to create self-contained virtual private cloud networks within an NSX Project so that networking and security services may be used in a self-service model.

This feature allows each tenant to define its own subnets, networking services, and firewall rules (DFW/Gateway). This simplifies network and security management, giving users a self-service model similar to public cloud environments. … Read More