& cplSiteName &

Virtual Security Gateway

Light Reading
Series Column
Light Reading

EXECUTIVE SUMMARY: Cisco’s Virtual Security Gateway (VSG) successfully applies policies between virtual machines, and continues to do so as VMs are migrated from hardware to hardware.

Earlier in the Tenant Isolation test (link Tenant Isolation test) we discussed the undeniable need for a comprehensive solution to the security concerns associated with cloud services. The isolation of tenants answers the question of security between private customers, but what about public or shared cloud services? Typically data centers use firewalls to block all traffic except for the specific types of traffic that are allowed, for the specific servers that need them. And if those servers are virtual? Well, then you need a virtual firewall of course.

Cisco’s Virtual Security Gateway (VSG) integrates with the Nexus 1000v via a module called vPath, which is embedded into the distributed virtual switch. As Cisco explains it, most of the intelligence of the policies are offloaded to the VSG component, which tells the vPath component how to treat traffic, thus reducing the complexity of the forwarding decision. Our interest was a) to verify that standard realistic policies would work in a realistic environment, and b) to verify that the appropriate policies remain associated with the appropriate VMs even when those VMs are moved around.

We set out to emulate a typical three-tier Web server scenario. For those less familiar, websites are delivered by splitting the main functions into three parts: the "presentation" or "Web" tier that users access directly; the "application" or "logic" tier, which runs the intelligence for the service that website is delivering; and "database" tier to store information. We started by creating three Ixia IxLoad VMs, each one emulating one of the three Web server tiers. Using Ixia hardware to emulate the outside users, we verified these policies with the appropriate traffic:

  • Users could exchange HTTP traffic with the presentation tier VM, but other types of traffic would not work. We used FTP to verify that other traffic types were discarded.
  • Users only had FTP access to the application tier. HTTP access was expected to fail.
  • Users had no access to the database tier -- verified with both HTTP and FTP traffic.

All traffic was passed or blocked as expected. We set up an additional three IxLoad VMs to verify that the policies among VMs would work in parallel to policies to the outside. Between the servers:
  • The presentation tier VM could exchange HTTP traffic with the application tier, but not with the database tier
  • The application tier could exchange both FTP and SQL traffic with the database tier. Ixia helped us to write a script to run the SQL traffic in parallel to the IxLoad generated traffic.

Again, all traffic was blocked and forwarded appropriately, and the behavior we had observed with outside customers remained the same, also in parallel. In fact, this entire setup was duplicated -- one setup running within a Silver tenant, and one within a Gold tenant. With all these traffic flows running to all twelve emulated servers in parallel, we were pretty convinced. In fact Cisco also showed us that there were different ways to configure the policies down to the VM -- one exemplified by the Silver tenant setup, and one by the Gold tenant setup. The Silver tenant used VM attributes (in fact the name of the VM) to match the policy to the VMs, while Gold tenants used IP-based mapping. Yet, one feature remained to be verified -- what happens when a VM is migrated? That is, what is when a VM is moved by an administrator to different hardware?

Cisco promised that the behavior would remain the same as VMs were migrated. We tested this out by leaving the traffic running and performing a "vMotion" (migration) on different Ixia IxLoad VMs while they were still responding to clients (still sending traffic). Indeed, the same behavior was witnessed as described above. HTTP was blocked where expected, and forwarded where expected, as was FTP. We randomly chose to move the outside-user-facing presentation tier IxLoad VM to a new blade, and in addition we also moved the outside-user-facing application tier IxLoad VM. We were left feeling pretty secure.

Next Page: Locator/ID Separation Protocol (LISP)
Previous Page: Virtual Machine Fabric Extender Performance

Back to the Cisco Test Main Page

(0)  | 
Comment  | 
Print  | 
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
Featured Video
Upcoming Live Events
September 17-19, 2019, Dallas, Texas
October 1-2, 2019, New Orleans, Louisiana
October 10, 2019, New York, New York
October 22, 2019, Los Angeles, CA
November 5, 2019, London, England
November 7, 2019, London, UK
November 14, 2019, Maritim Hotel, Berlin
December 3-5, 2019, Vienna, Austria
December 3, 2019, New York, New York
March 16-18, 2020, Embassy Suites, Denver, Colorado
May 18-20, 2020, Irving Convention Center, Dallas, TX
All Upcoming Live Events