In my environment I have two vCenter servers called NY-VCSA-01 and PA-VCSA-02 with the following compute, management and workloads:
The default Distributed Firewall Policy for both vCenters is to reject:
I'm now going to create a new security group within Service Composer and populate it based on the virtual machine name containing the work "web". First go into Service Composer and create a new security group:
Give it a name and click Next:
Set the correct matching criteria which in my case is to populate the group if the VM Name contains the word "web" then click Finish:
We are now going to create the policy that we will apply to the security group. The policy will be configured accordingly:
ANY -> Security Group -> HTTP/HTTPS -> Allow
ANY -> Security Group -> SSH -> Allow
ANY -> Security Group -> ICMP Echo / ICMP Echo Reply -> Allow
Go back into Service Composer and create a new policy and give it a name:
Create the firewall rules as required and then click Finish:
Apply the policy to the security group:
Ensure you have identical security groups and policies on both the primary and secondary NSX Managers.
I currently have WEB01 running in NY-VCSA-01 and WEB02 running in PA-VCSA-01 and I can check what distributed firewall rules are currently being applied:
Now when I vMotion WEB01 from NY-VCSA-01 to PA-VCSA-02 the VM will be removed from the Web Servers security group in NY-VCSA-01 and then populated into the Web Servers security group in PA-VCSA-01. I've tested this via pinging WEB01 during the migration. As you can see the VM pings fine and then the connectivity drops. This happens when the VM is removed from the security group on NY-VCSA-01 and not yet a member of the security group in PA-VCSA-01 so the default deny rule is being applied. Once the VM is populated in the security group in PA-VCSA-01 the rules apply and connectivity is restored:
As we can see the VM is now in PA-VCSA-01 and the same firewall rules are being applied: