Tuesday, 1 December 2015

Cross vCenter Networking and Security with Service Composer - NOT SUPPORTED

With the recent release of NSX 6.2 we now allow for cross vCenter Networking and Security.  This allows the security posture of your virtual machine to follow it when migrating from one vCenter to another.  As per the NSX 6.2 Cross vCener Installation Guide on page 18 service composer isn't actually supported but we can create local policies on each vCenter that populate a security group based on the name of the virtual machine.  When the VM vMotions from one vCenter to another the VM is removed from one security group and populate in the other.

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:

Ensure the same Security Group is created on both the Primary and Secondary NSX Managers.  Once completed if you have any VM's with the name "web" in the text then they should be members of the security group:

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:

No comments:

Post a Comment