Installing Cisco Virtual Security Gateway–VSG

Last time we have seen why and how to install and setup a Cisco Nexus1000V distributed switch. We now want to prevent one VM to talk to another entirely or just for some protocols. We could use traditional ACLs on the Nexus1000V itself, but this might not be scalable enough. For that reason we will now extend our virtual infrastructure (VI) further with Cisco’s Virtual Security Gateway or VSG.

First of all, what is a VSG? The VSG is a virtual firewall that protects VMs from each other within a single tenant. For example, if we take a look at the picture from below (source: www.cisco.com), we could see two web servers and two application servers within tenant “A”. Why would we allow them to talk to each other using whatever protocol they like, when all that’s needed is opening a HTTP(s) port from application server(s) to web servers(s)?  This is why we need a VSG.

image

But what if we would want to protect assets within tenant “A” from users in other tenants, such as tenant “B”? For that purposes we could use Cisco ASA 1000V Cloud Firewall. More on that topic some other time.

There is one more component that we will deal with in this blog: the VNMC (Virtual Network Management Center). This virtual appliance is used to manage the whole security infrastructure, both VSGs and ASAs.

Before we go ahead and install all this stuff, we may question ourselves, or better yet, our bosses may question us – why? Again, there could be several answers to this, but I like the “role separation” one. With all this implemented, we could have ESX admins in charge of VMs, network admins in charge of Nexus switches and security admins in charge of overall security. Nice!

In order to successfully deploy the VSG, we need to have our VI and physical infrastructure well prepared. We need to create appropriate VLANs, have addressing in place for management purposes, … Some components that we are building require L2 connectivity and some L3. Let’s try to break this down:

  • vCenter has to communicate with VSMs on a L3 level. We already have this in place from the previous blog.
  • vCenter also needs to communicate with the VNMC, so VNMC can, for example, retrieve VMs that we could use to build appropriate zones and filters. This communication is also L3.
  • VNMC must communicate with both VSM and VSG. This communication is for security policy enforcement. The VNMC communicate with VSM and VSG on L3 level.
  • VSG needs to communicate with VEM in order to receive a traffic flow from VEM (only initial packets), check a security policy and tell back the VEM what to do with further packets of that flow. This type of communication can happen on L2 or L3 level.
  • The communication between VSM and VEM is explained in previous blog and can also be a L2 or L3.

There are five major steps with the installation of VSG:

  1. Installing VNMC
  2. Installing VSG
  3. Register VSG with VNMC
  4. Register VSM with VNMC
  5. Register VNMC with vCenter

1. Installing VNMC

The VNMC is installed as a virtual appliance from an .OVA file with “Deploy OVF Template” file menu option. There are several steps that need to be completed. Some obvious steps, such as accepting EULA will not be shown here.

We specify the name and location of the virtual appliance:

image

We are doing a fresh installation:

image

Then specify a cluster:

image

And a host within a cluster:

image

As we are going to have a VNMC in a HA mode, we could select a local storage, as long as the other VNMC instance is on another host:

image

To conserve disk space, we select “Thin Provision” disk. This option is valid for VNMC deployment, in contrast to Nexus 1000V deployment:

image

Select appropriate management interface:

image

On the properties page, we select the IP address from a given VLAN, select other stuff, such as default gateway, hostname, etc. We also select admin user password and a shared secret. This shared secret is important, because it will be used when we establish a connection between the VNMC and VSG, and between VNMC and VSM:

image

After completing the wizard, we power on the appliance. When the VNMC boots up, we open a HTTPS session to its IP address or DNS name and log in as “admin” user. If we are able to connect and log in, we have successfully installed the VNMC:

image

2. Installing VSG

The VSG is also deployed as an OVF template. Before we do the installation, we need to create appropriate VLANs on our physical switches, as well as on Nexus 1000V switch. We also need appropriate port profiles created on Nexus. All trunks involved should pass VLANs that are needed for communication. We do have all that in place from our Nexus 1000V installation.

We should be able to deploy the OVF template by now. Here we will mention only the most important steps.

We have an option to install the VSG as a standalone appliance, HA primary or HA secondary. We choose “Install as a HA primary”. We could use a thin provisioned disk and use a local storage.

We then select appropriate networks to be used for “Data”, “Management” and “HA”interfaces. There is a catch in this specific deployment. It is not recommended to use two VLANs/Port groups for two services. In our case, we use VLAN10 for both “Management” and “Data” interfaces. Perhaps the “Data” interface should be separated from “Management”, but so far for our test infrastructure it will do the trick:

image

We then specify the HA ID, which needs to match on the secondary VSG, once we install it. Finally, we specify the VNMC IP address and a shared secret which has to match with a shared secret we used in step one, when installing the VNMC.

After wizard completes, we power on the VSG.

3. Register VSG with VNMC

The VNMC talks to the VSG by calling an agent that is located on the VSG. There are just a few configuration commands that needed to be performed on the VSG:

VSG#
VSG# dir bootflash:
! lines omitted
20938621     Aug 03 01:31:25 2012 
vnmc-vsgpa.2.0.1a.bin
! lines omitted

VSG#
VSG# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
VSG(config)# vnm-policy-agent
VSG(config-vnm-policy-agent)# registration-ip 10.1.x.141
VSG(config-vnm-policy-agent)# shared-secret somesharedsecret
VSG(config-vnm-policy-agent)# policy-agent-image bootflash:/vnmc-vsgpa.2.0.1a.bin
VSG(config-vnm-policy-agent)# exit
VSG(config)# exit
VSG#
VSG# show vnm-pa status
VNM Policy-Agent status is – Installed Successfully. Version 2.0(1a)-vsg

VSG#

As we can see, we list the IP address of the VNMC we want this VSG to be registered to, shared secret and an agent name and location. We also can see that the agent is installed successfully, which means that the communication with the VNMC is ok. This can be verified on the VNMC  itself. Under the “Administration->Service Registry->Clients”, we should see our VSG with the operational state “registered”:

image

4. Register VSM with VNMC

The registration of the VSM to the VNMC is very similar process as registering the VSG:

Nexus1KV-SPOP#
Nexus1KV-SPOP# dir bootflash:
! lines omitted
17456603     Oct 18 23:54:36 2012  vnmc-vsmpa.2.0.0.38.bin
! lines omitted

Nexus1KV-SPOP# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Nexus1KV-SPOP(config)# vnm-policy-agent
Nexus1KV-SPOP(config-vnm-policy-agent)# registration-ip 10.1.x.141
Nexus1KV-SPOP(config-vnm-policy-agent)# shared-secret somesharedsecret
Nexus1KV-SPOP(config-vnm-policy-agent)# policy-agent-image bootflash:/vnmc-vsmpa.2.0.0.38.bin
Nexus1KV-SPOP(config-vnm-policy-agent)# exit
Nexus1KV-SPOP(config)# exit
Nexus1KV-SPOP#
Nexus1KV-SPOP# show vnm-pa status
VNM Policy-Agent status is – Installed Successfully. Version 2.0(0.38)-vsm

Nexus1KV-SPOP#

We could also check the VSM agent status on the VNMC, following the very same steps as with VSG:

image

5. Register VNMC with vCenter

This is the final step in connecting all pieces together. First we need to download the vCenter extension from the VNMC. Log in to the VNMC and go to “Administration->VM Managers->General” and click “Export vCenter Extension”:

image

Save the XML file to appropriate location on the disk.

Now we use the vSphere client to register new plug-in, just as we did with the Nexus 1000V installation. Click “Plug-ins->Manage Plug-ins”, right click the white space and select “New Plug-in”. Then point to the previously saved XML extension, and select “Register Plug-in”. Ignore the security warning and we should be fine. This new plug-in should be listed among other plug-ins. Now we can add the VM Manager from the VNMC. Under the same spot as in previous picture, we select “Add VM Manager” and point to our vCenter server:

image

And of course, this can be verified from the VNMC:

image

The admin state should be “enable” and the operational state should be “up”.

And this completes our five-steps process of installing the VSG.

We now have a Nexus1000V, which is prerequisite for VSG, we have VSG and we have VNMC to manage the VSG now, and the ASA 1000V later. We of course have vCenter and some VMs to play with.

Next time we are going to create a tenant, assign a VSG to it, create some zones with VMs and join them to the tenant and see how can we prevent VMs from one zone to access VMs in another.

Thanks for reading!

Advertisements
This entry was posted in Cisco, Cloud, Virtualization, VMWare and tagged , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s