Blog

End to end virtual network security with the Cisco Nexus VSG

By Harley Stagner | Apr 11, 2011 | Insights, Virtualization

So I’ve been spending a lot of time in our lab with the Cisco Nexus Virtual Security Gateway. I have come to the conclusion that it rocks! Finally, the virtual infrastructure is no longer treated as a second class citizen when it comes to securing network traffic between virtual machines. We are at a point now with the Cisco VSG that we can have robust Cisco infrastructure, including security, from the upstream physical network to the virtual network.

The Cisco Nexus VSG builds upon the Nexus 1000v distributed virtual switch and communicates with the Virtual Ethernet Modules in the Nexus 1000v to provide a very robust security policy engine that can perform granular filtering and matching on a number of parameters. For example:

  • Network (ip address, port number, etc.)
  • VM (VM Name, Installed OS Name, Cluster, Host, Zone)

Yep, that’s right, I said VM. Since the Cisco VSG integrates with the vSphere API’s and vCenter, you can filter on items like a virtual machine name or partial name, installed OS, cluster, etc. This is very powerful. I no longer have to rely on network and IP rules alone to filter traffic between virtual machines. This is a more intelligent approach to filtering that really highlights the synergies that Cisco and VMware have established. Best of all, once it is set up everything is managed from a single Cisco Virtual Network Management Center (VNMC) instance. This web-based management tool let’s you manage multiple Virtual Security Gateway instances. Let’s look at a simple example of how easy it is to perform traffic filtering in the virtual infrastructure with the Cisco VSG.

Topology and Components:

  • vSphere 4.1 Enterprise Plus Host Servers
  • Cisco VNMC VM
  • Cisco Nexus 1000v Infrastructure
  • Cisco VSG Infrastructure
  • tenanta-srv1 VM
  • tenanta-srv2 VM
  • tenantb-srv1 VM
  • tenantb-srv2 VM

The goal of this configuration is to allow the following communication flows:

  • tenanta-srv1 and tenanta-srv2 should communicate
  • tenantb-srv1 and tenantb-srv2 should communicate
  • The Tenant A servers(tenanta-srv1 and tenanta-srv2) should not be able to communicate with the Tenant B servers (tenantb-srv1 and tenantb-srv2)
  • Anyone else should be able to communicate with both the Tenant A and Tenant B servers
  • There is a further caveat that the Tenant A and Tenant B servers are both on the same subnet (don’t worry these servers belong to the same company Winking smile )

Below are the network settings:

  • tenanta-srv1 VM – 10.91.41.200
  • tenanta-srv2 VM – 10.91.41.201
  • tenantb-srv1 VM – 10.91.41.202
  • tenantb-srv2 VM – 10.91.41.203
  • a client with another ip address

Here are the general steps for setting up this scenario once the Cisco VSG infrastructure is in place:

  • Create a tenant
  • Assign the VSG to the tenant
  • Create a zone each for the Tenant A and Tenant B servers (these zones match VM’s with names that contain “tenanta” and “tenantb” respectively)
  • Create a firewall policy for the VSG
  • Create a policy set that includes the policy
  • Bind the policy set to the VSG
  • Bind the tenant to a port-profile so that any VM that is on that port-profile is filtered with the policy rules

Below are the screenshots of the results after the VSG was configured.

These are the only rules that are required for the communication flows.

image

 

Here is what the port-profile looks like on the Nexus 1000v. Notice the org and vn-service entries. This means that this port profile is VSG aware.

image

 

The ICMP traffic from the Tenant A Servers.

image

image

ScreenClip

ScreenClip(1)

ScreenClip(2)

ScreenClip(3)

 

The ICMP traffic from the Tenant B Servers (same result as the Tenant A servers. Only one is shown here.)

ScreenClip(4)

ScreenClip(5)

ScreenClip(6)

 

Finally the results from the external client

ScreenClip(7)

ScreenClip(8)

ScreenClip(9)

ScreenClip(10)

 

As you can see, we achieved our goal with just three filtering rules. Also, we were able to leverage VM name filtering instead of IP filtering which allowed us to filter on the same subnet without resorting to naming each IP address or different port numbers. Very cool! The Cisco VSG is capable of many complex configurations combining both networking categories (ip, port number, etc.) and VM categories. This was just a quick example of what can be done. As always, if you have any questions or would like to see a live demo feel free to contact me.

Leave a Reply

Your email address will not be published. Required fields are marked *