Unsupported content This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Configuring VMware vShield App firewalls

VMware vShield App firewall overview

VMware vShield App is a hypervisor-based application-aware firewall solution for virtual data centers. vShield App plugs directly into VMware vSphere to protect against internal network-based threats and reduce the risk of policy violations within the corporate security perimeter by using application-aware firewalls with deep packet inspection and connection control based on source and destination IP addresses.

vShield App provides the following key benefits:

  • Increases visibility and control over network communications between virtual machines (VMs)
  • Eliminates the need for dedicated hardware and VLANs to separate security groups from one another
  • Optimizes hardware resource usage while maintaining strong security
  • Simplifies compliance through comprehensive logging of all virtual machine network activity

The cloud administrator must install and manage licensing of the VMware vShield App VM.

The vShield App firewall is installed per ESX host. Therefore, the App firewall service is activated on the data center, the cluster under which the ESX host resides, and the port groups associated with that ESX host. BMC Network Automation does not manage the actual vShield App VM. Instead, it manages the vShield Manager through a representational state transfer (REST) API.

BMC Network Automation does not configure security policies at the data center, cluster, and vNIC layers. The administrator must define system rules to allow or block traffic by default. You configure vShield App in BMC Cloud Lifecycle Management to apply and remove firewall policies on the vShield App firewall of the defined networks.          

Back to top

Adding a device for the vShield App firewall in BMC Network Automation

You add the VMware vShield App device in BMC Network Automation by defining the context ID of the data center or the data center name in a user-defined security context field. If use want to use the context ID instead of the data center name, ensure that you retrieve this security context by executing a REST API call to the vshield Manager by typing https://vshieldManagerHostNameOrIPAddress/api/2.0/services/usermgmt/scopingobjects in your web browser before performing the following procedure:

  1. Select Network > Spans > Devices.
  2. In Device Type, specify VMware vShield App.
  3. In Security Context, specify the context ID of the data center retrieved earlier, as shown in the following figure:
    vshield_app_2.jpg
  4. In Host Name/IP Address/URL, specify the management IP address or host name of the vShield Manager, as shown in the following figure:
    vshield_app_3.jpg

Back to top

Guidelines for creating the container blueprint

  • vShield App is shared among containers and not deployed per container.
  • The container blueprint must have a node blueprint of containerFirewallHostBlueprint type with a defined virtualGuestBlueprint.
  • The virtualGuestBlueprint must have the following flags defined:
    • useHostAddressForGuest=true
    • useExistingGuestDeviceFlag=true
    • independentFlag=true (only if you want the firewall to toggle independently)
    • accessLayerFlag=true

  • If independentFlag is true, in the containerFirewallHostBlueprint tag, define conditional configureActionInfoBlueprints and unconfigureActionInfoBlueprints tags as shown in the following sample:

    <nodeBlueprint xsi:type="containerFirewallHostBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <addressBlueprints/>
     <category>4</category>
     <configureActionInfoBlueprints/>
     <dummyHostFlag>false</dummyHostFlag>
     <name>Firewall</name>
     <numVrfs>0</numVrfs>
     <role>Firewall</role>
     <unconfigureActionInfoBlueprints/>
     <virtualGuestBlueprint xsi:type="containerVfwBlueprint">
       <configureActionInfoBlueprints>
         <configureActionInfoBlueprint xsi:type="mergeActionInfoBlueprint">
           <name>Configure vShieldApp Namespaces</name>
           <condition>-EXISTS- container.nodes['VFW']</condition>
           <templateGroups>
             <item>Configure vShieldApp Namespaces</item>
           </templateGroups>
         </configureActionInfoBlueprint>
         <configureActionInfoBlueprint xsi:type="mergeActionInfoBlueprint">
           <name>Clean App Rules</name>
           <condition>-EXISTS- container.nodes['VFW']</condition>
           <templateGroups>
             <item>Dummy</item>
           </templateGroups>
         </configureActionInfoBlueprint>
       </configureActionInfoBlueprints>
       <guestAddressBlueprints/>
       <useHostAddressForGuest>true</useHostAddressForGuest>
       <useExistingGuestDeviceFlag>true</useExistingGuestDeviceFlag>
       <guestDeviceName>${container.nodes[Firewall].device.name}</guestDeviceName>
       <guestNodeName>VFW</guestNodeName>
       <sharesVirtualDevice>false</sharesVirtualDevice>
       <accessLayerFlag>true</accessLayerFlag>
       <defaultEnabledFlag>true</defaultEnabledFlag>
       <independentFlag>true</independentFlag>
       <unconfigureActionInfoBlueprints>
         <unconfigureActionInfoBlueprint xsi:type="mergeActionInfoBlueprint">
           <name>Clean App Rules</name>
           <templateGroups>
             <item>Clean App Rules</item>
           </templateGroups>
         </unconfigureActionInfoBlueprint>
       </unconfigureActionInfoBlueprints>
  • The template defined for Dummy must not have any configuration object because no object is required. To designate a dummy template, add an exclamation mark (!) in that template content.
  • For vShield App, no guest device is created. The host acts as a guest in the container. Therefore, in the container blueprint, the name of the guest device defined by the guestDeviceName tag must be the name of the host device represented by ${container.nodes[firewallHostNodeName].device.name}. 
  • The managedInterfaceBlueprint must contain the names of the port profiles created in vCentre for a particular network through port group creation. The portTypeBlueprint tag in the container blueprint must include these port profiles for the defined hypervisor.
  • If an external preconfigured network exists, you must define a managedInterfaceBlueprint tag for that external network. The name of the managed interface defined for the external network must be the same as the port profile used for the external network.
  • If existing port groups are used as managed interfaces for the vShieldApp firewall, all the rules existing on those interfaces are deleted and reapplied when the first rule is added into the ACL.

  • You can specify system-defined rules by adding ruleBlueprint tags under the inboundAclBlueprint and outboundAclBlueprint tags.

    Warning

    If container provisioning fails because of ruleBlueprint failure error, modify the -ConfigureAppNamespaces.xml template to increase the delay specified in the pollIntervalSecondsargument.

    For example: ex- add-delay -pollMax 2 -pollIntervalSeconds 50

  • Use the following base protocols from different applications to block or permit traffic on vShield App:

    Protocol number

    Protocol  name

    1

    ICMP

    2

    IGMP

    4

    IPV4

    6

    TCP

    17

    UDP

    41

    IPV6

    43

    IPV6ROUTE

    44

    IPV6FRAG

    46

    RSVP

    47

    GRE

    50

    ESP

    51

    AH

    58

    IPV6ICMP

    59

    IPV6OXT

    60

    IPV6OPTS

    108

    IPCOMP

    111

    IPX

    115

    L2TP

    132

    SCTP

Note

  • Firewall rules and path rules are created correctly on vCenter Server 5.1 and vShield App (vShield Manager) 5.1.2 for dvSwitch.
  • Firewall rules and path rules are created incorrectly for the following combinations of vCenter Server and vShield App (vShield Manager)
    • vCenter Server 5.1 and vShield App (vShield Manager) 5.1.2 with Cisco N1K device and vSwitch
    • vCenter Server 5.5 and vShield App (vShield Manager) 5.1.4 with Cisco N1K device, vSwitch, and dvSwitch

Back to top

Guidelines for inbound and outbound ACLs

A single managed interface must have one ACL as shown in the following code sample:

<managedInterfaceBlueprints>
 <managedInterfaceBlueprint>
   <bridgeInterfaceNames/>
   <inboundAclBlueprint>
     <enablePathUpdates>true</enablePathUpdates>
     <name>Inside-IN</name>
   </inboundAclBlueprint>
   <name>Inside-${container.id}</name>
   <servicedSegmentNames>
     <servicedSegmentName>Inside</servicedSegmentName>
   </servicedSegmentNames>
 </managedInterfaceBlueprint>
 <managedInterfaceBlueprint>
   <bridgeInterfaceNames/>
   <inboundAclBlueprint>
     <enablePathUpdates>true</enablePathUpdates>
     <name>Outside-IN</name>
   </inboundAclBlueprint>
   <name>Outside-${container.id}</name>
   <servicedSegmentNames>
     <servicedSegmentName>Outside</servicedSegmentName>
   </servicedSegmentNames>
 </managedInterfaceBlueprint>
</managedInterfaceBlueprints
Warning

Ensure that the port group name that you specify in the <name> tag under the <managedInterfaceBlueprint> tag is unique across the vCenter.

Back to top

Sample pod and container blueprints

You can find sample pod and container blueprints and related templates in the BCAN_HOME\public\bmc\bca-networks\csm\samples\sampleWithVshieldApp directory on the BMC Network Automation application server. For additional information about the sample pod and container blueprints for use with a VMware vShield App firewall, see Pod-model and Container-model.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*