NSX IDFW Rule with Port SMB, not work if on source the RDSH role is installed

[lukasbe12]

Hello

I am currently testing IDFW and having problems with SMB access, when the RDSH role is installed on the source VM.

Basically, IDFW works with other ports that I have tested (so far only tested RDP, SQL successful), but it simply does not want to work with the SMB port.

I can use any VM to reproduce this. As long as I don't have an RDSH role installed on the source VM, the IDFW rules worked with the tested ports (RDP, SQL, SMB). However, as soon as I install the RDSH role on the same VM, only "RDP" and "SQL" of these three ports still work, the SMB port 445 then no longer works. As soon as the RDSH role is uninstalled again, it works again.

The problem is not only in my environment, I can recreate this in the VMware LABS (NSX-T Security: https://pathfinder.vmware.com/v3/activity/nsx_sec), by cloning the Windows VM "user-vm-01" available there, creating an SMB share on the clone and create the following Firewall Rule (Where Destination “rds” is my new cloned Windows VM):

Then it looks like this:

example 1
Source VM:                       user-vm-01 (Without RDSH role)
Source AD ​​Group:            AD-app-users
Target VM:                       rds
Ports:                               SMB, RDP
Firewall Action:                Drop
Results:                            SMB and RDP is blocked as configured in the firewall

Example 2 (Identical to setup above, simply installed with RDSH role on source VM:

Source VM:                       user-vm-01 (RDSH role installed)
Source AD ​​Group:            AD-app-users
Target VM:                        rds
Ports:                                SMB, RDP
Firewall Action:                 Drop
Result:                               RDP is blocked as on the firewall configured, but SMB is not, this is now still accessible

I don't know if there are more ports that don't work from an RDSH, I have only tested these three ports so far. Vmware Writes that all TCP and UDP Ports will work with IDFW on RDSH, ony

My NSX-T Version is identical with the Vmware Labs “3.2.1.0.0.19801959”. VMware Tools, I have tested multiple Version of v11 and v12, is always the same. I also use VMware Tools to get Logged on Users, like in the VMware Labs and not AD Log Scraper.

Anyone have an idea or is this a Bug like it looks like for me?

Regards

Lukas

[Perttu]

Just an educated guess: in a multi-session environment (RDSH) NSX Network Guest Introspection filter ( an optional component of VMware Tools) cannot provide the identity of the initiator of an SMB connection without doubt, so it doesn't make assumptions either.

I assume that SMB connections are mediated by the NT kernel and hence they are not plain application sockets such as SQL (TCP 1433) or HTTPS (TCP 443) or whatever plain user space processes open.

On a single concurrent user machine one can safely assume that the logged in principal also opens the SMB connections. Even this is not true, as the machine itself (using network service builtin) could open SMB connections to shares for whatever use. But this applies in general.

On a multi-user machine different users can open different shares and due to the intricacies of SMB connections the GI cannot reliably convey information about these so it's not done.

However I could be totally wrong here. Does vsipioctl ( VMware Internerworking Service Insertion Platform I/O Control command line tool on ESXi ) show any details about NT SIDs mapped to these flows? Google for its instructions. 

And in our environment we don't use IDFW rules to block connections (think about situations when they don't work). We use them merely to whitelist connections so in a situation when they fail, ports will be closed by default - not open.