Several posts have been written prior on multi-site with Cross-VC NSX describing the fundamentals, use cases, deployment models, and flexibility Cross-VC NSX provides. In this post, we focus on the security benefits of a multi-site Cross-VC NSX solution.
Prior Cross-VC NSX Blogs:
Cross-VC NSX: Multi-site Deployments with Ease and Flexibility
NSX-V: Multi-site Options and Cross-VC NSX Design Guide
Enhanced Disaster Recovery with Cross-VC NSX and SRM
Cross-VC NSX for Multi-site SolutionsSo, why multi-site with Cross-VC NSX? The following five reasons should be enough for you to seriously consider Cross-VC NSX as a solution for your multi-site needs:
1.) Centralized Management
Centralized management of security policies across multiple vCenter domains/sites. You have one central location to configure security policies and only write the security policy once, which is then applied across all vCenter domains/sites.
Figure 1 Central Management of Security Policies Across Sites from Primary NSX Manager
Consistent security policies across vCenter domains/sites provided automatically by Cross-VC NSX enables enhanced workload mobility. Security policies are configured on the primary NSX Manager and automatically synced to the secondary NSX Managers providing for uniform security across all sites.
Figure 2 Consistent Security Across Sites with Universal Distributed Firewall
Cross-VC NSX enables enhanced workload mobility by making it possible to extend logical networks across multiple vCenter domains/sites. In addition, Cross-VC NSX ensures the security policies follow the workload as it is vMotioned or migrated across vCenter domains/sites.
Figure 3 Security Policies Follow Workloads Across vCenter Domains and Sites
Security policies can be configured via GUI on the primary NSX Manager and are then automatically synced to the secondary NSX Managers. However, NSX Rest API calls can also be utilized. One NSX REST API call to the primary NSX Manager applies the same security policy across all vCenter domains/sites. As such, the respective API calls can be included in advanced workflows to provide for ease of security automation across vCenter domains/sites.
Figure 4 One NSX REST API Call to Primary NSX Manager to Create Security Policy Allows for Ease of Security Automation
Consistent networking and security across sites prevents the need for manual security replication across sites for disaster recovery scenarios. Also, universal logical networking across sites allows for the application IP address to remain the same preventing the need to update security policies.
Figure 5 Applications Recover with Same IP Address and Security Policies
Bottom-line is Cross-VC NSX allows for consistent security and micro-segmentation across vCenter boundaries with the Universal Distributed Firewall (UDFW) and Universal Distributed Firewall Rules.
Figure 6 Consistent Security and Micro-segmentation Across Sites via Universal Distributed Firewall
Additionally, the Universal section of the DFW supports the belownetwork and security grouping objects. Grouping objects are used to identify endpoints.
Universal Grouping Objects Universal Security Groups Universal IP Sets Universal MAC Sets Universal Services Universal Service GroupsThe demo video at the top of this post demonstrates consistent security and micro-segmentation across sites using theUDFW. As shown below in Figure 7, Cross-VC NSX is deployed across two sites. Universal Logical Switches (ULS) exist across both sites for Web, App, and DB tiers of a 3-tier application.
Initially, all the VMs and entire application is at site 1, and a VM on the Web ULSis communicating to a VM on the DB ULS.
Figure 7 Web VM on Web ULS Communicating With DB VM on DB ULS
However, VMs on the Web tier should never directly communicate with VMs on the DB tier, and, instead should go through the App tier. As such, a UDFW rule containingUniversal Security Groups which contain Universal IP Sets is used to prevent communication between the Web and DB tiers. The UDFW rules are shown below in Figure 8.
Figure 8 UDFW Rules Preventing Communication Between Web and DB Tiers
The result of this UDFW configuration, as shown below in Figure 9, is that the Web VM on the Web ULS and the DB VM on the DB ULS can no longer communicate directly, which is the desired result.
Figure 9 Web VM on Web ULS Can No Longer Communicate to DB VM on DB ULS Due to Configured UDFW Rule
As the Web VM or part of the application movesto site 1 as shown below, the security policies for the respective workload follow and consistent security across sites ismaintained.
Figure 10 Web VM Moves to Site 2 and Respective Security Policies Follow
As the DB VM, or even if the entire application moves to site 2, the application security policies follow the respective workload(s) and consistent security across sites is maintained. This is shown below in Figure 11.
Figure 11 DB VM Moves to Site 2 and Respective Security Policies Follow
In the demo video at the top of this post, I step through and demonstrate consistent security and micro-segmentation across sites using the UDFW as explained above. I also used this demo at VMworld 2016 in the following session: Multisite Networking and Security with Cross-vCenter NSX: Part 2 [NET7861R] ; the recording can be watched online once made available.In a follow-up post to this, I’ll demonstrate how we can leverage third party security services in a Cross-VC NSX environment. A demo of this specific scenario was also shown in the above mentioned VMworld session and will be discussed in detail in the next follow-up post.
In summary, witha Cross-VC NSX multi-site solution, users automatically get central management of security policies, consistent security and micro-segmentation, and ability for ease of advanced security automation across multiple vCenter domains and sites. In addition, the security policies follow the workload(s) across vCenter domains and sites. Also,
