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 NSXVMware NSX-T Data CenterVMware vDefend Firewall
Issue/Introduction
Symptoms:
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 Destination
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
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
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.
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.