This is the third of a series of 5 demos that show how the NSX Security Model works through several use cases. Don’t just believe what you see, try it yourself for free with VMware Hands-On-Labs (see below):
In this video, we discuss the way in which Neutron, the networking project of OpenStack, and VMware NSX interact. We cover the basic Neutron workflows and their situation as it relates to the application, as well as the corresponding NSX element that is leveraged each time. With this, we aim to describe how NSX ultimately brings stability to Neutron
This is the second of a series of 5 demos that show how the NSX Security Model works through several use cases. Don’t just believe what you see, try it yourself for free with VMware Hands-On-Labs (see below):
This is the first of a series of 5 demos that show how the NSX Security Model works through several use cases. Don’t just believe what you see, try it yourself for free with VMware Hands-On-Labs (see below):
VMware NSX for vSphere, release 6.0.x.
This document covers how one can create security policy rules in VMware NSX. This will cover the different options of configuring security rules either through the Distributed Firewall or via the Service Composer User Interface. It will cover all the unique options NSX offers to create dynamic policies based on the infrastructure context.
Thanks to Francis Guillier, Kausum Kumar and Srini Nimmagadda for helping author this document.
VMware NSX Distributed Firewall (DFW) provides the capability to enforce firewalling functionality directly at the Virtual Machines (VM) vNIC layer. It is a core component of the micro-segmentation security model where east-west traffic can now be inspected at near line rate processing, preventing any lateral move type of attack.
This technical brief gives details about DFW policy rule configuration with NSX. Both DFW security policy objects and DFW consumption model will be discussed in this document.
We assume reader has already some knowledge on DFW and Service Composer functions. Please refer to the appropriate collateral if you need more information on these NSX components.
Distributed Firewall Object Grouping Model
NSX provides the capability to micro-segment your SDDC to provide an effective security posture. To implement micro-segmentation in your SDDC, NSX provides you various ways of grouping VMs and applying security policies to them. This document specifies in detail different ways groupings can be done and details on when you should use one over the other.
Security policy rules can be written in various ways as shown below:
Network Based Policies:
- This is the traditional approach of grouping based on L2 or L3 elements. Grouping can be based on MAC addresses or IP addresses or a combination of both. NSX supports this approach of grouping objects. The security team needs to aware of networking infrastructure to deploy network-based policies. There is a high probability of security rule sprawl as grouping based on dynamic attributes is not used. This method of grouping works great if you are migrating existing rules from a different vendor’s firewall.
When not to use this: In dynamic environments, e.g. Self-Service IT; Cloud automated deployments, where you are adding/deleting of VMs and application topologies at a rapid rate, MAC addressed based grouping approach may not be suitable as there will be delay between provisioning a VM and adding the MAC addresses to the group. If you have an environment with high mobility like vMotion and HA, L3/IP based grouping approaches may not be adequate either.
Infrastructure Based Policies:
- In this approach, grouping is based on SDDC infrastructure like vCenter clusters, logical switches, distributed port groups, etc. An example of this would be, clusters 1 to cluster 4
are earmarked for PCI kind of applications. In such a case, grouping can be done based on cluster names and rules can be enforced based on these groups. Another example would be, if you know which logical switches in your environment are connected to which applications. E.g. App Tier Logical switch contains all VMs pertaining to application ‘X’. The security team needs to work closely with the vCenter administration team to understand logical and physical boundaries.
When not to use this: If there are no physical or logical boundaries in your SDDC environment then this type of approach is not suitable. Also, you need to be very careful where you can deploy your applications. For example, if you would like to deploy a PCI workload to any cluster that has adequate compute resources available; the security posture cannot be tied to a cluster but should move with the application.
Application Based Policies:
- In this approach, grouping is based on the application type (e.g: VMs tagged as “Web_Servers”), application environment (e.g: all resources tagged as “Production_Zone”) and application security posture. The advantage of this approach is that the security posture of the application is not tied down to either network constructs or SDDC infrastructure. Security policies can move with the application irrespective of network or infrastructure boundaries. Policies can be templated and reusable across instances of same types of applications and workloads. You can use variety of mechanisms to group. The security team needs to be aware of only the application that it is trying to secure based on the policies. The security policies follow the application life cycle, i.e. comes alive when the application is deployed and is destroyed when the application is decommissioned.
When not to use this: If the environment is pretty static without mobility and infrastructure functions are properly demarcated. You do not need to use application-based policies.
Application-based policy approach will greatly aid in moving towards a Self-Service IT model. The Security team needs to be only aware of how to secure an application without knowing the underlying topology. Concise and reusable security rules will require application awareness. Thus a proper security posture can be developed via application based policies.
Security-Groups is a container-construct which allows to group vCenter objects into a common entity.
When defining a Security-Groups, multiple inclusion and exclusion can be used as shown in the diagram below:
Download a full VMware NSX DFW Policy Rules Configuration Technical White Paper
VMware NSX for vSphere, release 6.0.x.
This document guides you through the step-by-step configuration and validation of NSX-v for microsegmentation services. Microsegmentation makes the data center network more secure by isolating each related group of virtual machines onto a distinct logical network segment, allowing the administrator to firewall traffic traveling from one segment of the data center to another (east-west traffic). This limits attackers’ ability to move laterally in the data center.
VMware NSX uniquely makes microsegmentation scalable, operationally feasible, and cost-effective. This security service provided to applications is now agnostic to virtual network topology. The security configurations we explain in this document can be used to secure traffic among VMs on different L2 broadcast domains or to secure traffic within a L2 broadcast domain.
Microsegmentation is powered by the Distributed Firewall (DFW) component of NSX. DFW operates at the ESXi hypervisor kernel layer and processes packets at near line-rate speed. Each VM has its own firewall rules and context. Workload mobility (vMotion) is fully supported with DFW, and active connections remain intact during the move.
This paper will guide you through two microsegmentation use cases and highlight steps to implement
them in your own environment.
Use Case and Solution Scenarios
This document presents two solution scenarios that use east-west firewalling to handle the use case of
securing network traffic inside the data center. The solution scenarios are:
- Scenario 1: Microsegmentation for a three-tier application using three different layer-2 logical segments (here implemented using NSX logical switches connected over VXLAN tunnels):
In Scenario 1, there are two VMs per tier, and each tier hosts a dedicated function (WEB / APP / DB
services). Traffic protection is provided within the tier and between tiers. Logical switches are used to
group VMs of same function together.
- Scenario 2: Microsegmentation for a three-tier application using a single layer-2 logical segment:
In Scenario 2, all VMs are located on same tier. Traffic protection is provided within tier and per function (WEB/ APP/ DB services). Security Groups (SG) are used to logically group VMs of same function together.
For both Scenario 1 and Scenario 2, the following security policies are enforced:
For Scenario 1, a logical switch object is used for source and destination fields. For Scenario 2, a Service Composer / Security Group object is used for source and destination fields. By using these vCenterdefined objects, we optimize the number of needed firewall rules irrespective of number of VMs per tier (or per function).
NOTE: TCP port 1433 simulates the SQL service.
Two ESXi hosts in the same cluster are used. Each host has following connectivity to the physical
- one VLAN for management, vMotion, and storage. Communication between the ESXi host and the NSX Controllers also travels over this VLAN.
- one VLAN for data traffic: VXLAN-tunneled, VM-to-VM data traffic uses this VLAN.
- Web-01, app-01 and db-01 VMs are hosted on the first ESXi host.
- Web-02, app-02 and db-02 VMs are hosted on the second ESXi host.
The purpose of this implementation is to demonstrate complete decoupling of the physical infrastructure from the logical functions such as logical network segments, logical distributed routing and DFW.
In other words, microsegmentation is a logical service offered to an application infrastructure irrespective of physical component. There is no dependency on where each VM is physically located.
The VMware NSX network virtualization platform is a critical pillar of VMware’s Software Defined Data Center (SDDC) architecture. NSX network virtualization delivers for networking what VMware has already delivered for compute and storage. In much the same way that server virtualization allows operators to programmatically create, snapshot, delete and restore software-based virtual machines (VMs) on demand, NSX enables virtual networks to be created, saved and deleted and restored on demand without requiring any reconfiguration of the physical network.
The result fundamentally transforms the data center network operational model, reduces network provisioning time from days or weeks to minutes and dramatically simplifies network operations.
Due to the critical role NSX plays within an organization, hardening of the product along with secure topology will reduce the risk an organization may face. This document is intended to provide configuration information and topology recommendations to ensure a more secure deployment.
This paper is a draft document which covers some fundamentals of how one can securely deploy network virtualization with NSX. Updated with correct document.
NSX Traffic [Control, Management, and Data]
The main components of NSX include the NSX Manager, NSX Edge/Gateway, NSX Controllers, and NSX vSwitch. Great care must be given toward the placement and connectivity of these components within an organization’s network. NSX functions can be grouped into three categories: management plane, control plane, and data plane.
The consumption of NSX can be driven directly via the NSX manager UI. In a vSphere environment this is available via the vSphere web interface. Typically end-users tie in network virtualization to their cloud management platform for deploying applications. NSX provides a rich set of integration into virtually any CMP via the REST API. Out of the box integration is also available through VMware vCloud Automation Center.
The NSX management plane is built by the NSX Manager. The NSX manager provides the single point of configuration and the REST API entry-points in a vSphere environment for NSX. The NSX Manager is also the integration point with vCenter.
Network traffic to and from the NSX Manager should be restricted and it’s recommended that it be placed on a management network where access is limited.
Access to the NSX manager utilizes a web redirect to only allow access via HTTPS.
Traffic from the NSX manager to other components such as vCenter and the ESXi is encrypted. These safe guards reduce some of the risk to the NSX manager, but it is recommended that it be separated from other traffic via physical or VLAN separation, at a minimum. The VMware vSphere Hardening Guides (http://www.vmware.com/security/hardening-guides.html) can be used to further explore protection of the management network.
The NSX Controller is the heart of the control plane. In a vSphere-optimized environment where VMware’s virtual distributed switches (VDS) are deployed, the controllers enable multicast free network virtualization and control plane programming of elements that enable logical distributed routing and logical network traffic within and across hypervisors.
In all cases, the controller is purely a part of the control plane and does not have any data plane traffic passing through it. The controller nodes are also deployed in a cluster of odd members in order to enable high-availability and scale. Any failure of the controller nodes does not impact any existing data plane traffic.
These communications does not carry any sensitive application data, but it is required for NSX to work properly. As of version 6.0.4 of NSX, controller to controller communication is unencrypted along with hypervisor to controller communication. Hence, it’s recommended that it be separated from other traffic via physical or VLAN separation, at a minimum. No user machines should be on this network.
The NSX Data plane consists of the NSX vSwitch. The vSwitch in NSX for vSphere is based on the vSphere Distributed Switch (VDS) with additional components to enable rich services. The add-on NSX components include kernel modules (VIBs) which run within the hypervisor kernel providing services such as distributed routing, distributed firewall and enable VXLAN bridging capabilities.
The NSX vSwitch (VDS) abstracts the physical network and provides access-level switching in the hypervisor. It is central to network virtualization because it enables logical networks that are independent of physical constructs such as VLAN. Some of the benefits of the VDS are:
- Support for overlay networking leveraging the VXLAN and centralized network configuration. Overlay networking enables the following capabilities:
- o Creation of a flexible logical layer 2 (L2) overlay over existing IP networks on existing physical infrastructure without the need to re-architect any of the data center networks
o Provisioning of communications (east–west and north–south) while maintaining isolation between tenants
o Application workloads and virtual machines that are agnostic of the overlay network and operate as if they were connected to a physical L2 network
- NSX vSwitch facilitates massive scale of hypervisors.
- Multiple features—such as Port Mirroring, NetFlow/IPFIX, Configuration Backup and Restore, Network Health Check, QoS, and LACP—provide a comprehensive toolkit for traffic management, monitoring and troubleshooting within a virtual network.
Additionally, the data plane also consists of gateway devices that can either provide L2 bridging from the logical networking space (VXLAN) to the physical network (VLAN).
The gateway device is typically an NSX Edge virtual appliance. NSX Edge offers L2, L3, perimeter firewall, load balancing and other services such as SSL VPN, DHCP, etc
Topology and the NSX Manager Virtual Machine
The NSX Manager virtual machine (VM) is part of the management plane, certain considerations must be taken into account when deciding where to install and connect the VM.
1. Placement: Best practices dictate that the NSX Manager should be placed in a segmented and secured network. Since the NSX manager and vCenter are in continuous communication, it is recommended they be placed on the same network. Typically, the NSX manager and vCenter are placed on a management network where access is limited to specific users and/or systems. The management network should not contain any user or general network traffic.
2. Physical and network security: The following table provide ports use for communication with the NSX Manager. If you are securing the NSX manager from other network services, make sure the appropriate ports are open.
Download a full Securing VMware® NSX Technical White paper
VMware NSX Hardening Guide Authors: Pravin Goyal, Greg Christopher, Michael Haines, Roberto Mari, Kausum Kumar, Wade Holmes
This is the Version 1.6 of the VMware® NSX for vSphere Hardening Guide.
This guide provides prescriptive guidance for customers on how to deploy and operate VMware® NSX in a secure manner.
Acknowledgements to the following contributors for reviewing and providing feedback to various sections of the document: Kausum Kumar, Roberto Mari, Scott Lowe, Ben Lin, Bob Motanagh, Dmitri Kalintsev, Greg Frascadore, Hadar Freehling, Kiran Kumar Thota, Pierre Ernst, Rob Randell, Roie Ben Haim, Yves Fauser
Guide is provided in an easy to consume spreadsheet format, with rich metadata (i.e. similar to existing VMware vSphere Hardening Guides) to allow for guideline classification and risk assessment.
Feedback and Comments to the Authors and the NSX Solution Team can be posted as comments to this community Post (Note: users must login on vmware communities before posting a comment).
Download a full NSX-v Security Hardering Guide
The intended audience for this document includes virtualization and network architects seeking to deploy VMware® NSX™ for vSphere® in combination with F5® BIG-IP® Local Traffic Manager™ devices.
Note: A solid understanding based on hands-on experience with both NSX-v and F5 BIG-IP LTM is a pre-requisite to successfully understanding this design guide.
NSX deployments can be today coupled with F5 BIG-IP appliances or Virtual Edition.
Such deployment gives to NSX customers a flexible, powerful, and agile infrastructure with the richness of F5 ADC service.
Note: F5 deployment + configuration done from F5.
The Software Defined Data Center is defined by server virtualization, storage virtualization and network virtualization and server virtualization has already proved the value of SDDC architectures in reducing costs and complexity of compute infrastructure. VMware NSX network virtualization provides the third critical pillar of the SDDC and extends the same benefits to the data center network to accelerate network service provisioning, simplify network operations and improve network economics.
VMware NSX-v is the leading network virtualization solution in the market today and is being deployed across all vertical markets and market segments. NSX reproduces L2-L7 networking and security including L2 Switching, L3 Routing, Firewalling, Load Balancing, and IPSEC/VPN secure access. services completely in software and allows programmatic provisioning and management of these services. More information about these functions is available in the NSX Design Guide.
F5 BIG-IP is the leading application delivery controller in the market today. The BIG-IP product family provides Software-Defined Application Services™ (SDAS) designed to improve the performance, reliability and security of mission-critical applications. BIG-IP is available in a variety of form factors, ranging from ASIC-based physical appliances to vSphere-based virtual appliances. NSX deployments can be coupled with F5 BIG-IP appliances or Virtual Edition form factors.
Furthermore, F5 offers a centralized management and orchestration platform called BIG-IQ.
By deploying BIG-IP and NSX together, organizations are able to achieve service provisioning automation and agility enabled by the SDDC combined with the richness of the F5 application delivery services they have come to expect.
This design guide provides recommended practices and topologies to optimize interoperability between the NSX platform and F5 BIG-IP physical and virtual appliances. This interoperability design guide is intended for those customers who would like to adopt the SDDC while ensuring compatibility and minimal disruption to their existing BIGIP environment. The Recommended practice guide will provide step-by-step guidance to implement the topologies outlined in this document.
NSX/F5 Topology Options
“BIG-IP Form Factor” / “NSX overlay or not” / “BIG-IP placement” Relationships
There are about 20 possible topologies that can be used when connecting BIG-IP to an NSX environment but this Design Guide will focus on the three that best represent the form factor, connection method, and logical topology combinations. In addition, the Design Guide will highlight the Pros and Cons of each of the three topologies.
The following figure describes the relationship of:
- BIG-IP form factor:
o BIG-IP Virtual Edition (“VE”)
o BIG-IP physical appliance
- With NSX overlay/Without NSX overlay:
o non-VXLAN (VLAN tagged on untagged)
- BIG-IP placement:
o BIG-IP parallel to NSX Edge
o BIG-IP parallel to DLR
o BIG-IP One-Arm connected to server network(s)
o BIG-IP on top of NSX Edge
o BIG-IP on top of NSX DLR
This design guide provides recommended practices and topologies to optimize interoperability between the NSX platform and F5 BIG-IP physical and virtual appliances.
Download NSX F5 Design Guide v1.6
This document is targeted toward virtualization and network architects interested in deploying VMware® NSX network virtualization solution in a vSphere environment.
This is a updated edition of the VMware® NSX for vSphere Network Virtualization Design Guide
Authors:VMware NSX Technical Product Management Team
IT organizations have gained significant benefits as a direct result of server virtualization. Tangible advantages of server consolidation include reduced physical complexity, increased operational efficiency, and simplified dynamic repurposing of underlying resources. These technology solutions have delivered on their promise of helping IT to quickly and optimally meet the needs of increasingly dynamic business applications.
VMware’s Software Defined Data Center (SDDC) architecture moves beyond the server, extending virtualization technologies across the entire physical data center infrastructure. VMware NSX, the network virtualization platform, is a key product in the SDDC architecture. With VMware NSX, virtualization now delivers for networking what it has already delivered for compute. Traditional server virtualization programmatically creates, snapshots, deletes, and restores virtual machines (VMs); similarly, network virtualization with VMware NSX programmatically creates, snapshots, deletes, and restores software-based virtual networks. The result is a completely transformative approach to networking, enabling orders of magnitude better agility and economics while also vastly simplifying the operational model for the underlying physical network.
NSX is a completely non-disruptive solution which can be deployed on any IP network from any vendor – both existing traditional networking models and next generation fabric architectures. The physical network infrastructure already in place is all that is required to deploy a software-defined data center with NSX.
This document is targeted toward virtualization and network architects interested in deploying VMware® NSX Network virtualization solution in a vSphere environment.
Figure 1 draws an analogy between compute and network virtualization. With server virtualization, a software abstraction layer (i.e., server hypervisor) reproduces the familiar attributes of an x86 physical server (e.g., CPU, RAM, Disk, NIC) in software. This allows components to be programmatically 5 assembled in any arbitrary combination to produce a unique VM in a matter of seconds.
With network virtualization, the functional equivalent of a “network hypervisor” reproduces layer 2 to layer 7 networking services (e.g., switching, routing, firewalling, and load balancing) in software. These services can then be programmatically assembled in any arbitrary combination, producing unique, isolated virtual networks in a matter of seconds.
Where VMs are independent of the underlying x86 platform and allow IT to treatphysical hosts as a pool of compute capacity, virtual networks are independent of the underlying IP network hardware. IT can thus treat the physical network as a pool of transport capacity that can be consumed and repurposed on demand.
This abstraction is illustrated in Figure 2. Unlike legacy architectures, virtual networks can be provisioned, changed, stored, deleted, and restored programmatically without reconfiguring the underlying physical hardware or topology. By matching the capabilities and benefits derived from familiar server and storage virtualization solutions, this transformative approach to networking unleashes the full potential of the software-defined data center.
With VMware NSX, existing networks are immediately ready to deploy a next generation software defined data center. This paper will highlight the range of functionality provided by the VMware NSX for vSphere architecture, exploring design factors to consider to fully leverage and optimize existing network investments.
NSX Primary Use Cases
Customers are using NSX to drive business benefits as show in the figure below.
The main themes for NSX deployments are Security, IT automation and Application Continuity.
- NSX can be used to create a secure infrastructure, which can create a zero-trust security model. Every virtualized workload can be protected with a full stateful firewall engine at a very granular level. Security can be based on constructs such as MAC, IP, ports, vCenter objects and tags, active directory groups, etc. Intelligent dynamic security grouping can drive the security posture within the infrastructure.
- NSX can be used in conjunction with 3rd party security vendors such as Palo Alto Networks, Checkpoint, Fortinet, or McAffee to provide a complete DMZ like security solution within a cloud infrastructure.
- NSX has been deployed widely to secure virtual desktops to secure some of the most vulnerable workloads, which reside in the data center to prohibit desktop-to-desktop hacking.
- VMware NSX provides a full RESTful API to consume networking, security and services, which can be used to drive automation within the infrastructure. IT admins can reduce the tasks and cycles required to provision workloads within the datacenter using NSX.
- NSX is integrated out of the box with automation tools such as vRealize automation, which can provide customers with a one-click deployment option for an entire application, which includes the compute, storage, network, security and L4-L7 services.
- Developers can use NSX with the OpenStack platform. NSX provides a neutron plugin that can be used to deploy applications and topologies via OpenStack.
- NSX provides a way to easily extend networking and security up to eight vCenters either within or across data center In conjunction with vSphere 6.0 customers can easily vMotion a virtual machine across long distances and NSX will ensure that the network is consistent across the sites and ensure that the firewall rules are consistent. This essentially maintains the same view across sites.
- NSX Cross vCenter Networking can help build active – active data centers. Customers are using NSX today with VMware Site Recovery Manager to provide disaster recovery solutions. NSX can extend the network across data centers and even to the cloud to enable seamless networking and security.
The use cases outlined above are a key reason why customers are investing in NSX. NSX is uniquely positioned to solve these challenges as it can bring networking and security closest to the workload itself and carry the policies along with the workload.
Overview of NSX Network Virtualization Solution
An NSX deployment consists of a data plane, control plane, and management plane, as shown in Figure 4.
The NSX architecture has built in separation of data, control, and management layers. The NSX components that maps to each layer and each layer’s architectural properties are shown in above Figure 4. This separation allows the architecture to grow and scale without impacting workload.
In this version 3.0 edition the guide was updated to provide new additional context around:
1. Sizing for small and medium data centers with NSX
2. Routing best practices
3. Micro-segmentation and service composer design guidance
Thanks to all the contributors and reviewers to various sections of the document.
A final version of this Reference Guide will be posted soon on our NSX Technical Resources website (link below): http://www.vmware.com/products/nsx/resources.html