This document provides guidelines and best practices for deploying Cisco® Virtual Security Gateway (VSG) 1.4 or later and Cisco Virtual Network Management Center (VNMC) 2.0 with Cisco Nexus® 1000V Series Switches 1.5.2 or later.
This document discusses the architecture design components required to build a secure virtual computing environment; the interaction of components such as VMware vCenter, Cisco Nexus 1000V Series Virtual Supervisor Module (VSM), Cisco VSG, and Cisco VNMC; and deployment considerations and design best practices.
Cisco VSG is a virtual firewall for Cisco Nexus 1000V Series Switches that delivers security and compliance for virtual computing environments. Cisco VSG uses the virtual network service data path (vPath) technology embedded in the Cisco Nexus 1000V Series Virtual Ethernet Module (VEM), offering transparent insertion and efficient deployment. The Cisco VSG solution allows IT security, network, and server teams to collaborate while helping ensure administrative segregation to meet regulatory and audit requirements. This approach also reduces administrator errors. Cisco VSG also introduces Cisco VNMC, which manages Cisco VSG instances in a multitenant environment.
Cisco VSG provides controls at the virtual machine level, using virtual machine attributes, so that context-based policies can be applied. These policies are VLAN-independent and can be applied to zones of virtual machines, thereby providing topology-invariant, policy-based security controls. Traffic from external sources to the virtual machines and from virtual machine to virtual machine can be protected. The following sections describe some of the main benefits of deploying Cisco VSG in a virtualized environment.
Dynamic (Virtualization-Aware) Operation
Virtualization can be highly dynamic, with virtual machines frequently added, deleted, and changed. Live migration of virtual machines occurs through manual VMware vMotion or Distributed Resource Scheduler (DRS) events.
Cisco VSG, operating in conjunction with the Cisco Nexus 1000V Series (and vPath), supports dynamic virtualization. Trust zones and associated security profiles for each line of business or tenant are created with Cisco VSG and Cisco VNMC. Security profiles are bound to Cisco Nexus 1000V Series port profiles (authored on the Cisco Nexus 1000V VSM and published to VMware vCenter). When a new virtual machine is instantiated, the server administrator assigns the appropriate port profile to the virtual machine's virtual Ethernet port. The port and security profiles and the virtual machine's zone membership are immediately applied. A virtual machine can be repurposed simply by assigning different port and security profiles.
Nondisruptive Operating Model
With the introduction of the Cisco Nexus 1000V Series, Cisco VSG provides transparent integration with VMware vCenter. The operating model is still intact, in which the system security administrators define the security rules and policies, the network administrators manage those policies and associate them with a particular port profile, and the server administrators select the appropriate port group (the Cisco Nexus 1000V Series equivalent of a port profile) for the particular virtual machine. Figure 1 depicts this operating model.
Figure 1. Administrative Segregation of Server, Network, and Security Administrators
The tight integration with VMware vCenter allows transparent and dynamic provisioning of port profiles and security policies to the virtual machines.
Cisco VNMC is designed to manage Cisco VSG and security policies in a dense, multitenant environment, so that administrators can rapidly add and delete tenants and update tenant-specific configurations and security policies. Figure 2 depicts the multitenant deployment of Cisco VSG. In the architecture shown in the figure, Tenant A has its own Cisco VSG that provides security policies for its virtual machines. Tenant B has its own, separate Cisco VSG to manage its security policies for its virtual machines.
Figure 2. Multitenant Deployment with Cisco VSG Solution
Independent capacity planning: Cisco VSG can be placed on a dedicated server controlled by the security operations team so that appropriate computing capacity can be allocated to application workloads, capacity planning can occur independently across server and security teams, and operational segregation can be maintained across security, network, and server teams.
vPath Intelligence: Cisco VSG leverage Nexus 1000V vPath intelligence for traffic redirection, fast path offload with all policy enforcement of flows offloaded to vPath, and insertion of Cisco VSG along with other virtual network services in the traffic path. vPath is designed for multi-tenancy, providing traffic steering and fast path offload on a per-tenant basis.
Figure 3 shows the overall architecture of the Cisco VSG solution and the integration of the required components in the solution. This section discusses the communication across these components.
Figure 3. Cisco VSG Solution Architecture
The following components are required to set up the Cisco VSG environment:
• Cisco Virtual Network Management Center: Cisco VNMC is a virtual appliance that provides centralized device and security policy management for Cisco VSG.
• Cisco Virtual Security Gateway: Cisco VSG operates with the Cisco Nexus 1000V Series distributed virtual switches in the VMware vSphere hypervisor, and it uses the vPath technology embedded in the Cisco Nexus 1000V VEM.
• Cisco Nexus 1000V Series Switches: Cisco Nexus 1000V Series Switches are virtual machine access switches that are an intelligent software switch implementation for VMware vSphere environments running Cisco NX-OS Software. To support the Cisco VSG solution, the Cisco Nexus 1000V Series must be running Cisco NX-OS Release 1.4 or later.
• VMware vCenter: The VMware vCenter server manages the VMware vSphere environment and provides unified management of all the hosts and virtual machines in the data center from a single console.
Communication Between Cisco VNMC and VMware vCenter
Cisco VNMC registers with VMware vCenter for visibility into the VMware environment. This registration allows the security administrator to define policies based on the VMware virtual machine attributes. Cisco VNMC integrates through an XML plug-in. The integration process is similar to that of the Cisco Nexus 1000V VSM with VMware vCenter. Cisco VNMC and VMware vCenter communicate over an SSL connection on port 443 (Figure 4). There is no specific network limitation for communications between Cisco VNMC and VMware vCenter, other than that the appropriate ports must be open if there is a firewall between them.
Figure 4. Communication Between Cisco VNMC and VMware vCenter
Communication Between Cisco VNMC and Cisco VSG
Cisco VSG registers with Cisco VNMC through the policy agent configuration performed on Cisco VSG. After registration, Cisco VNMC pushes the security and device polices to Cisco VSG. No policy configuration is performed using the Cisco VSG command-line interface (CLI) after Cisco VSG is registered with Cisco VNMC. The CLI is available to the administrator for monitoring and troubleshooting purposes. Communication between Cisco VSG and Cisco VNMC takes place over an SSL connection on port 443 (Figure 5).
Figure 5. Communication Between Cisco VNMC and Cisco VSG
Communication Between Cisco VNMC and the VSM
The VSM registers with Cisco VNMC through the policy agent configuration performed on the VSM. The steps for registration are similar to those for registering Cisco VSG with Cisco VNMC. After registration, the VSM can send IP-to-virtual machine bindings to Cisco VNMC. IP-to-virtual machine mappings are required by Cisco VSG to evaluate policies that are based on virtual machine attributes. The VSM also resolves the security-profile ID using Cisco VNMC. This security-profile ID is sent in every vPath packet (discussed in the next section) to Cisco VSG and is used to identify the policy for evaluation. Communication between the VSM and Cisco VNMC is supported over an SSL connection on port 443 (Figure 6).
Figure 6. Communication Between Cisco VNMC and the VSM
Communication Between Cisco VSG and the VEM (vPath)
Cisco VSG receives traffic from the VEM when protection is enabled on a port profile. The redirection of the traffic occurs using vPath. vPath encapsulates the original packet and sends it to Cisco VSG. Cisco VSG has a dedicated interface (Data 0) with an IP address for vPath communication.
Cisco VSG can be Layer 2 or Layer 3 adjacent to the VEM:
Cisco VSG-L2 adjacent: When configured in Layer 2 mode, VEM obtains Cisco VSG's MAC address through the Address Resolution Protocol (ARP) for that IP address. If Cisco VSG and the VEM are Layer 2 adjacent, communication will be through the Data 0 interface VLAN of Cisco VSG. The following VSM configuration example shows the addition of service node Cisco VSG as Layer 2 adjacent to the VEM. Layer 2 adjacency is recommended having minimal latency in data path.
vservice node vsg type vsg
ip address 192.168.1.99
adjacency l2 vlan 10
Cisco VSG-L3 adjacent: Layer 3 adjacency is applicable when Cisco VSG is not in the same Layer 2 domain and is multiple hops away from the VEM. In this configuration, Layer 3 communication will be through the Cisco VSG Data 0 interface, and a VMkernel interface on the VEM. Each protected VEM needs to have VMkernel communicate with VSG Data Interface. The VMkernel interface can be same as the one used for VSM and VEM (Layer 3 control) communication. The VEM needs IP reachability only to the tenant-specific Cisco VSG to redirect traffic from vPath to Cisco VSG for policy evaluation. VSM configuration example below shows how Cisco VSG Layer 3 adjacency is configured on VSM.
For Layer 3 adjacency, a new port profile is defined on the VSM with capability l3-vn-service, and this port profile will be associated with a VMkernel interface on the VEM.
vservice node VSGL3 type vsg
ip address 10.10.10.10
port-profile type vethernet VSG-Data-interface
switchport mode access
switchport access vlan 1001
An alternate approach is to use the same VMkernel interface on protected host, that's used for VSM and VEM control traffic, for communication between Cisco VSG and VEM. This is achieved by adding capability l3-vn-service to the same port profile as the one used for VSM and VEM (Layer 3 control) communication.
Configuration example below:
port-profile type vethernet n1kv-l3
switchport mode access
switchport access vlan 171
system vlan 171
Cisco VSG evaluates policies on the first packet of each flow that is redirected by vPath. Cisco VSG then transmits the policy evaluation results to vPath. vPath maintains the result in the flow table, and subsequent packets of the flow are permitted or denied based on the result cached in the flow table (Figure 7).
Figure 7. Communication Between Cisco VSG and the VEM
vPath maintains the state of the TCP flows. In the event of a reset (RST) event or a finish (FIN) flag in the TCP flow, vPath purges the entry of that flow from the table. Inactivity in any flow will also cause the entry to be cleared from the flow table.
Cisco VSG supports stateful protocols, such as FTP, Trivial File Transfer Protocol (TFTP), and Remote Shell (RSH) Protocol.
Communication Between the VSM and the VEM
There are two ways of connecting the VSM and the VEM (Figure 8):
• Over Layer 2: If the VSM and VEM are in the same Layer 2 domain, They can connect using L2 mode. However Layer 3 mode for VSM-VEM is recommended best practice.
• Over Layer 3: If the VSM and VEM are in different Layer 2 domains, the Layer 3 connectivity mode should be used. The Layer 3 mode will encapsulate the packet of the Layer 2 mode using Generic Routing Encapsulation (GRE). All communication between the VSM and the VEM are encrypted using a 128-bit algorithm. Cisco VSG implementation is independent of VSM-to-VEM communication (whether in Layer 2 or Layer 3 mode).
Figure 8. Communication Between the VSM and the VEM
Virtual Extensible LAN
Cisco Nexus 1000V Series supports Virtual Extensible LAN (VXLAN) technology with a 24-bit LAN segment identifier to provide segmentation at cloud scale. Cisco vPath secures virtual machines configured as part of VXLAN. Because the VXLAN header is decapsulated on a VEM, vPath does not need the VXLAN reachability information to make decisions about either rerouting packets to Cisco VSG or permitting or denying traffic based on the configured security policy. Cisco VSG Data interface can be on a VLAN or a VXLAN segment.
Cisco VSG Deployment Considerations
This section discusses various aspects of Cisco VSG deployment in your network.
Cisco Nexus 1000V Series Infrastructure
Before installing Cisco VSG, you are required to install Cisco Nexus 1000V Series Software Release 4.2(1) SV1(5.2) in your environment. Cisco VSG 1.4 is supported from Cisco Nexus 1000V Release 4.2(1) SV1(4) and performs the basic configuration of the Cisco Nexus 1000V Series Switch. This will configuration includes:
• Installing and configuring the VSM
• Providing access to shared storage
• Creating the necessary port profiles, including
– Uplink port profiles
– VMkernel port profiles
– Virtual machine data port profiles
• Registering the VSM with VMware vCenter
• Installing two or more VEMs
• Adding the VEMs to the VSM
This deployment guide does not discuss the details of installing and deploying the Cisco Nexus 1000V Series. Please refer to the Cisco Nexus 1000V Installation Guide or a Deployment Guide for this information.
Cisco VSG uses three network interfaces in the following order:
1. Cisco VSG data interface
2. Cisco VSG management interface
3. Cisco VSG high-availability interface
Note: During VSG OVA install, installer prompts for configuring VSG management interface, subnet mask, default gateway, VNMC IP address and VNMC Shared Secret for secure connectivity with VNMC. VSG Data Interface is not be configured during initial installation. This is only done via VNMC when assign VSG to a Compute Firewall, and is covered later in this document.
Create additional VLANs for the Cisco VSG data and high-availability interfaces on the VSM and allow the VLANs to forward on the system uplinks. Create these VLANs on the upstream switch. You can have the same VLAN for both the high-availability and data interfaces, depending on the utilization of the data interface.
The existing management VLAN in your setup can be used to manage Cisco VSG.
The recommend approach is to use VMware Open Virtual Appliance (OVA) for the Cisco VSG installation, which allows simplified installation. Since Cisco VNMC is the central management center for Cisco VSG, it will be located in your management VLAN. There are no specific network requirements for setting up Cisco VNMC. Please refer to the quick start guide at for the steps for deploying Cisco VNMC.
Cisco VSG (OVA or ISO) contains respective VNMC policy-agent image, which is copied to bootflash on installation of VSG. In certain scenarios VSG works with multiple versions of VNMC, and if need to use non-default VNMC Policy-Agent image, you would need to manually copy the VNMC Policy Agent image to boot flash, which is available with VNMC download.
Installation and Initial Setup
Please refer to Part 1 of the Cisco VSG and Cisco VNMC Installation Guide [[PLS PROVIDE URL]] to do the following (Figure 9):
1. Install Cisco VNMC as a virtual appliance.
2. Install Cisco VSG as a virtual appliance.
3. Register Cisco VSG with Cisco VNMC
4. Register the VSM with Cisco VNMC.
5. Register Cisco VNMC with VMware vCenter
Note: Step 3 is achieved by installing VNMC-VSG policy agent image on VSG. Cisco VSG is bundled with respective VNMC Policy Image; It is by default copied to VSG bootflash. If you're deploying VSG in mixed mode deployment where VNMC version is different, then you need to copy new VNMC policy agent image bundled in downloaded VNMC zip file.
Here's an example of installing vsg-policy-agent on Cisco VSG:
VNM Policy-Agent status is - Installed Successfully. Version 2.0(1a)-vsg
Figure 9. Initial Setup of Cisco VSG and Cisco VNMC
After completing these tasks, you should be ready to start defining and implementing the policies for Cisco VSG. Figure 10 shows a typical network with all the necessary components in place for the Cisco VSG solution.
Figure 10. Network Topology with Cisco Nexus 1000V Series, Cisco VSG, and Cisco VNMC
Enabling the Firewall
To insert the firewall into the network, you need to attach Firewall security profile to the port profile. All the traffic traversing the virtual ports associated with that port profile is subjected to policy evaluation.
The following commands define the Cisco VSG firewall feature on the VSM:
Nexus1000V (config)# vservice node VSG_Node-Name type vsg
Nexus1000V(config-vservice-node)# ip address VSG_DATA_IP
The first command defines virtual service instance of node type Cisco VSG. The second and third commands provide information for vPath communication with Cisco VSG, including the mode of adjacency, Cisco VSG data interface IP address, and Cisco VSG service VLAN.
The following commands turn on the firewall feature under the port profile on the VSM:
The first command specifies the tenant in which the firewall is enabled. The second command binds a specific Cisco VSG and security profile to the port profile. It enables vPath to redirect the traffic to the Cisco VSG in the service VLAN.
The following example shows the port-profile configuration with Cisco VSG firewall protection enabled:
port-profile type vethernet Secure-ATenant-VM
switchport access vlan 10
switchport mode access
vservice node vsg profile Secure-ATenant
Starting with Cisco Nexus 2.1 Release, Cisco VSG and VNMC license is bundled with Cisco Nexus 1000V Advanced Edition licenses.
A Cisco Nexus 1000V advanced edition license is required for each CPU socket, and VSG licensing follows the same model as licensing for the Cisco Nexus 1000V Series. Each CPU requires one license, and there is no limit on the number of cores per CPU. The main point to note is that the licenses need to be installed on the VSM. Because the licenses are based on physical host sockets, you can instantiate Cisco VSGs in a scale-out model without worrying about licenses.
You must purchase enough licensing capacity to cover all installed CPUs. Licenses are not applied to a VEM unless the existing license has the capacity to cover all its CPUs. Please refer to the licensing guide at for the steps you need to take to install the licenses.
The Cisco Nexus 1000V Series Release 2.1 software comes with a 60-day evaluation license of Advanced Edition.
Cisco VSG is a transparent firewall inserted at Layer 2 and acts like a "bump in the wire"; it is not seen as a Layer 3 hop to connected devices. Insertion of a Cisco VSG into the network does not require any reengineering of the existing network.
Cisco VNMC supports overlapping network spaces for a multitenant environment. Therefore, if network segmentation exists that allows overlapping IP spaces (for example, virtual route forwarding lite (VRF-lite), Cisco VNMC will allow you to build policies for each tenant with overlapping networks.
Service VLAN Maximum Transmission Unit Size
Starting from Cisco VSG 1.3, Cisco VSG can be either Layer 2 or Layer 3 adjacent to the VEM. vPath intercepts the first packet of the flow and encapsulates the original packet with an additional vPath header. When the connectivity between Cisco VSG and the VEM is Layer 2, the frame size is increased by 74 bytes. With Layer 3 connectivity between Cisco VSG and the VEM, the increase in payload size is 94 bytes.
For Layer 2 mode, vPath performs fragmentation if the encapsulated packet exceeds the outgoing interface maximum transmission unit (MTU) value. Typically, this overhead does not affect TCP flows. These flows will not be subject to fragmentation because the first packet of any TCP flow is a SYN packet, which is not subject to fragmentation after vPath encapsulation. You may see fragmentation with User Datagram Protocol (UDP) flows in which the packet is already 1500 bytes when vPath intercepts it. To avoid fragmentation, you can increase the MTU value by 74 bytes on the uplink port profile configured in Cisco Nexus 1000V Series Switches and on the upstream physical switch to which other physical hosts are connected.
With Layer 3 connectivity between Cisco VSG and the VEM, the payload increase is 94 bytes. In Layer 3 mode, vPath does not support fragmentation, so if the new packet size after the addition of 94 bytes exceeds the outgoing interface MTU value, the packet will be dropped and an Internet Control Message Protocol (ICMP) error message (error code = 4) will be sent back to source.
Note: In Cisco VSG Layer 3 mode, IP fragmentation is not supported on the VEM virtual machine network interface card (vmnic) for traffic leaving the VMware ESX or ESXi host. Hence, after vPath encapsulation, if an IP packet is received by a VEM from a virtual machine with a packet size greater than the outgoing interface MTU value, it will be dropped, and an ICMP error message (error code = 4) will be sent back to the source virtual machine. To avoid packet drops in this scenario, increase the outgoing server port MTU value by 94 bytes. For example, if the MTU values of client and server virtual machines and uplinks are all 1500 bytes, set the uplink MTU value to 1594 bytes.
Table 1 summarizes the high-availability behavior for various components of the solution. Like the VSM, Cisco VSG comes with high availability. It is not recommended that you use the VMware High Availability (HA) feature or the fault-tolerance or VMware DRS feature for Cisco VSG and the VSM. If neither the primary nor the standby Cisco VSG is available to vPath, you can configure the failure mode as Fail Open or Fail Close. You can make this configuration when you enable the security profile with the vn-service command in the port profile.
Table 1. High-Availability Behavior for Cisco VSG Solution Components
Standby Cisco VSG takes over in 6 to 8 seconds
Hardware failure backup
Standby VSM takes over in 6 to 8 seconds
Note: A Cisco VSG pair shares a high-availability ID that should be unique to the pair, if you have more than one Cisco VSG high-availability pair sharing the same management or high-availability VLAN.
One or more instances of Cisco VSG are deployed on a per-tenant basis, which allows a highly scalable deployment across many tenants. Tenants are isolated from each other, so that no traffic can cross tenant boundaries. A tenant can be further divided to the following levels:
• Virtual data center
• Virtual application
• Virtual tier
Each instance in a tenant tree is classified as an organization (org) level. Depending on the use case, you can deploy a Cisco VSG at the tenant level, at the virtual data center (vDC) level, or at the virtual application (vApp) level. Figure 11 shows how a tenant tree structure can be built in Cisco VNMC.
Figure 11. Cisco VNMC Tenant Management View
Security Policy Management
The security policy in Cisco VNMC uses network attributes, VMware virtual machine attributes, and virtual machine custom attributes. You can define multiple policies for a tenant. All the policies are published to the Cisco VSG through a security profile. These policies can be applied at any organization level within a tenant.
A general guideline is to apply more generic policies at a higher level in the tenant hierarchy, and to apply more specific policies closer to the organization level within a tenant, where they are more meaningful.
In Figure 12, Cisco VSG is placed at the tenant level (Tenant A), but the policies are applied at two different levels within the tenant. Policy P1 is applied at the data center level, which means that the entire data center DC 2, and all the sublevels within DC 2, are subjected to P1 policy evaluation. Policy P2 is specific to App 2 only and is placed at that organization level.
The general guideline is to place more generic policies higher in the organization structure, and to place more specific policies closer to the organization level, where they are more meaningful.
Figure 12. Cisco VSG and Policy Placement in Tenant Hierarchy
Device Policy Management
The general settings for Cisco VSG are also specified through Cisco VNMC. The settings include Simple Network Management Protocol (SNMP), syslog, Network Time Protocol (NTP), and fault logging. All these settings are part of the device policy that is published to Cisco VSG along with the security policy. When assigning a registered firewall to a tenant Cisco VSG, if you do not define a device policy, a default policy is pushed to Cisco VSG for these settings.
With Cisco Nexus 1.5.2 Release, vPath 2.0 supports enabling multiple services for a network port with its unique intelligent service chaining architecture. Cisco VSG for Compute Firewall, and Cisco ASA 1000V for Edge Security Firewall, can both be enabled for a particular VM Port group. White Paper on vPath Service Chaining has more details.
Cisco VSG is designed to be scalable. As virtualized environments grow to accommodate business needs, you can instantiate more Cisco VSGs and apply the same policies to protect a larger environment. Table 2 can help you understand how you can scale from both the Cisco VSG and Cisco VNMC perspectives.
Table 2. Scaling Cisco VSG and Cisco VNMC
Cisco VSG 1vCPU
Cisco VSG 2vCPU
Number of Cisco VSG instances
New Connections Per Second
Max Number of VSMs
Number of Hosts
Currently, if you need to deploy an additional Cisco VSG, you use a manual process in which you bind one port profile to one Cisco VSG and another port profile to another Cisco VSG. In future versions, Cisco VSG will offer a clustering feature that will allow you to perform load balancing with two or more Cisco VSGs dynamically.
Cisco VSG Deployment Scenarios and Configuration Tasks
This Tables describes the flow and how segregation of duties and ownership is maintained for provisioning Security Firewall.
Cisco VNMC GUI: Define Security Profile, Add Rules, Assign and publish policies to Cisco VSG
VSM Interface: Define Service node, and bind Security Profile to Port-Profile (available as Port-Group in vCenter)
vCenter Interface: Attach Virtual Machines to Firewall enabled port-group to instantly enable security for the VM's
Figure 13 depicts the physical topology and network configuration that is used in this document in the sample Cisco VSG deployment.
Figure 13. Sample Cisco VSG Deployment Topology
Note: Standard practice for the Cisco Nexus 1000V VSM still applies, with a separate VLAN used for management, and dedicated VLAN used for VSM-VEM control traffic. The example here uses this scheme. However, this configuration is not a requirement, and users can choose to have all three traffic types in the same VLAN or to have a separate VLAN for each.
Three-Tier Access Control with Virtual Machine Base Policies
Cisco VSG provides the standard 5-tuple network attributes that can be used in the security policies. Table 3 shows the supported attributes.
Table 3. Cisco VSG Supported Network Attributes
Source IP address
Destination IP address
Protocols specified in IP header (TCP, UDP, etc.)
Here is a sample security policy for Tenant content hosting, which will be applied to this use case:
• Permit only port 80 (HTTP) for virtual machines in the web zone.
• Permit port 22 (Secure Shell [SSH]) for virtual machines that belong to the database zone.
• Allow communication only between web servers and database servers.
• Allow communication only between application servers and database servers.
• Explicitly deny all traffic to all zones.
Tasks for Security Administrators
The security administrator must perform the following high-level steps on the Cisco VNMC to create a policy using conditions based on VM or Network attributes.
Let's walk through the flow of provisioning VSG security policies via VNMC Web Interface.
Access VNMC from your browser session using URL <Error! Hyperlink reference not valid.>
In the next few pages, following tasks are illustrated for provisioning Compute Firewall (VSG) policies through VNMC:
Define Tenants, Add Zones, Define Security-Profile, Create Rules, Assign VSG to a Tenant (configure VSG Data Interface), and Verify Security Profile is published to VSG.
Log into Cisco VNMC and select the Tenant Management tab. Right-click the root node and create a tenant (Figure 14).
Figure 14. Create a Tenant
Add Zones for Tenants
A zone is a logical group of virtual machines or hosts. Zones simplify policy writing by allowing users to write policies based on zone attributes using zone names. After you have created the tenant, you can go to the Policy Management tab to define logical Zones (vZones).
Navigate to Policy Management > Service Profiles > Tenant > Policy Helpers >vZones (Figure 15).
Add three zones:
Figure 15. Adding vZone
After defining the vZones; WebZone as an example, select the Edit tab to classify the zone, as shown in Figure 16. This example will use VM attributes to classify the zones.
Figure 16. Adding a Condition for vZone Classification
Similarly, define conditions for the other two zones based on VM or Network attributes. All three zones are now displayed in the Summary tab, as shown in Figure 17.
Figure 17. Three vZones Defined for the Policy
Define the Security Profile
You configure security profiles in the Cisco VNMC Policy Management interface. The predefined zones can be used to define the security policy for each tenant. The security profile contains set of policy rules defined for the tenant compute firewall.
Navigate to Policy Management > Service Profiles > Tenant > Compute Firewall > Compute Security Profiles. Select Add to add a new security profile (Figure 18).
Figure 18. Adding a Security Profile for a Tenant
Define a Policy Set and Create Rules in the Policy
Define a policy set in the security profile and add rules to the policy set. Policy specifications outlined in the use case will be implemented by adding rules to this policy.
In this example:
• Allow only HTTP traffic destined to virtual machines in the web zone.
• Allow all ICMP traffic to virtual machines.
• Allow only traffic originating from the web server in the database zone.
• Allow only communication between the web and database servers.
• Deny all other traffic.
Define a new policy set in the security profile, as shown in Figure 19.
Figure 19. Adding Policy Set to the Security Profile
Then click Add Rule to add rules to this policy set, as shown in Figure 20.
Figure 20. Adding Rules to the Policy Set
Assign Cisco VSG to a Tenant
All the registered Cisco VSGs appear in the Resource Management interface. (This step requires that VNMC policy agent image is successfully installed on Cisco VSG, details in VSG installation tasks)
To push configured security profile to a Cisco VSG instance, you need to assign Cisco VSG to a tenant. After this assignment, all the policies (security profiles) are published to that Cisco VSG. The recommended approach is to add the computing firewall object directly at the tenant level.
Follow these steps:
1. In the navigation pane, click the VNMC>Resource Management tab > Managed Resources tab.
2. Expand the root node.
3. Select Compute Firewalls for the Tenant in which you have defined Security Profile and want to add a computing firewall service instance.
4. In the work pane, click the Add Compute Firewall link.
In the Add Compute Firewall dialog box, do the following:
On the General tab, add a user-defined name and description.
In the Firewall Settings area, enter the VSG Data IP address, as shown in Figure 21. This interface IP address/Vlan will be used to define VSG as a service node in VSM, and for vPath-VSG communication.
Then you Assign that computing firewall object to an available Cisco VSG, as shown in Figure 22.
Figure 21. Adding a Compute Firewall at the Tenant Level
Figure 22. Selecting a Cisco VSG from the Drop-Down Menu
After you have assigned the computing firewall object to the Cisco VSG, the Cisco VSG configuration status should be "applied " and association status should be "associated" as shown in Figure 23.
Figure 23. Cisco VSG Assignment Status
Verify the Security Policy Configuration Using the CLI
Log in to the Cisco VSG CLI and enter command "show run policy" to verify security policy is being pushed successfully by the Cisco VNMC (Figure 24). This step is optional and only for verification purpose.
Figure 24. Verifying the Security Policy Using the Cisco VSG CLI
Tasks for Network Administrators
The configured security policy is made available to the network administrator through the security profile. This feature makes the network administrator's configuration task much easier because the administrator does not have to deal with security-policy-related details.
The network administrator now creates a port profile and can also bind the security policy to this port profile. The definition for the security policy does not require a separate port profile, so a single port profile can be used for all the virtual machines. The sample configuration in Figure 25 shows how this configuration is accomplished.
Figure 25. Binding a Security Profile to the Port Profile
Tasks for Server Administrators
The server administrator only needs to go to the network settings of the virtual machine and select the port profile that the network administrator created with the security profile (Figure 26).The network profile and security profiles created will be instantiated dynamically when the virtual machine is associated with this network port profile.
Figure 26. Selecting a Firewall-Enabled Port Group
Three-Tier Access Control with Custom Attribute Base Policies
This example discuss how to use custom attributes for the same three-tier server zone use case, follow the steps in this section in addition to the steps in the previous sections using virtual machine. The goal of this use case is to help you gain a better understanding of how you can use custom attributes to build a security policy, based on VMware virtual machine attributes and network attributes.
2. Right-click and choose Add Security Profile Dictionary (Figures 27 through 29).
Figure 27. Adding a Security Profile Dictionary
Figure 28. Naming the Security Profile Dictionary
Figure 29. Adding a Custom Attribute to the Dictionary
Define Zones Based on Custom Attributes
Add three zones - WebZone, AppZone, and DBZone - as in the previous two examples. The only difference is that here you will use a custom attribute that was added to the security profile dictionary, "Server-Type" (Figure 30).
Figure 30. Adding a Zone Condition Based on a Custom Attribute
Follow the same process for AppZone and DBZone.
Build the Security Policy
The policy rules are exactly the same as in previous two examples, in which zones were added based on network and virtual machine attributes.
Create Security Profiles
The process of creating security profiles using custom attributes involves an additional step. You need to create three security profiles, such as the following:
For each profile, perform the following steps:
1. Select the policy set from the drop-down menu (Figure 31).
Figure 31. Adding a Custom Attribute to the Security Profile
2. Give a value to the custom attribute on the Attributes tab (Figure 32).
Figure 32. Assigning a Value to the Custom Attribute
The new profiles will appear in the list of security profiles (Figure 33).
Figure 33. List of Newly Created Security Profiles
You have created three security profiles with different custom attribute values but the same policy set. The policy evaluation will be different depending on which security profile is enabled for the traffic flow.
Tasks for Network Administrators
Create three port profiles in the Cisco Nexus 1000V Series Switch:
All these port profiles belong to the same tenant and share the same VLAN, but they have different security profiles (Figure 34).
Figure 34. Enabling Three Different Security Profiles on Three Port Profiles
Tasks for Server Administrators
The server administrator can select from three port groups depending on whether the virtual machine belongs to the Web, App, or DB port group (Figure 35).
Figure 35. Selecting the Port Group Based on Server Type
Configuring a Syslog Server
Device settings for Cisco VSG are also configured through Cisco VNMC. You can use these settings to configure NTP, syslog, and SNMP options. Please refer to the information about how to configure device policies in the Cisco VNMC GUI Configuration Guide for the options available on the Device Policies tab.
After you have defined a device policy, you assign this policy on the Resource Management tab. The following example shows how to add a device policy to set up a syslog server for logging Cisco VSG.
2. On the right side pane, in Firewall Settings, select the device profile that you created for syslog (Figure 40). Then save the configuration.
Figure 40. Assigning the Device Profile to Cisco VSG
Cisco VSG integrates with Cisco Nexus 1000V Series Switches to enforce security policies for your virtualized environment. Cisco VNMC provides policy management for a multitenant environment. One or more Cisco VSG instances are required per tenant. Cisco VSG uses the vPath intelligence in the Cisco Nexus 1000V VEM to provide security policy enforcement.