Configuring Cisco VSG firewalls

This topic contains information about configuring Cisco Virtual Security Gateway (VSG) firewalls for use with BMC Network Automation and BMC Cloud Lifecycle Management.

Overview

The Cisco Virtual Security Gateway (VSG) is supported as a type of virtual firewall (VFW) that you can use in network containers. A VSG runs the Nexus operating system and is controlled by a Cisco Virtual Network Management Center (VNMC). This means you can log on to the VSG directly to inspect its configuration, but to make changes to it, you must log on to the VNMC. These changes are automatically propagated by the VNMC to the VSG. Both the VSG and VNMC run as software inside a VM. They are represented as devices in BMC Network Automation, with the VNMC acting as the manager device (which uses the Cisco VNMC device adapter) of the VSG worker device (which uses the Cisco Nexus device adapter).

The Cisco VNMC device adapter communicates with the VNMC via a REST API over HTTP. A set of pseudo-commands has been defined for BMC Network Automation for use with the VNMC, which you can include in templates pushed to the VNMC.These pseudo-commands are documented on the the Device Adapter Capabilities report, which is attached on the Supported devices topic in the BMC Network Automation documentation. These pseudo-commands are automatically translated by BMC Network Automation into the appropriate REST calls to make configuration changes in the VNMC.

Cisco architecture

The VSG secures packets sent and received by VMs attached to the network via a Cisco Nexus 1000V switch (N1K). This can include packets exchanged between VMs (east-west traffic), and well as packets exchanged between a VM and an external client outside the container (north-south traffic). To perform this filtering, a port profile (port type) in the N1K is configured to use a specified VSG and a specified security profile to secure the packets sent and received by VMs attached to the network using that port profile. Security profiles are defined in the VNMC for this purpose, which contain lists of rules, called policies, organized into policy-sets. The rules define logic for permitting and denying packets involving various sources and destinations.

After it is configured, the N1K passes the first packet in a TCP connection across a data VLAN to the VSG, for it to evaluate against the security profile. The N1K caches the result, so that subsequent packets in the same connection can be filtered by the N1K without involving the VSG. The same security profile can be used to secure multiple port profiles across multiple N1Ks. Similarly, the same VSG can be used to secure multiple port profiles across multiple N1Ks.

A VSG can be configured either as a single VM running in stand-alone mode, or as a pair of VMs running in high-availability (HA) mode, with an HA VLAN used to perform heartbeat checks between them. The failure of the active VM in the pair is handled transparently by the VNMC, providing active-standby fault-tolerant capability in which the same management IP address is used by whichever VM is currently active.

The VLANs used for data, HA, and management traffic sent to a VSG can be different VLANs or the same VLAN, depending on your configuration.

A VSG is managed under the scope of a particular tenant defined within the VNMC.

Back to top

BMC Network Automation model

This section describes how Cisco VSG firewalls are handled within the BMC Network Automation model.

Pod and Container Management

A VSG is represented as a guest VFW node in the BMC Network Automation Pod and Container Management (PCM) model, with the VNMC acting as its firewall host node. A flag is added to the VFW node to denote that for the VSG, traffic is secured at the access layer instead of at the perimeter like other VFWs. In most other respects, however, BMC Network Automation treats the VSG like any other VFW. Such access layer firewalls are presented as Distribution Firewalls in the BMC Cloud Lifecycle Management user interface, meaning that they are firewalls distributed to locations where server VMs are being deployed.

Each security profile that the VSG uses is modeled as a separate firewall interface within the VFW. These interfaces are treated as loopback interfaces by BMC Network Automation, meaning that packets coming into the interface for filtering are expected to be sent back out to the same interface afterwards. Each such loopback interface manages a single ACL, rather than two ACLs like other interfaces. By convention, BMC Network Automation treats this ACL as a managed inbound ACL. This inbound ACL corresponds to a policy within the security profile that is represented by the interface.

While executing any action on the VSG (for example, VSG Deploy), irrespective of the field name or action, for IP address and subnet mask fields, specify the values in dotted decimal format because the VSG device does not support the Classless Inter-Domain Routing (CIDR) format.

As a result, when you add a VNMC device to BMC Network Automation, ensure that you specify the IP address of the device and not the host name for the Host Name/IP Address/URL field for Primary Interface or Auxiliary Interface so that when BMC Network Automation deploys the VSG firewall (guest node) VM to VCenter, Management IP Gateway and VNMC IP Address are passed in dotted decimal format.

Also, because the VSG is modeled as a VFW, it is owned by a particular container, because sharing a VFW across multiple containers is not currently supported. It also means that, like VFWs, you can have multiple VSGs within a single container.

Because each VSG is owned by a container, each container corresponds to a tenant in the VNMC under which the VSG is located.

Back to top

ACL initialization

One difference in behavior between the VSG and other VFWs is that the VSG can secure traffic between server VMs on the same VLAN, which other VFWs cannot. Such traffic is blocked by default by the VSG. If you do not want this default behavior, you must add rules to the ACL to change it. To facilitate this, BMC Network Automation enhancements allow the container blueprint author to specify initial rules to be applied to an ACL when it is enabled. You might want to use this, for example, to allow traffic between VMs on the same NIC segment by default, or to allow traffic between a VIP segment and the NIC segment it serves by default.

Back to top

Lifecycle management

The guest VFW device representing the VSG is created when the VFW is enabled within a given container, just like any other VFW device. BMC Network Automation currently is responsible for not only creating the VSG device in its database, but also creating the VM in VCenter when this happens. Likewise, when the VFW is disabled, BMC Network Automation is responsible for both deleting the VSG device in its database and destroying the VM in VCenter. External scripts actions that call the VSphere API have been developed and delivered with the BMC Network Automation system to do this. The container blueprint author is expected to invoke these actions as part of configuring and unconfiguring the VFW being enabled and disabled. The VM deployment criteria passed to these actions can come either from pod parameters in the firewall host node, or runtime parameters, which the container administrator specifies.

Back to top

Sample network container blueprint

A sample blueprint for constructing a container that has a VSG is delivered with the BMC Network Automation system in the BCAN_HOME\public\bmc\bca-networks\csm\samples\sampleWithVSG directory of the BMC Network Automation application server.

Topology

The following diagram depicts the logical topology of an instance of this sample container:

Sample Container Logical Topology

In the diagram above, a Cisco 6500 switch (C6K) is being used at the edge layer, and an N1K and VSG are being used at the access layer. VM1 and VM2 are servers that have been added to the Customer Network 1 NIC segment, while VM3 and VM4 are servers that have been added to the Customer Network 2 NIC segment. VLAN 10 is delivering external traffic to the edge, while VLAN 12 is delivering traffic to Customer Network 1 and VLAN 13 is delivering traffic to the Customer Network 2. VLAN 11 is serving as the data VLAN for the VSG to filter packets passing through the N1K. The Network1 interface on the VSG corresponds to the security profile being used to filter traffic for VMs on Customer Network 1 while the Network2 interface corresponds to the security profile being used to filter traffic for VMs on Customer Network 2.

Back to top

Network container blueprint

If you inspect the sample container blueprint, you will notice that BMC Network Automation uses external script actions to create a VSG VM HA pair when the VFW is enabled, and to destroy the VSG VM HA pair when it is disabled. The values passed to these actions are being specified as pod parameters on the firewall host node in the pod.  BMC Network Automation also initializes the ACLs on each VFW interface to allow traffic between VMs on the NIC segment it secures traffic for.

Another item to notice is that the sample container blueprint declares what are called identity network paths. These are network paths in which the two endpoints in the path are the same. The Network1-Network1 path is one such example, and the Network2-Network2 path is another. Each specifies the VSG as a service node along the path. Configuring identity network paths is necessary to have BMC Network Automation correctly update the VSG ACLs when path rules are added by BMC Cloud Lifecycle Management to control traffic between VMs on the same NIC segment.

Back to top

Provisioning sequence

The following sequence of actions are executed when the container is configured:

In this sequence, the action to initialize the VSG is being performed as a host action on the VNMC device. However, it could just as easily be performed as a guest action on the VSG device since the template involved would be redirected to the VNMC underneath due to the manager-worker relationship between the VNMC and VSG.

The creation of the tenant and its syslog policy is performed in a separate action from the initialization of the VSG. This is advised so that these commands are executed once, when the container is provisioned. The VSG is initialized separately, whenever the VFW is enabled.

One important point here is that the container blueprint author must use the expected naming conventions in their templates for the entities being added to the VNMC. This is necessary so that the templates created by BMC Network Automation to make ACL updates by adding rules to the policies in the VNMC can operate correctly on those same entities. The naming conventions are as follows, along with substitution parameters which can be used in their place if desired:

Back to top