What you've experienced is as expected. When a group is used in the AppliedTo field of a rule, it is used to generate a list of logical ports (VIFs) that the firewall rule will be programmed onto.
Now if that group your using in the AppliedTo field only contains IP addresses, then there is no guaranteed way for the system to auto resolve those to a logical port (VIF). Hence if you remove the group and set the AppliedTo to be the DFW, then the rule will be programmed onto every logical port(VIF) and your rule appears to work, at the expense of memory consumption.
The next question that people normally ask after the above statement is "why can't NSX-T figure out the IP to logical port mapping itself so that we can use IP based groups in the applied to field". And the response is that NSX-T allows for the use of overlapping IP Addressing. So you may use the IP address 192.168.1.10 in a rule, but you have multiple tenants and they all happen to have a VM with the IP address of 192.168.1.10, so the question then becomes, which VM, or logical port, do you actually need to apply it to, because you probably don't want it to automagically apply a rule meant for Tenant A VM to Tenant B's VM.
But using groups where they only contain IPs (or in NSX-T 3.x using RAW IPs) doesn't preclude you from utilising the AppliedTo field. In these instances, if the IP addresses used in the source and/or destination are associated with a NSX-T segment, then you can create a new group and add the associated segment to the group, and then use the group with the segment in it in the AppliedTo field.
This means the rule will still be programmed onto all the logical ports (VIFs) connected to the segment, which should include the ones your interested in, so its scope is a bit bigger than just the individual workloads, but its limited to only those subsets of logical ports(VIFs) rather than every logical port in the environment and is still classed as a valid use of AppliedTo.
Dale
