NSX-T DFW rules not getting applied to virtual machines in NSX-T Security Only prepared cluster
search cancel

NSX-T DFW rules not getting applied to virtual machines in NSX-T Security Only prepared cluster

book

Article ID: 330455

calendar_today

Updated On:

Products

VMware vDefend Firewall

Issue/Introduction

  • NSX-T DFW rules not getting applied to virtual machines in NSX-T Security Only prepared cluster.
  • When you try to run the vsipioctl getrules command against these impacted VM filter you receive output as No rules / No root rule set.
  • Even though the DFW rules are intact for these VMs, in NSX-T it fails to get applied to VMs.
  • This issue is also seen in vCenter VM that is added as the first Compute Manager in NSX-T that is used as a Management vCenter to deploy other two NSX-T Manager appliance that make use of DVS ephemeral port groups.
  • This scenario is applicable to VMs connected to an ephemeral DVS port group, and if such a VM was powered on using ESXi Host CLI or UI.

Environment

VMware NSX-T Data Center
VMware NSX

Cause

In NSX-T Security Only prepared cluster this issue is seen where the NSX Manager has dependency on vCenter to get a valid lport_attachment_id for the VM's and if the VM has a valid id the DFW rules get applied.

In scenarios when ephemeral DVS port groups are being used by the VMs, these port groups can be modified from ESXi host UI/API as these have Port Binding in DVS port groups being set to ephemeral-no binding.

When the vCenter is down or inaccessible, if there are any Power OFF/ON performed for the VM's directly from the Host UI/API or any modification to VM port group can lead to this issue.

As from the Host UI/API when these activities are performed ESXi provide an attachment_id that is less than 4 characters in case If an attachment_id is less than 4 characters, then it is not considered as a valid ID by nsx-datapath.  Hence, these VM's will not get DFW rules applied.

 

=============================================================================

The desired state manager logs can help identify the lport_attachment_id

 

 

The lport_attachement_id for a working VM in the Security Only Cluster, where the valid lport_attachement_id is allocated by the vCenter has a higher value as shown below and the DFW rules get applied fine.

  

  "lport_attachment_id": "424579489",

  "lport_attachment_id": "1360516542",

  "lport_attachment_id": "1283154804",

 

The lport_attachement_id for VM's that are assigned by the ESXi Host it is having value that is less than 4 characters and where DFW rules does not get applied.

  

  "lport_attachment_id": "1",

  "lport_attachment_id": "3",

 

 

The lport_attachement_id for VM's that are assigned by the NSX Manager have a UUID that is for the clusters which are prepared for both Networking and Security where DFW rules get applied. 

 

  "lport_attachment_id": "22edae7b-4686-4795-bed5-b0d0ba8a911d",

  "lport_attachment_id": "d8758e75-d46a-4663-abdb-d279cfc1fcd2",

  "lport_attachment_id": "ea00d002-3efc-43ea-97f8-9369a21dc071",

Resolution

This issue is resolved in VMware NSX 4.2.0


Workaround:

This issue is not seen if modification to the VM port group is performed from the vCenter UI as vCenter provides a valid lport_attachment_id to VM which then is used by NSX and the DFW rules get applied properly.

 

The workaround involves creating a temporary DVS port group that mimics the same VLAN and other attributes as the original DVS port group and edit setting for the impacted VM from vCenter UI and moving to temporary port group and bringing back to original port group helps in getting a valid lport_attachment_id from vCenter.

 

The workaround below is for the Management vCenter that was added as the first Compute Manager in NSX-T where the DFW rules does not get applied below procedure can be also followed for other VM's having similar issue.

 

NOTE: You need to change the port group used by the vCenter currently. DO NOT DISCONNECT the network adapter as that will lead to vCenter VM to be off of the Network.

Create temporary portgroup:

  1. Go to the Networking Tab in vCenter.
  2. Select the Distributed Switch that is being used that has the port group which vCenter VM is using.
  3. Right click on the Distributed Switch >  Distributed Port Group > Select New Distributed Port group
  4. Type the name of the temporary port group different from the existing port group used by the vCenter VM.
  5. Click Next
  6. Under configure Settings Select Port Binding > Select Ephemeral-no binding from the drop down list.
  7. Under VLAN type Select VLAN > Type the same VLAN ID that is being used for the existing port group.
  8. Select the radio button next to the Customize default configuration and hit Next.
  9. Select the Security Modes try matching the same policies as the existing port group.
  10. In Traffic shaping leave it default no change required.
  11. In Teaming and failover option select the correct failover order and the Load balancing option as the existing port group.
  12. Click next and keep rest all the options as default and at last hit finish.

 

Workaround Steps:

  1. Login to the vCenter UI.
  2. Search for your vCenter VM in the inventory then right click > select Edit Settings > Look for the Network adapter section 
  3. Click on the drop down menu > select Browse > Search for the new temporary port group name and select and hit OK
  4. Click OK in the Edit settings option at the bottom right in the Edit Setting dialogue box.
  5. The vCenter should still be accessible if the VLAN ID and the Teaming policy are correct.
  6. Do a refresh of the vCenter UI page. The vCenter VM should show it to be connected to the temporary port group.
  7. Once the vCenter is accessible you need to again go to to the edit settings of the vCenter VM and bring it back to the original port group that vCenter was making use of prior the change.
  8. Once the vCenter VM is brought to the original port group you can check if the DFW rules are getting applied to the vCenter VM or not.
  9. To verify, ssh to the ESXi host where the vCenter VM is running and execute the following commands:

    summarize-dvfilter
    vsipioctl getrules -f <FIlter name>

Additional Information

Impact/Risks:

NSX-T DFW rules will not get applied to the VM's when there are modification to port groups or Power OFF/ON activity performed on these VM's directly from the HOST UI/API having ephemeral binding port groups.

This issue is also seen in vCenter VM that is added as the first Compute Manager in NSX-T that is used as a Management vCenter to deploy other two NSX-T Manager appliance.


Powered by Wolken Software