VMware NSX

 View Only
Expand all | Collapse all

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

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

    Posted Jan 09, 2023 04:25 PM

    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):

    lukasbe12_0-1673281430757.png

    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

     

     



  • 2.  RE: NSX IDFW Rule with Port SMB, not work if on source the RDSH role is installed

    Posted Jan 15, 2023 09:58 PM

    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.