VMware Networking Community
rogerscual
Enthusiast
Enthusiast
Jump to solution

Block traffic using security groups.

I want to block all traffic between two VM's, for that I have created Security Group in Service Composer named SG-WEB.Screen Shot 2015-10-12 at 9.57.29 PM.png

In the DFW I have two simple rules:

Screen Shot 2015-10-12 at 9.59.02 PM.png

One rule that block the traffic between the security group SG-WEB and another that permits everything else. But I still can ping WEB1 from WEB2 and vice versa. From the ESXi if I look to the log of the FW I can see the traffic getting permitted for the L2.

If instead of Security Groups I use subnets, everything works well. I know that I have used Security Groups to identify traffic in the DFW but here does not work at all, is this a bug or I'm missing some configuration needed for this to happen?

Thanks.

Tags (2)
1 Solution

Accepted Solutions
Richard__R
Enthusiast
Enthusiast
Jump to solution

What's the status of VMware Tools in these VMs?

View solution in original post

6 Replies
Richard__R
Enthusiast
Enthusiast
Jump to solution

What's the status of VMware Tools in these VMs?

greco827
Expert
Expert
Jump to solution

Try creating a new security group, SG-WEB2, and place WEB2 into it, just as a test.  I think the issue may be that your source and destination groups are the same.

If you find this or any other answer useful please mark the answer as correct or helpful https://communities.vmware.com/people/greco827/blog
Reply
0 Kudos
BrandonArms
Contributor
Contributor
Jump to solution

change your "apply to" to either the logical switch that the vm's connect to or the DFW

Reply
0 Kudos
DaleCoghlan
VMware Employee
VMware Employee
Jump to solution

Richard__R‌ is on the right track. As you are referencing a vCenter Object (VM) in the rule (in your case, through a security group), in NSX versions 6.0.x and 6.1.x, for the DFW to be able to enforce policy/rules on a VM, NSX must know the IP address assigned to the VM.

Even if you change the "Applied to" field to be the logical switch, you would still have the same outcome. In fact with the Applied to field configured as shown, it is working correctly to limit the applied to scope of the rule, its just that the DFW needs to know what the IP address of each VM is, so that it can write specific IP rules, which it can then match against the packets passing through the VSIP module. As the packet will not be able to match rule 1, it will then match rule 2 which permits the traffic.

Why does it work when using subnets? Thats because there is no IP to VM lookup that needs to occur. The rule already specifies the subnet to match a packet on, hence the rule will be matched.

In NSX-v 6.2.x, new IP discovery techniques were introduced, ARP Snooping & DHCP Snooping which remove the requirement for VMTools to be installed on a VM for DFW to enforce policy. You can read more about it on this post NSX-v 6.2 What’s New: IP Discovery | SneakU

If you are running nsx 6.0.x or nsx 6.1.x and need to look at the filters and addrsets, you will need to know how to use vsipioctl, which you can read about in the following post https://networkinferno.net/validating-distributed-firewall-rulesets-in-nsx

Dale

Richard__R
Enthusiast
Enthusiast
Jump to solution

You should be able to use the same security group for source/dest and Applied To. Seems more like the IPs of the VMs haven't been captured which would typically rely on VMware Tools despite some new mechanisms in 6.2.

EDIT: think I was typing this at the same time as the post above which does a better job of explaining it Smiley Happy

Reply
0 Kudos
rogerscual
Enthusiast
Enthusiast
Jump to solution

That worked, once the VMware-Tools were installed the security-group populated the information.

Screen Shot 2015-10-13 at 9.47.31 PM.png

And now everything is working correctly.

Thanks.

Reply
0 Kudos