- VMware Technology Network
- :
- Networking
- :
- VMware NSX
- :
- VMware NSX Discussions
- :
- NSX Identity Firewall Rdp change source IP of Clie...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
NSX Identity Firewall Rdp change source IP of Client to the Rdp Server?
With NSX Identity firewall it is possible to define AD Group based dFW Policies, the IP Address needed for the vNIC of the VM that the the dFW Applied about the client is learned from teh AD Security Logs or through Vmware tools and Guest Introspection if the source is virtual. Both of these mechanisms could be used to learn the IP address of the AD Group member client.
If the client PC1 has IP Address 10.1.1.10, VM1 Windows Server has 10.1.1.20 and another Server VM2 has IP 10.1.1.30, and the rules are configured as follows what should be the IP Address of the client seen by the NSX Manager in the following Scenario:
Rules:
Source AD Group AllowRDP - Destination VM2 or VM1- Service RDP - Action Allow
Souce VM1 - Destination VM2 - Service RDP - Action Block
Source AD GroupAllowRDP - Destination VM2 - Service ICMP - Action Allow
Source VM1 - Destination VM2 - Service ICMP - Action Block
Source any - Destination any - Servie any - Action Block
Which of the following is the expected behaviour?
1. User logs in to PC1, since user is member of AD Group AllowRDP he is able to RDP and ping to VM2 successfully. If at that point he also creates an RDP Session with same AD user to VM1, does the NSX Manager Convert the source IP of the Client to VM1 and blocks the PC1 RDP and ICMP Sessions from PC1 IP Address?
2. User logs in to PC1, since user is member of AD Group AllowRDP he is able to RDP and ping to VM2 successfully.
If at that point he also creates an RDP Session to VM1, NSX Manager keeps source IP of the Client as PC1, and blocks the VM1 RDP and ICMP Sessions from the RDP Session?
If 1 is the expected behaviour, is it possible to change the rules or a solution for the 2. way?
Thanks,
http://www.routetocloud.com/2016/11/nsx-identity-firewall-deep-dive/
Access from physical PCs (Log Scrub):
In this usecase we would like to provide access for an employee or an external contractor to our datacenter (shown on the right side) directly from their physical laptop windows PCs or mobile devices without any agent installed on the physical PC. When the user is logged in to a windows domain machine with their Active Directory credentials, successful logon event will be generated inside the Active Directory. With NSX IDFW Log Scrub we’re relying on this event to detect the identity of the user and correlating the IP address. This method named Log Scrub because the NSX manager will need to scrub the logs from the AD to correlate the user ID and IP address to NSX Security Policy.
The firewall policy will be defined based on a user membership or groups membership in the Active Directory. The NSX firewall enforcement will be done at the datacenter’s workloads (on the right side).
Identity Firewall Workflow
Identity Firewall (IDFW) allows user-based distributed firewall rules (DFW).
About this task
User-based distributed firewall rules are determined by membership in an Active Directory (AD) group membership. IDFW monitors where AD users are logged in, and maps the login to an IP Address, which is used by DFW to apply firewall rules. Identity Firewall requires either guest introspection framework or active directory event log scraping. You can use both in your environment, or one or the other. When both the AD log scraper and Guest Introspection are used, Guest Introspection will take precedence. Note that if both the AD event log scraper and Guest Introspectionare used, the two are mutually exclusive: if one of these stops working, the other does not begin to work as a back up.
AD group membership changes do not immediately take effect for logged in users using RDSH Identity Firewall rules, this includes enabling and disenabling users, and deleting users. For changes to take effect, users must log off and then log back on. We recommend AD administrators force a log off when group membership is modified. This behavior is a limitation of Active Directory.
Note:
Identity Firewall for RDSH is only supported with Windows Server 2016.
Procedure
- Configure Active Directory Sync in NSX, see Synchronize a Windows Domain with Active Directory. This is required to use Active Directory groups in Service Composer.
- Prepare the ESXi cluster for DFW. See Prepare the Host Cluster for NSX in the NSX Installation Guide.
- Configure Identity Firewall logon detection options. One or both of these options must be configured.
Note:If you have a multi-domain AD architecture, and the log scrapper isn't accessible due to security constraints, use Guest Introspection to generate login and logout events.