IP address 0.0.0.0 or 0.0.0.0/32 as a Container IP in Firewall data plane in NSX
search cancel

IP address 0.0.0.0 or 0.0.0.0/32 as a Container IP in Firewall data plane in NSX

book

Article ID: 325085

calendar_today

Updated On:

Products

VMware NSX

Issue/Introduction

Symptoms:

  • Whenever an IP address 0.0.0.0 or 0.0.0.0/32 is configured as IPSet and applied to a Security Group, then firewall default deny action will occur.
  • Whenever an IP address 0.0.0.0 or 0.0.0.0/32 used in a FW Rule along with any other Source/Destination IP address, firewall rule action will not happen for 0.0.0.0/32, action applies to other IP(s).

Non-working condition:

Container set (Security Group containing IPSet as 0.0.0.0 or 0.0.0.0/32)
vsipioctl getaddrsets -f nic-69152-eth0-vmware-sfw.2
addrset ip-ipset-4
{
} -----------> empty here

DFW dropping the packets as it hits default deny since it cant match the correct rule as addrsets is empty.

OR

0.0.0.0/32 configured along with 10.0.0.0/32 IP, only 10.0.0.0 shows up in address sets
] vsipioctl getaddrsets -f nic-69152-eth0-vmware-sfw.2 | grep -A 3 23869
addrset rsrc23869 {
ip 222.0.0.0,
}

addrset src21978 {
[root@sc2-rdops-vm09-dhcp-61-132:/var/log] vsipioctl getrules -f nic-69152-eth0-vmware-sfw.2 | grep 23869
  rule 23869 at 4 inout protocol any from addrset rsrc23869 to any accept with log;

Environment

VMware NSX for vSphere 6.3.x

Resolution

This issue is resolved in VMware NSX for vSphere 6.3.7, available at VMware Downloads.

In VMware NSX for vSphere 6.4.1 a ‘Critical’ event will be generated for an IPSet containing either 0.0.0.0 or 0.0.0.0/32 address' 




 

 


Workaround:
To work around this issue if you do not want to upgrade, use IP address 0.0.0.0 or 0.0.0.0/32 in Firewall rule's Source or Destination IP with an action.

For example:

Working:

vsipioctl getrules -f nic-69152-eth0-vmware-sfw.2 | grep "ip 0."
rule 23869 at 4 inout protocol any from ip 0.0.0.0 to any accept;