Unsupported content

 

This version of the product has reached end of support. The documentation is available for your convenience. However, you must be logged in to access it. You will not be able to leave comments.

Configuring Juniper SRX firewalls

This topic provides information about Pod and Container Management (PCM) changes and requirements to support the management of the Juniper SRX firewalls using BMC Network Automation as part of a BMC Cloud Lifecycle Management implementation.

In a BMC Cloud Lifecycle Management implementation, the Juniper SRX logical system is used to provide multi-tenancy. The current version of BMC Network Automation supports multiple firewall interfaces. Firewall interfaces are mapped 1:1 with zones. In a Juniper VFW, security policies are applied to zones, and interfaces are assigned to zones. For more details, see Zone-based firewalls in the BMC Network Automation documentation.

Mapping in the BMC Network Automation object model

Support for Juniper SRX-based virtual firewalls in network containers is achieved by having the following mapping in the BMC Network Automation object model:

  • ContainerVfw maps to a logical system on the Juniper SRX device.
  • FirewallInterface maps to a physical interface/sub interface in the Juniper SRX. However, the Juniper SRX has an additional layer of abstraction called the security zone that does not have a peer in the BMC Network Automation object model. So, BMC Network Automation makes the Juniper security zone transparent, by having a 1:1 relationship between an interface and the security zone (that is, the logical system is configured to have an interface belong in a security zone, and the security zone name is of the form <interface name>-zone).
  • FirewallAcl maps to a list of policies between a from-zone and a to-zone.
  • FirewallRule maps to a policy.

    The fact that a policy specifically applies to a particular from-zone and a particular to-zone is different in the Juniper SRX than in the BMC Network Automation model. What this means is:
    • A rule on an inbound ACL of an interface applies to traffic originating in a network segment serviced by the interface that the ACL belongs to; the destination of the rule is on a network segment serviced by any other interface of the firewall. The inbound ACL is in effect a union of individual set of rules where each set of rules applies to traffic from this interface to one other interface of the VFW.
    • Similarly, a rule on an outbound ACL of an interface, applies to traffic destined for a network segment serviced by the interface the ACL belongs to; the source of the rule is on a network segment serviced by any other interface of the firewall. The outbound ACL is in effect a union of individual set of rules where each set of rules applies to traffic to this interface from another interface.

Back to top

Container blueprint requirements

Separate management IP addresses are not assigned for each guest logical system created. The guest device is created using the same host device IP address with the user-defined security context having the name of the logical system. The Juniper JunOS adapter internally switches CLI mode to the logical system and manages the guest device. To create a guest device using the IP address of the host device, you must set the useHostAddressForGuest flag as true in the containerFirewallHostBlueprint schema, with the guestAddressName tag set to null.

If you want to assign a management IP address for each guest logical system created, you must set the useHostAddressForGuest flag as false, and the guestAddressName tag should have defined a guestAddressBlueprintName child tag, which acquires the management IP address.

Interfaces that are going to be managed must be defined in a Virtual Firewall (VFW). In Juniper VFWs, you are not managing the interfaces directly, but managing security zones for policy creation. The templates defined for creating a container fetch the name of the managed interface blueprint for security zone creation.

Back to top

Creating network container blueprints

When you create a network container blueprint for network containers with Juniper SRX-based container VFWs, you should be aware of the following:

  • Separate management IP Address are not assigned for each guest logical system created. The guest device is created using the same host device IP address with a user-defined security context having the name of the logical system. The BMC Network Automation Juniper JunOS device adapter internally switches CLI mode to logical system and manages the guest device. When you create a guest device using the IP address of the host device, you have to define the useHostAddressForGuest tag as true in the containerFirewallHostBlueprint schema, with the guestAddressName tag set to null.

    If the customer wants to assign management of the IP address of each guest logical system created, the useHostAddressForGuest tag should be set to false, and the guestAddressName tag should have a defined guestAddressBlueprintName, which is acquires the managment IP address.
  • Interfaces that you are going to manage in VFW must be defined. BMC Network Automation is not managing interfaces directly, but managing security zones for policy creation. The templates defined for creating network containers fetch the name of managed interface blueprint for security zone creation.

Back to top

Container blueprint and substitution parameter changes

To support these changes, the name child tag in the managedInterfaceBlueprint tag in the container blueprint XML file can now be specified as a substitution parameter. Two new container substitution parameters, ${container.node.managedInterfaces[<interface-name>].sanitizedName} and ${container.nodes[<role-name>].managedInterfaces[<interface-name>].sanitizedName} have been added. See Container substitution parameter syntax for more information.

Back to top

Creating containers

Creating a container using the Juniper SRX involves the following:

  • Creating a logical system.
  • If a single interface is used to carry multiple VLAN traffic, that interface should be configured as a trunk.
  • If a single physical interface is used to create multiple inside networks, sub-interfaces should be created. These sub-interfaces should be assigned to a custom zone.

    For example, if ge-0/0/0 is a physical interface, and it is connected to a switch supporting two networks with VLAN 20 and VLAN 30, first ge-0/0/0 is VLAN-tagged, and then two sub-interfaces are created, ge-0/0/0.20 and ge-0/0/0.30 with respective VLAN ID and IP address.
  • Creating a security profile and assigning it to a created logical system for a guest device. You can using default values, or you can modify a template and use a runtime parameter to pass custom values.
  • Each sub-interfaces created is associated with a single security zone. During network container VFW creation, security zones are created by fetching the name of managed interface blueprint defined. A sanitized version of substitution parameter for container managed interface blueprint is used for security zone creation.

(Applicable for BMC Network Automation version 8.8.00 and later) BMC Network Automation does not support the add, remove, and replace firewall rule operations if the device is using tunneled transfer mode. The tunneled transfer mode pushes the ACL updates in an unsafe way because it first deletes the old ACL and then builds up the new ACL. The process might lead to data packets being processed incorrectly. If you are using the tunneled transfer mode in a Juniper SRX firewall device, set the device to use the file transfer mode.

Back to top

Pod blueprint requirements

If the Juniper SRX physical port connected to a switch is required to be configured as VLAN-tagging, the pod blueprint should have one or more pod node parameter defined for getting physical interface information. In container creation also this information is used to create sub-interfaces for service Network Interface Controller (NIC) segments.

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\sampleWithJuniperSrxVfw directory on the BMC Network Automation application server. See Pod model and Container model  for additional information on the sample pod and container blueprints for use with Juniper SRX firewalls.

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