In a prior post, Multi-site with Cross-VC NSX: Consistent Security and Micro-segmentation Across Sites, we discussed how Cross-VC NSX provides micro-segmentation and consistent security across multiple sites. We looked at five reasons to seriously consider Cross-VC NSX for a multi-site solution in terms of security alone: centralized management, consistent security across vCenter domains/sites, security policies follow the workload(s), ease of security automation across vCenter domains/sites, and enhanced disaster recovery use case. In this post, we’ll discuss how advanced third party security services can also be leveraged in a Cross-VC NSX environment.
Prior Cross-VC NSX Blogs:
Multi-site with Cross-VC NSX: Consistent Security and Micro-segmentation Across Sites
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 Solutions
NSX provides a solid platform for security in general: inherent isolation via logical networks, micro-segmentation via distributed firewall, edge firewall capabilities, third party guest introspection services, third party network introspection services, and a robust security policy orchestration and automation framework.
With Cross-VC NSX, micro-segmentation and consistent security policies for workloads expands beyond a single vCenter boundary. Typically, customers who have multiple sites also have multiple vCenters – at least one vCenter per site.
Figure 1 Micro-segmentation and Consistent Security Across Sites with Centralized Management
Sometimes multiple vCenters are also required by the solution, such as the case of a disaster recovery solution employing VMware SRM where a separate vCenter is required at the protected and recovery sites respectively for additional segmentation/isolation.
Figure 2 Disaster Recovery Solution with Cross-VC NSX
For the reasons mentioned above along with the benefits of expanded workload mobility and resource pooling across vCenter domains, Cross-VC NSX provides a powerful use case for achieving micro-segmentation and consistent security policies with centralized management across multiple vCenter domains residing across multiple sites.
On top of all the benefits inherently present with NSX simply by leveraging the Universal Distributed Firewall (UDFW), advanced security services can also be leveraged in a Cross-VC NSX environment for application/L7-level security (IPS/IDS, URL Filtering, Application Identification, Anti-virus, Anti-bot, etc.). Figure 3 below shows how such a setup would look, for example, leveraging network introspection services where a Service VM (SVM) is deployed on each ESXi host. A third party SVM is deployed on each ESXi host locally at each site. All ESXi hosts which may have workloads requiring advanced third party security protection have a SVM deployed; the third party security service is deployed locally at each site and traffic is also redirected locally to the respective SVM.
Figure 3 Third Party Security Deployed with Cross-VC NSX
Figure 4 below shows a diagram of a deployed lab setup where Palo Alto Networks integration with NSX is leveraged. A Panorama instance and respective Service VMs are deployed at each site within the Cross-VC NSX environment.
Figure 4 Palo Alto Networks Deployed with Cross-VC NSX
In the setup in Figure 4 above, traffic redirection rules need to be configured locally at each site as the redirection rule is not automatically synchronized across NSX Managers; however, leveraging NSX REST API, it’s possible to automate this step.
Figures 5 and 6 below respectively, show a Palo Alto Networks service manager and service profile installed on the Primary NSX Manager. This is done through the Palo Alto Networks Panorama instance deployed at site 1. The same procedure is followed at site 2, except using the Panorama instance deployed at site 2.
Figure 5 Palo Alto Networks Service Manager Installed on Primary NSX Manager
Figure 6 Palo Alto Networks Service Profile Installed on Primary NSX Manager
Looking at the Installation -> Service Deployments tab on the Primary NSX Manager, we can see the Palo Alto Networks SVM has been installed on all ESXi hosts in Compute Cluster 1 and Compute Cluster 2 at Site 1, Palo Alto.
Figure 7 Palo Alto Networks SVM Installed on Compute Cluster 1 and Compute Cluster 2 at Site 1, Palo Alto
Similarly, looking at the Installation -> Service Deployments tab on the Secondary NSX Manager, we can see the Palo Alto Networks SVM has been installed on all ESXi hosts in Compute Cluster 1 and Compute Cluster 2 at Site 2, San Jose. It’s important to note the deployment of the SVMs is done locally at each site from the local Panorama instance.
Figure 8 Palo Alto Networks SVM Installed on Compute Cluster 1 and Compute Cluster 2 at Site 2, San Jose
Looking at the respective clusters and hosts via vSphere Web Client, we can see a Palo Alto Networks SVM has been deployed on each host in the respective clusters at both sites.
Figure 9 Palo Alto Networks SVM Installed on all Respective Compute Clusters and Hosts at Both Sites
The redirection rule configured under Firewall->Partner security services for both the Primary and Secondary NSX Managers is shown below in Figures 10 and 11 respectively. The Web Universal Logical Switch is used in the source field and a Universal Security Group containing a Universal IP Set for the workloads on the App Universal Logical Switch is used in the destination field. Thus, all local traffic from the web tier going to app tier will be redirected to the Palo Alto Networks SVM.
Figure 10 Redirection Rule on Primary NSX Manager – Site 1
Figure 11 Redirection Rule on Secondary NSX Manager – Site 2
Now that the Palo Alto Networks service has been installed and configured locally at both sites, Palo Alto Networks SVMs deployed, and respective traffic redirection rules configured, security policies can be created via Panorama and pushed down to the respective SVMs as depicted in Figure 12 below.
Figure 12 Palo Alto Networks Security Policies Applied and Committed to Local SVMs
Similar to the redirection rule that needs to be configured locally at each site, security policies in Panorama also have to be configured locally within each Panorama instance at the respective site. Palo Alto Networks showed an interesting demo in their VMworld 2016 booth where they demonstrated how Palo Alto Networks REST API can be utilized to automate the synchronization of policies. The demo showed that when a security policy is created on the Panorama instance at site 1 it’s automatically synced to the Panorama instance at site 2. Thus, through scripting and leveraging the Palo Alto REST API it’s possible to automate the synchronization of rules across Panorama instances.
Figure 13 below shows a security policy being configured within Panorama leveraging the NSX objects it learned from the DFW redirection rule.
Figure 13 Configuring Palo Alto Networks Security Policies in Panorama at Site 1
Figure 14 below shows the Palo Alto Networks security policies being committed and pushed to respective SVMs at site 1.
Figure 14 Committing Palo Alto Networks Security Policies in Panorama to Local SVMs
To see a demo and walkthrough of everything discussed in this post, make sure to check-out the video at the top of this page. I also used this demo at VMworld 2016 in the following session: Multisite Networking and Security with Cross-vCenter NSX: Part 2 [NET7861R]; see the recording for additional information.
In conclusion, Cross-VC NSX enables consistent security across sites with the UDFW and UDFW rules which are automatically synchronized across NSX Managers/sites. In addition, third party security services such as Palo Alto Networks can also be leveraged in a Cross-VC NSX environment for application/L7-level advanced security services.
Comments
0 Comments have been added so far