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.

Multiple ACLs on virtual firewalls

The network container blueprint supports multiple firewall interface blueprints and the specification of inbound ACL blueprints and outbound ACL blueprints. BMC Network Automation manages both inbound and outbound ACLs for interfaces on virtual firewalls created from such network container blueprints. In addition, layer 2 connectivity information has been modeled. The model captures the network segments connected to a virtual firewall interface. The model also captures whether any virtual firewalls are bridged to each other. This enhanced support for multiple ACLs in network container virtual firewalls allows the support features at a slightly higher level of abstraction, such as support for path rules.

This topic contains the following information:

Network segments

A network segment is an entity which encapsulates a subnet that can be used as an endpoint in a firewall rule. This could either be an external network segment (for example, customer network segment), where the VLAN and subnet exist outside the system being managed, or an internal network segment (for example, NIC or VIP network segment), where the VLAN and subnet exist inside the system being managed. Network segments serve as endpoints in the network paths defined in a container.

A network segment has a name, but can also be annotated with a label (which for historical reasons is called a networkName attribute), and a tag value. A BMC Network Automation network segment corresponds to what BMC Cloud Lifecycle Management calls a network. The label and tag values from a BMC Network Automation network segment are used to initialize corresponding values in the corresponding BMC Cloud Lifecycle Managementnetwork.

External network segments

An external network segment is a network segment where clients reside who are talking to servers inside the container. This could be the internet (in which case the subnet will have a network address and mask of 0), or a corporate network.

Note

A subnet involved in an external network segment is not one acquired by BMC Network Automation from an IP Address Management (IPAM) system.

Internal network segments

An internal network segment is a network segment encapsulating a VLAN and address pool owned by the container, used either for connecting server NICs or load balancer VIPs.

NIC network segments

A NIC network segment is an internal network segment where server NICs can be connected. In the case of a container level NIC network segment, it encapsulates a container level VLAN (for example, data VLAN used exclusively by the container), and a container level address pool (for example, data subnet used exclusively by the container).

VIP network segments

A VIP network segment is an internal network segment where load balancer VIPs can be connected.

Back to top

Network paths

The network container blueprint author can specify network paths in the network container blueprints. Network containers are assigned network paths at container creation time.

Note

A path rule in BMC Network Automation is referred to as a network path in BMC Cloud Lifecycle Management. BMC Network Automation also has a notion of a network path but that has no corresponding entity in BMC Cloud Lifecycle Management

A network path identifies layer 3 connectivity between two network segments (endpoints), and the sequence service node (virtual firewall or virtual load balancer) hops present along the way. This information is used by BMC Network Automation to translate high-level security rules (called path rules) into low-level security rules (called firewall rules). This translation allows BMC Cloud Lifecycle Management to specify the security rules for a given service offering instance (SOI) at a high level (for example, “open up HTTP traffic between endpoints A and B”), leaving it to BMC Network Automation to translate that into ACL updates on all of the intervening firewall interfaces along the path involved.

If no network paths are defined in the container blueprint, BMC Network Automation automatically generates network paths as follows:

  • If there are no firewalls, BMC Network Automation generates network paths connecting all possible endpoints (network segments) when the container is provisioned.
  • If there are firewalls, BMC Network Automation generates network paths based on the connectivity of network segments to firewalls. The administrator specifies connectivity information when he specifies the firewall guest blueprints, their managed interface blueprints, and the serviced segments of the interfaces.

This mechanism has been implemented as a convenience to support rapid prototyping. BMC Network Automation also generates this set of network paths when upgrading a container created in BMC Network Automation version 8.1.

Consider a network container with the network connectivity as shown in the following figure:

BMC Network Automation auto-generates the following network paths:

Network pathSource endpointService nodeDestination endpoint
NP-1External Network[VFW-1]Customer Network 1
NP-2External Network[VFW-1]Customer Network 2
NP-3External Network[VFW-1, VFW-2]Customer Network 3
NP-4External Network[VFW-1, VFW-2]Customer Network 4
NP-5Customer Network 1[VFW-1]Customer Network 2
NP-6Customer Network 1[VFW-1, VFW-2]Customer Network 3
NP-7Customer Network 1[VFW-1, VFW-2]Customer Network 4
NP-8Customer Network 2[VFW-1, VFW-2]Customer Network 3
NP-9Customer Network 2[VFW-1, VFW-2]Customer Network 4
NP-10Customer Network 3[VFW-2]Customer Network 4


Recommendation

Do not rely on this mechanism in real-world scenarios. BMC strongly recommends that the administrator specify network paths explicitly in the container blueprint, specifically for distributed firewalls like Virtual Security Gateway (VSG), instead of relying on BMC Network Automation to generate them.

If network paths are defined within the container blueprint, the absence of a network path connecting two endpoints together causes attempts to translate high-level security rules along such a path to fail.

Network paths are of the form <Endpoint1> - [service node]* - <Endpoint2>, where Endpoint1 and Endpoint2 are pod or container network segments. A network path may have 0 or more service nodes, where a service node is a virtual firewall or a VLB. The first service node in the sequence should have layer-2 connectivity to Endpoint1 and the last service node should have layer 2 connectivity to Endpoint2.

Network paths are created in the following sequence:

  1. Create network paths from network path blueprints in the container blueprint.
  2. If no network path blueprints are in the container blueprint, BMC Network Automation generates them as follows:
    1. Assumes routing between all interfaces of a virtual firewall and generates a connectivity graph with serviced segments of interfaces and virtual firewalls as the vertices in the graph
    2. Looks for paths between all pairs of network segments; all paths found become network paths in the container

      Note

      Network paths derived this way will have virtual firewalls as service nodes, but not virtual load balancers because BMC Network Automation does not model the connectivity of virtual load balancers to virtual firewall interfaces.

  3. If no network paths are found, there is no virtual firewall in the network container, and network paths are created between every pair of network segments in the network container, and these network paths have no service nodes.
  4. A network path blueprint potentially has sub-paths called dependent network paths, which BMC Network Automation derives, as follows:
    A network path blueprint has dependent paths if it has a virtual load balancer. A network path has one of the following forms:

           1.   EP1 -\[ no service nodes \] - EP2
           2.   EP1 -\[ VLB \]- EP2
           3.   EP1 -\[ VLB - VFW+ \]- EP2
           4.   EP1 -\[ VFW+ - VLB \]- EP2
           5.   EP1 -\[ VLB - VFW+ - VLB \]- EP2
    

    EP1 and EP2 are endpoints. EP can be a VIP network segment or a NIC network segment.

  5. If a NIC network segment is attached to a VLB, BMC Network Automation creates:
    1. A dependent network path in which the NIC segment is replaced with its associated VIP network segment
    2. A dependent path between the NIC network segment and the associated VIP segment with the VLB as the service node
  6. If the VIP network segment is attached to a VLB, BMC Network Automation creates:
    1. A dependent network path in which the VIP segment is replaced with associated NIC network segments, one network path per associated NIC network segment
    2. A dependent path between the VIP network segment and the associated NIC network segments with the VLB as the service node, one network path per associated NIC network segment
  7. All dependent paths thus derived are added as network paths of the network container.

Identity network paths

Network containers have certain implicit network paths called identity network paths that are not displayed in the container details page. An identity network path is one in which Endpoint1 and Endpoint2 are identical, it has no service nodes, and every network segment in the network container has an identity network path.

Path rules

A path rule is a high-level rule (as opposed to a firewall rule, which is a low-level rule) in which you can specify the intention of the rule at the network container level (you specify a firewall rule for an individual ACL on an interface of a network container virtual firewall). A path rule can accommodate network segment names, ad hoc networks, or hosts as the source and destination, and BMC Network Automation internally translates a path rule into updates for one or more ACLs of virtual firewalls in the network container.

You can view the path rules that are associated with a network container by viewing the container details page for that network container in the BMC Network Automation user interface. Open the container details page for a network container by navigating to the Containers page (Network > Virtual Data Center > Containers) and clicking the View icon for the network container. 

The path rules section of the container details page lists updated ACLs for the network container, and it also lists the constituent firewall rules and other details for the ACLs. After firewall rules have been added, they cannot be modified. When you add path rules, they are stored in BMC Network Automation with their associated ACL updates and copy of constituent low-level rules. If you remove or replace any of the constituent firewall rules using firewall rule APIs, the changes are reflected in the VFW node section of the container details page. You can use the two lists of firewall rules to compare the original set of rules to those that are currently in use.

BMC Network Automation supports adding and removing path rules in the SecurityService API. A request to add a path rule is valid if at least one network path supports it. In other words, if you want to add a path rule with A as the source and B the destination, the request succeeds if there is a network path (including dependent and identity network paths) where A belongs to Endpoint1 and B belongs to Endpoint2 or A belongs to Endpoint2 and B belongs to Endpoint1. If no such network path is found, the request fails. Similarly, a remove path rules operation succeeds if at least one supporting network path is found. For both, if multiple supporting network paths are found, ACL updates are done on all matching network paths.

The replaceFirewallRules() method within the SecurityService class performs the following validations:

  • Does not change the rule ID
  • Displays an appropriate message if BMC Network Automation does not recognize the replacement Rule ID
  • Adds a new firewall rule if the replacement Rule ID is not specified or if it is specified as 0
  • Prevents the addition of a firewall rule with a duplicate Rule ID for a nonmatching context host address
  • Prevents the modification or deletion of a firewall rule that is created as a NAT rule

The removeFirewallRules() method within the SecurityService class performs the following validations:

  • Prevents the deletion of a firewall rule that is associated with a path rule
  • Prevents the deletion of a firewall rule that is created as a NAT rule

Notes

  • An adhoc firewall rule, which is reused by a path rule is deleted when the associated path rule is deleted.
  • A path rule can only be added if there is a supporting network path. Instances where the path rule has both its source and destination in the same network and the network is secured by a non-access layer firewall, do not need any supporting network path. Such path rules will display no value in the Supporting Network Paths column.

Back to top

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.

Comments