After upgrade from 3.2.3.1 to 4.1.2.1, DHCP Discovery broadcast packets were not hitting the Allow rule and were dropped by the default rule instead
search cancel

After upgrade from 3.2.3.1 to 4.1.2.1, DHCP Discovery broadcast packets were not hitting the Allow rule and were dropped by the default rule instead

book

Article ID: 327764

calendar_today

Updated On:

Products

VMware NSX VMware NSX-T Data Center VMware vDefend Firewall

Issue/Introduction

Symptoms:
  1. Customer is on version 3.2.x and has a rule to allow DHCP Discovery broadcast traffic with quad 0 IP or IP ranges in the Source and DHCP broadcast IP (255.255.255.255/32)in the DestinationScreenshot 2024-03-21 at 11.29.55 AM.png
  2. After upgrade to 4.1.1 and above, this rule stops working and traffic is dropped by the default deny rule. You can see it in the dfwpktlogs Screenshot 2024-03-18 at 3.04.49 PM.png
  3. As a result of this, the VMs wont obtain IP addresses via DHCP after the upgrade

 


Environment

VMware NSX-T Data Center
VMware NSX 4.1.1

Cause

  1. In 3.2.3.1, the rule has the source configured with a group with IP range 0.0.0.0 - 0.0.0.1 and destination with the DHCP broadcast & DHCP server IP.
    A rule with quad 0s in the source is not suppose to work. This works in 3.2.3.1, because the destination groups are evaluated and are matched. Hence, the rule works in 3.2.3.1.
  2. NSX 4.1.2.1 does have optimizations to the dataplane fastpath to improve performance and reduce latencies.
    As a result of this, the evaluation of rules is different. Due to these changes, rules with 0.0.0.0 won't work in 4.1.2.1 as in this case, destinations are not being evaluated.

 

 

Resolution

There is no resolution, this is expected behavior.

To workaround this issue, we suggest to modify the rule by removing the quad 0s in the source and put ANY instead of that. This should solve the issue.

 

 

 

Additional Information

Please note: DHCP discovery broadcast traffic would get dropped and VMs won't be able to obtain IP addresses via DHCP.