Hello all,
Need some help with this questions:
1) Imagine that i have two groups of VMs:
Group A - VM1
Group B - VM2 + VM3
VM1 need to do SSH to VM2 and VM3, so the rule will be:
Sources - Group A | Destinations - Group B | Services - SSH |Applied to - Group B | Action - Allow
To prevent the apply rule to DFW i will apply to Group B, right? In this case it's easy, but how do i know to which group should i apply the rule?
2) Now i need to prevent that VMs on Goup B can do SSH to VM on Group A.
Sources - Group B | Destinations - Group A | Services - SSH |Applied to - Group A?? | Action - Drop
Should i create that rule, or if i create a bottom rule (the last rule) with any -> any, reject, i will prevent that?
3) The last rule (any -> any, reject), should i apply to DFW or to a group that contain all the vms that need to be secured by the firewall?
Thanks.
Regards.
A good practice to formulating rules is to imagine the packet flow, and where possible apply it to the source group. Remember, routing decisions are made on the source hypervisor, so makes sense to also apply the rules here. This is not possible when it is data coming externally from NSX-T into NSX-T. There are port optimizations for TCP and UDP ports in the dataplane when applying rules to VM's, this reduces the amount of lines each VM / logical port has worth of DFW rules.
For 2 - if you want a rule to explicitly call this out, then yes another rule and apply it to B, however your catch all deny will also get it.
3) the deny any any, I imagine you would want to catch all traffic, and not just that within NSX-T? If you apply this to a group that only NSX-T knows about, it will not deny traffic coming externally and not known by NSX-T. If you apply it to the DFW, the deny any any is applied to every port.
Hope this helps!
Hi,
You can checkout the reference design guide.
VMware® NSX-T Reference Design - VMware Technology Network VMTN
Chapter 5 NSX-T security (page 111)
I to would like to hear answer to Petersaints questions as even reference guide does not give super detail in dfw design.
My guess is answer to question 1 is yes Group B apply to, but also to Group A too. Not limited to just one Group in Apply to.
Maybe best to publsh policy and log into esxi host cli and run vsipioctl getrules and vsipioctl getaddrsets cmds to see rule logic?
A good practice to formulating rules is to imagine the packet flow, and where possible apply it to the source group. Remember, routing decisions are made on the source hypervisor, so makes sense to also apply the rules here. This is not possible when it is data coming externally from NSX-T into NSX-T. There are port optimizations for TCP and UDP ports in the dataplane when applying rules to VM's, this reduces the amount of lines each VM / logical port has worth of DFW rules.
For 2 - if you want a rule to explicitly call this out, then yes another rule and apply it to B, however your catch all deny will also get it.
3) the deny any any, I imagine you would want to catch all traffic, and not just that within NSX-T? If you apply this to a group that only NSX-T knows about, it will not deny traffic coming externally and not known by NSX-T. If you apply it to the DFW, the deny any any is applied to every port.
Hope this helps!
Hello @shank89 ,
Thanks for your answer.
Other doubt, about the deny any any rule:
The management vNIC of NSX-T Managers, Edge nodes, vCenter, DNS, are on a vlan backed, out of NSX-T. If i create a deny any any rule, applied to DFW, that rule will block the traffic on the management vNIC of those components? If so, should i create a exclude list to those components? Or exists a better practice to prevent that?
Thanks,
Regards
That's correct, the deny will drop the traffic. You'll need to create rules to allow the traffic for groups or vms that you wish to allow. There is no exclude, the other thing is negate. As long as the VMs are in the same vCenter, then you should be able to create dynamic based groups or statiic if you wish and not have to use IP sets.
Please don't forget to kudo useful posts and mark a solution you think is correct for you!
NSX components are automatically excluded, you don't have to exclude them manually.
Good catch, forgot about that!