Configuring Fortinet FortiGate firewalls

This topic provides the following information on Pod and Container Management (PCM) changes and requirements to support the management of the Fortinet FortiGate firewalls using BMC Network Automation as part of a BMC Clould Lifecycle Management implementation.

Guidelines for creating pods (dedicated and shared mode)

The following sections describe the guidelines for creating pods to support dedicated and shared modes.

Supporting dedicated mode

In the dedicated mode, you create a guest device per container, so you do not need to select a guest device. You should select a host firewall device.

Supporting shared mode

While creating a pod for shared mode, the administrator needs to first select the host firewall device, and then select the guest firewall device. The host firewall is the physical FortiGate device, and the guest firewall device is the shared VDOM. The administrator can add the host and guest devices using the same management IP address, as the BMC Network Automation device adapter internally switches VDOM mode. The host device should be added with a security context set to none and the guest device, which acts as the shared VDOM, should be added with a security context set to the name of the VDOM.

The following figure shows the Pod Node page from the BMC Network Automation UI for a FortiGate perimeter firewall. The Device field is highlighted in red, and the Guest Device field is highlighted in blue. The Device field is used to select the host firewall device (the physical FortiGate device), and the Guest Device field is used to select the guest device (the shared VDOM).

The Interfacetrunkinside field can be used when any physical interface serving inside networks or any other outside networks, and you need to create an inside networks VLAN interface and need to associate it to a defined physical interface facing the inside network or any other network.

Back to top

Guidelines for configuring network container blueprints to support dedicated mode

The following guidelines are for the creation of guest devices when configuring network container blueprints.

• A configure action creates a separate VDOM and requires inside network VLAN interfaces, and an unconfigure action removes any static routes and deletes the VDOM. The configureActionInfoBlueprint and unconfigureActionInfoBlueprints schemas should be defined within the containerFirewallHostBlueprint schema.
• In dedicated mode, separate VDOMs are created per container. FortiGate firewalls are limited to a maximum of 11 characters for a VDOM name, so you need to ensure that the VDOM name used for the guest VDOM does not exceed 11 characters. The FortiGate sample network container blueprint for shared mode uses the guest device name prefix tag in following way:
  
  <guestDeviceNamePrefix>Vdom-${container.integers[guestInteger]}</guestDeviceNamePrefix>

Back to top

Guidelines for configuring network container blueprints to support shared mode

This section contains the guidelines for configuring network container blueprints to support shared mode for FortiGate firewalls.

Defining public address pool definition

A public address pool can be defined at the pod level as a pod-level address pool or can be defined at the network container level as an address space. The sample FortiGate network container blueprint contains an example of a container-level address space used to define a public address pool.

Back to top

Defining configuration and un-configuration templates for a shared Virtual Domain per network container

Configuration (configureActionInfoBlueprints) and unconfiguration (unconfigureActionInfoBlueprints) templates should be defined under the virtual guest blueprint (virtualGuestBlueprint xsi:type="containerVfwBlueprint"). A configuration template configures a VLAN interface for inside networks, sets a VLAN interface to a physical interface, and assigns it to a shared Virtual Domain (VDOM). The value of physical interface that serves inside networks is taken in the corresponding pod as a paramBlueprint. You can find examples of this in the sample FortiGate network container blueprint.

Back to top

Guidelines for network address translation on FortiGate

NAT is used to allow/deny an outside or external network to access a host provisioned in the inside network using public IP. BMC Network Automation supports static NAT to achieve this task.

Implementing static NAT on FortiGate requires that you do the following:

• Configure VIP and IP pool (IPPOOL). VIP is a type of NAT object that has static mapping of private and public address and external interface information. IPPOOL is used to define a public address pool used to NAT private address. IPPOOL has only one public address in case of static NAT.
• Configure a firewall policy for allowing/denying an outside or external network to access an inside network host. The destination address used under this policy should be VIP object. In this case, the source NAT value is false.
• A policy can be configured to allow/deny a NAT VM on the inside network to access an external network. In this case, the source NAT value is true.

Back to top

Defining NAT content in a network container blueprint

• Define a template for createNatActionInfoBlueprint to configure a VIP and an IP pool with names in the following format: vip-pri-${runtime.privateAddress} and pool-pri-${runtime.privateAddress}. Define a template for removeNatActionInfoBlueprint to delete a VIP and an IP pool with names in the following format: vip-pri-${runtime.privateAddress} and pool-pri-${runtime.privateAddress}. You should use the name formats define above for VIP and IP pool, because internal java code use the same VIP name and IP pool name while creating Deploy to Active scripts for firewall policies.

• Configure a firewall policy to allowing/denying access from the Internet to a NAT Virtual Machine (VM) or from a NAT VM to the Internet. When defining NAT policy, you need to define natRuleBlueprints under natTypeBlueprint. Multiple NAT rule blueprints can be defined for allowing/denying access on multiple ports. You can refer to the sample FortiGate network container blueprint for an example.
  
  

  Note

  In a NAT rule blueprint only one service can be defined. If multiple services need to be defined, you need to define multiple NAT rule blueprints.

• There should be at least one address translator blueprint which defines a private address pool as addressPoolName, the inside interface name as insideInterfaceName, and the outside interface name as outsideInterfaceName. Ensure that you use the exact same name as is defined in the managed interface blueprint for respective interfaces.
• Inside network address pools need to have a public pool defined which is used for acquiring public addresses. You can refer to the sample FortiGate network container blueprint for examples.

Back to top

Defining a managed interface for inside networks

All interfaces used for inside networks are created in the form of VLAN interfaces. In the FortiGate device, all interface names should be unique and should be less than 16 characters. You need to define a managed interface for inside networks such as FECust${container.id} or FECust${container.name}. You should restrict hardcoded characters to 6 to 8. The configure template should also use same name as the respective inside interface. You can refer to the sample FortiGate network container blueprint for an example.

Back to top

Defining a managed interface for external networks

BMC Network Automation does not create interface-facing external networks and BMC Network Automation assumes that those are existing interface-facing respective external networks.

Back to top

Guidelines for inbound and outbound ACLs

In FortiGate firewalls, the source and destination interfaces define the direction of traffic. For example, stating that the inbound ACL is on X interface means that traffic is coming inside of the firewall through the X interface, so the source of this traffic is the network served by the X interface. In case of outbound ACL on X interface traffic is flowing outside of Firewall through X interface so network served by X interface will be destination.

Back to top

BMC Network Automation determination of the source and destination interfaces

For inbound ACLs, BMC Network Automation treats the interface on which the inbound ACL is applied as the source interface, and the value of the destination interface depends upon the address used at the destination side. For outbound ACLs, BMC Network Automation treats the interface on which the outbound ACL is applied as the destination interface, and the value of the source interface is dependent upon the source address.

For example:
If the network container has a shared virtual firewall (VFW) with two managed interfaces, Inside and Outside. The Inside interface is serving a Network Interface Controller (NIC_ Segment Inside-Customer with a network (10.10.10.0/24), and the Outside interface is serving the Internet (0.0.0.0/0).

If the administrator wants to allow the inside network to access the Internet, the administrator needs to apply an inbound ACL on the Inside interface or an outbound ACL on the Outside interface. The source address should be from the inside network and the destination address can be any address.

Similarly, if the administrator needs to allow/deny the outside network access to the inside network, then the administrator needs to apply an inbound ACL on the Outside interface or an outbound ACL on the Inside interface.

Back to top

Limitations

• If a network address translation (NAT) rule policy deploy job should fail, BMC Network Automation does not roll back the job. You must manually clean all successfully created Virtual IP (VIP) addresses, IP pools, or policies.
• If a NAT action deploy job should fail, BMC Network Automation does not roll back the job. You must manually clean all successfully created VIP addresses, IP pools, or policies.
• The deployment of FortiGate firewalls in high availability configurations is not currently supported.

• BMC Network Automation does not allow the modification of the Deploy to Active scripts used to configure firewall rules. Extra commands/settings cannot be inserted in these scripts externally or by any other means.
  
  The commands used in creating scripts for configuring firewall rules with and without NAT are as follows:
  
  

  Example: Firewall Rules without NAT

  config firewall policy
  edit <policy_id>
  set srcaddr <source_address_name>
  set dstaddr <_destination_address_name>
  set service <service_name>
  set schedule always
  set schedule-timeout disable
  set status enable
  set action accept
  set srcintf <source_interface_name>
  set dstintf <destination_interface_name>
  

  Example:Firewall Rules with Source NAT set to true

  config firewall policy
  edit <policy_id>
  set service <service_name>
  set schedule always
  set schedule-timeout disable
  set status enable
  set action accept
  set srcintf <source_interface_name>
  set dstintf <destination_interface_name>
  set srcaddr <source_address_name>
  set dstaddr <_destination_address_name>
  set nat enable
  set ippool enable
  set poolname <ippool_name>
  

  Example:Firewall Rules with Source NAT set to false

  config firewall policy
  edit <policy_id>
  set srcaddr <source_address_name>
  set dstaddr <VIP_Name>
  set service <service_name>
  set schedule always
  set schedule-timeout disable
  set status enable
  set action accept
  set srcintf <source_interface_name>
  set dstintf <destination_interface_name>

Back to top