NSX-T IDFW how-to guide: How to consume NSX-T IDFW efficiently

I’ve had the privilege of working with VMware’s BU and the Livefire teams on an IDFW design that can be consumed at scale. Hopefully, people can make use of my findings.

Note: That this design can be consumed by VDI. but in this example i’m am using RDSH.

Requirements:

Just some critical information in the diagram above, especially the VMware tools elements.

• Windows Server 2019 IDFW is supported in NSX-T 3.1 and above
• VMware Tools install – VMCI Driver, NSX File Introspection Driver, NSX Network Introspection Driver

Design

VMware’s overview and demos give customers a high-level expectation of how IDFW works, but this doesn’t detail how to implement it in the real world.

So what does it look like in the real world?

For this example, I am using an RDSH cluster and two users with two AD security groups. The User must only be allowed to connect to their own applications and services but denied access to the other application.

Deliverables:

• Deploy an RDSH Server Cluster. Both Admin Users can connect
• RDP access to the RDSH server and Web Apps
• Admin 01 can only connect to Web-App-01 & Admin 02 is denied
• Admin 02 can only connect to Web-App-02 & Admin 01 is denied

Assumptions:

1. All the users are connecting from outside of the NSX Domain
2. The default Deny rule is enabled

Building the NSX-T IDFW rules:

Each of the AD groups will be associated with a dedicated NSX Group. The RDSH Servers will have their own dedicated NSX security group & The Application servers will have their own NSX Security group. To see how this would look, please refer to the table below:

Application Name	AD Security Group	NSX Security Group For Servers	NSX Security Group for AD Security Group
Web-App-01	Admin-Web-App-01	NSXSRV-Web-App-01	NSXAD-Web-App-01
Web-App-02	Admin-Web-App-02	NSXSRV-Web-App-02	NSXAD-Web-App-02
RDSH Server	N/A	NSX-RDSH-Server	N/A

In the NSX GUI it would look like the following:

RDSH DFW Access Rules (Section 1 on Identity Firewall Logical design)

Now the security groups have been deployed. We need to implement inbound access to the RDSH servers. This is section 1 In the diagram Identity Firewall Logical design for Green and Red connections.

Name	Source	Destination	Service	Profile	Applied To	Action
Allow Access to RDSH Servers	Networks Accessing the RDSH Hosts	NSX-RDSH-Server	RDP	RDP	NSX-RDSH-Server	Allow
Deny Access to RDSH Servers	Any	NSX-RDSH-Server	Any	Any	NSX-RDSH-Server	Block

Deploy Identity Access from the RDSH Hosts (Section 2 Identity Firewall Logical design)

Now the APP Groups have access to the RDSH hosts. We need to implement an identity firewall from the RDSH Servers. The key parts are the “Applied to” section, which deploys the rule to the security group listed in this section. In This case, the Active Directory groups to the destinations. Which mean the IDFW rule is deployed to the RDSH only and no other server or service.

Name	Source	Destination	Service	Profile	Applied To	Action
Allow Access AD to Web-App-01 Servers	NSXAD-Web-App-01	NSXSRV-Web-App-01	RDP	RDP	NSX-RDSH-Server	Allow
Deny Access AD to Web-App-01 Servers	NSXAD-Web-App-01	NSXSRV-Web-App-01	Any	Any	NSX-RDSH-Server	Block
Allow Access AD to Web-App-02 Servers	NSXAD-Web-App-02	NSXSRV-Web-App-02	RDP	RDP	NSX-RDSH-Server	Allow
Deny Access AD to Web-App-02 Servers	NSXAD-Web-App-02	NSXSRV-Web-App-02	Any	Any	NSX-RDSH-Server	Block

In the NSX GUI it will look something like this:

DFW Allow Access to Application Servers (Section 3 Identity Firewall Logical design)

Note this section has to be applied last otherwise the NSX DFW will process this rule before the other two sections

In section 2, we have created a rule that only allowed outbound access on the RDSH server. This applies the identity rule at the source. Any traffic leaving the RDSH servers will have been accepted by section 2, but the destination NSXSRV-Web-Apps need the policy to allow the traffic inbound to the systems. Otherwise, the default-deny will drop the traffic.

The below table is an example of such a deployment, you will note that all the groups are IP based and not AD integrated.

Name	Source	Destination	Service	Profile	Applied To	Action
Allow Access to Web-App-01 Servers	NSX-RDSH-Server	NSXSRV-Web-App-01	RDP	RDP	NSXSRV-Web-App-01	Allow
Deny Access to Web-App-01 Servers	NSX-RDSH-Server	NSXSRV-Web-App-01	Any	Any	NSXSRV-Web-App-01	Block
Allow Access to Web-App-02 Servers	NSX-RDSH-Server	NSXSRV-Web-App-02	RDP	RDP	NSXSRV-Web-App-02	Allow
Deny Access to Web-App-02 Servers	NSX-RDSH-Server	NSXSRV-Web-App-02	Any	Any	NSXSRV-Web-App-02	Block