About network address translation

BMC Network Automation supports static address translation on virtual firewalls (VFWs) that support Network Address Translation (NAT). Static NAT support allows public addresses to be acquired, which the VFW maps to the private addresses of server NICs that are added to the container. It also makes the algorithm for translating high-level path rules into low-level firewall rules aware of VFWs along the path, which perform these static translations.

This topic includes the following sections:

Runtime API calls

Static address translation on a container node that supports NAT is supported by a runtime API available in the BMC Network Automation AddressingService class. The following API calls are associated with this class:

acquiredNatAddress2(): You provide the container name and the private address that you want to NAT and the registerDNS flag (with or without additional parameters). BMC Network Automation acquires a public address and adds a NAT entry to the container node for this public-private address pair. To acquire the public address, BMC Network Automation uses the AddressPool specified as the NAT pool in the address pool for the private address.
releaseNatAddress2(): You provide the container name and the public address. BMC Network Automation removes the NAT entry from the device for this public address, and releases this address back to the address pool from which it was acquired. The API also allows you to provide a flag to state whether the public address should be released if there was a failure during device update to remove the NAT entry.

See the AddressingService class for more information about these API calls.

Pod and container blueprint child tag

The addressPoolBlueprint tag in the pod and container blueprints has a child tag to support static NAT: natPoolName. natPoolName specifies the name of an address pool from which the public address is acquired during the acquireNatAddress() call.

The following is an example of the schema for addressPoolBlueprint including the natPoolname child tag.

<addressPoolBlueprints>
   <addressPoolBlueprint>
       <addressSpaceBlueprintName>My Infrastructure Address Space</addressSpaceBlueprintName>
       <defaultPoolSize>20</defaultPoolSize>
       <name>My Container Level Address Pool 2</name>
       <natPoolName>My Nat Pool</natPoolName>
       <networkName>My Container Level Network</networkName>
   </addressPoolBlueprint>
</addressPoolBlueprints>

In the example, when the passed-in private address is acquired from My Container Level Address Pool 2, BMC Network Automation acquires the public address from My Nat Pool.

BMC Cloud Lifecycle Management imposes a limitation that the address pool defined in the natPoolName child tag must be taken from a provisioning address space. BMC Cloud Lifecycle Management does not support an address pool taken from an address range to be used as a NAT pool.
BMC Cloud Lifecycle Management also imposes a limitation that the network container can have at most only one address pool (or chain of identically named address pools) designated as the NAT Pool, which can then be re-used as the NAT pool across multiple VM, VIP, or physical server provisioning address pools.

See Pod blueprint XML reference and Container blueprint XML reference for more information about the addressPoolBlueprint tag.

Container blueprint child tag

The nodeBlueprint tag in the container blueprint has a child tag that supports static NAT: natTypeBlueprint. The natTypeBlueprint tag specifies how BMC Network Automation should acquire and translate static NAT addresses. The addresses acquired are typically the public address for a private address which has already been acquired during NIC provisioning. Static NAT is typically done in the VFW. Within each natTypeBlueprint, you specify actionInfoBlueprints that are Deploy to Active actions for creating a new NAT entry when a public address is acquired, and removing an old NAT entry when a public address is released.

See Container blueprint XML reference for more information about the nodeBlueprint and natTypeBlueprint tags.

The following is an example of the schema for nodeBlueprint including the natTypeBlueprint child tag.

<natTypeBlueprint>
   <addressTranslatorBlueprints>
       <addressTranslatorBlueprint>
           <addressPoolNames>
               <addressPoolName>My Container Level Address Pool 2</addressPoolName>
           </addressPoolNames>
           <insideInterfaceName>inside</insideInterfaceName>
           <outsideInterfaceName>outside</outsideInterfaceName>
       </addressTranslatorBlueprint>
   </addressTranslatorBlueprints>
   <createNatActionInfoBlueprint
xsi:type="mergeActionInfoBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
       <templateGroups>
           <item>My Create Nat Template</item>
       </templateGroups>
   </createNatActionInfoBlueprint>
   <removeNatActionInfoBlueprint xsi:type="mergeActionInfoBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
       <templateGroups>
           <item>My Remove Nat Template</item>
       </templateGroups>
   </removeNatActionInfoBlueprint>
</natTypeBlueprint>

When the natTypeBlueprint tag is specified in the Firewall Host node blueprint, the actual NAT commands are executed in its guest VFW.

Static NAT in the BMC Network Automation user interface

Once static NAT has been set up in a container blueprint, a section is added to the container blueprint properties in the BMC Network Automation user interface. To access this page, navigate to Network > Virtual Data Center > Container Blueprints in the BMC Network Automation user interface, and click the View icon for the desired container blueprint. An example is shown in the following figure:

These settings are inherited by container instances, as shown in the following figure:

Example static NAT configurations

The following sections contain example static NAT configurations.

Accessing a VM from a single external network

A typical example for the use of static NAT would be a simple translation, where the user is looking to acquire a public address for a VM so it can be reached from the external network. Assuming an external network that connects to the VFW via IF1, and a VM (a private address from the VLAN 3 pool) that connects to the VFW via IF2, you would like to direct traffic from the external network to the VM. You would specify the following address translator blueprint:

Accessing a VM from multiple external networks

The NAT type blueprint can also be used to do complex translations, such as accessing a VM from multiple external networks. Assuming two external networks that are connecting to the VFW via IF1 and IF2, and a VM (a private address from the VLAN 3 pool) that connects to the VFW via IF3, you would like to direct traffic from both external networks to VM1. You would specify the following address translator blueprints:

When the user invokes the acquireNatAddress() call, BMC Network Automation evaluates the two address translator blueprints, and adds two distinct NAT entries to the device, allowing traffic on both paths.

Accessing two VMs from the same external network

The NAT type blueprint can also be used to do complex translations, such as accessing two VMs from a single external network. Assuming an external network that is connecting to the VFW via IF1, and two VMs (private addresses from the VLAN 3 and VLAN 4 pools) that connect to the VFW via IF2 and IF3, you would like to direct traffic from the external network to both VMs. You would specify the following address translator blueprints:

NAT sensitivity in path rule translation

The path rule translation algorithm in BMC Network Automation is currently sensitive to both static NAT done in the VFW, and dynamic NAT done in the VLB.

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.

When a path rule is added to a network container, BMC Network Automation first checks to see if there is a network path defined within the container on which it lies upon. If there is none, the attempt to add the path rule is rejected. If a network path exists, BMC Network Automation automatically translates it into firewall rules to be added to eligible firewall Access Control Lists (ACLs) along the underlying network path.

Whether an ACL along the path is eligible or not is a function of whether it is flagged as enabled for path updates in the original container blueprint. For performance reasons, a blueprint author might decide to only flag inbound ACLs as enabled for path updates.

The subtleties of how BMC Network Automation translates path rules into firewall rules are best communicated by using the following examples:

Example Container:

Consider a container with the following topology:

Network segments: Outlined in green
Firewalls: Outlined in red
Load balancers: Outlined in blue
Switches: Outlined in black

Only the inbound ACLs of the firewall interfaces have been flagged as enabled for path updates.

Each segment shows its associated network address and mask in parentheses. The perimeter firewall is configured for static NAT using 1.0.0.0/28 as its source for translated addresses. The load balancer is configured for dynamic PAT using blocks from 11.0.0.0/28 as its source for translated addresses.

The following network paths are defined:

Name	Endpoint 1	Service Nodes	Endpoint 2
NP1	External Segment	Perimeter FW, Access FW	NIC Segment
NP2	External Segment	Perimeter FW	VIP Segment
NP3	VIP Segment	Access FW	NIC Segment
NP4	NIC Segment	Access FW	NIC Segment

The following VMs are provisioned:

Name	Private Address	Public Address
VM1	10.0.0.11	1.0.0.11
VM2	10.0.0.12
VM3	10.0.0.13

The following load balancer pools are created:

Name	VIP Address	PAT Block	Entries
LBPool1	2.0.0.10	11.0.0.12 – 11.0.0.13	VM2, VM3

Use Case #1: No NAT

Consider that the administrator wants to allow SSH traffic to flow from the External Segment to the NIC Segment. He would do this by sending a request to BMC Network Automation to add the following path rule:

Action	Transport Protocol	Source Endpoint	Destination Endpoint	Destination Port
Permit	TCP	External Segment	NIC Segment	SSH

This path rule lies along network path NP1, so it is permissible. It is translated into the following additions to the inbound ACL of the outside interface of the Perimeter FW:

Action	Transport Protocol	Source Endpoint	Destination Endpoint	Destination Port
Permit	TCP	0.0.0.0/0	10.0.0.0/24	SSH

It is also translated into the following additions to the inbound ACL of the loopback interface of the Access FW:

Action	Transport Protocol	Source Endpoint	Destination Endpoint	Destination Port
Permit	TCP	0.0.0.0/0	10.0.0.0/24	SSH

The translation here is straight forward because the source and destination endpoints of the path rule refer to entire networks, and there is no NAT being done between entire networks.

Use Case #2: Static NAT

Consider that the administrator wants to allow FTP traffic to flow from the External Segment to VM1.

He would do this by sending a request to BMC Network Automation to add the following path rule:

Action	Transport Protocol	Source Endpoint	Destination Endpoint	Destination Port
Permit	TCP	External Segment	10.0.0.11	FTP

This path rule lies along network path NP1, so it is permissible. It is translated into the following additions to the inbound ACL of the outside interface of the Perimeter FW:

Action	Transport Protocol	Source Endpoint	Destination Endpoint	Destination Port
Permit	TCP	0.0.0.0/0	1.0.0.11	FTP

It is also translated into the following additions to the inbound ACL of the loopback interface of the Access FW:

Action	Transport Protocol	Source Endpoint	Destination Endpoint	Destination Port
Permit	TCP	0.0.0.0/0	10.0.0.11	FTP

The translation here is straight forward in the Access FW, but in the Perimeter FW, the originally specified destination address of 10.0.0.11 is replaced with 1.0.0.11. This is done because 10.0.0.11 corresponds to a private address, which the Perimeter FW statically translates to a public address of 1.0.0.11 for packets traveling from the outside interface to the inside interface.

Note that some firewalls perform “auto-translation” of rule endpoints, which are statically NATed. For such devices, the endpoint that BMC Network Automation specifies when it pushes the rule to the device must always be the private endpoint, and never the public endpoint. Therefore, if the Perimeter FW performs auto-translation, BMC Network Automation translates the path rule into a FW rule that specifies “10.0.0.11” (the private address) as its endpoint, instead of “1.0.0.11” (the public address).

The Cisco IOS FW (for example, CSR 1000V) and recent models of the Cisco ASA FW (version 9.0 or later) are examples of FWs that perform auto-translation.

Use Case #3: Dynamic NAT

Consider that the administrator wants to allow HTTP traffic to flow from the External Segment to VIP1, and then on to VM1 and VM2. He would do this by sending a request to BMC Network Automation add the following path rules:

Action	Transport Protocol	Source Endpoint	Destination Endpoint	Destination Port
Permit	TCP	External Segment	2.0.0.10	HTTP
Permit	TCP	2.0.0.10	10.0.0.12	HTTP
Permit	TCP	2.0.0.10	10.0.0.13	HTTP

The first path rule lies along network path NP2, and the second and third path rules (shown in red and blue respectively) lie along network path NP3, so they are all permissible. The first path rule is translated into the following additions to the inbound ACL of the outside interface of the Perimeter FW:

Action	Transport Protocol	Source Endpoint	Destination Endpoint	Destination Port
Permit	TCP	0.0.0.0/0	2.0.0.10	HTTP

The second and third path rules are translated into the following additions to the inbound ACL of the loopback interface of the Access FW (colors trace back to the originating path rules):

Action	Transport Protocol	Source Endpoint	Destination Endpoint	Destination Port
Permit	TCP	11.0.0.12	10.0.0.12	HTTP
Permit	TCP	11.0.0.13	10.0.0.12	HTTP
Permit	TCP	11.0.0.12	10.0.0.13	HTTP
Permit	TCP	11.0.0.13	10.0.0.13	HTTP

The translation here is straight forward in the Perimeter FW, but in the Access FW, the originally specified source network of 0.0.0.0/0 is replaced with 11.0.0.12 – 11.0.0.13. This is done because 2.0.0.10 corresponds to a VIP address, which the VLB dynamically translates to the address block 11.0.0.12 – 11.0.0.13. Because BMC Network Automation does not support the ability to specify an address block as an endpoint in a firewall rule, each path rule is mapped to multiple firewall rules, one for each address in the block.