Configuring the NAT Policy

Translating IP Addresses

NAT (Network Address Translation) is a feature of the Firewall Software Blade and replaces IPv4 and IPv6 addresses to add more security. You can enable NAT for all SmartDashboard objects to help manage network traffic. NAT protects the identity of a network and does not show internal IP addresses to the Internet. You can also use NAT to supply more IPv4 addresses for the network.

The Firewall can change both the source and destination IP addresses in a packet. For example, when an internal computer sends a packet to an external computer, the Firewall translates the source IP address to a new one. The packet comes back from the external computer, the Firewall translates the new IP address back to the original IP address. The packet from the external computer goes to the correct internal computer.

SmartDashboard gives you the flexibility to make necessary configurations for your network:

• Easily enable the Firewall to translate all traffic that goes to the internal network.
• SmartDashboard can automatically create Static and Hide NAT rules that translate the applicable traffic.
• You can manually create NAT rules for different configurations and deployments.

How Security Gateways Translate Traffic

A Security Gateway can use these procedures to translate IP addresses in your network:

• Static NAT - Each internal IP address is translated to a different public IP address. The Firewall can allow external traffic to access internal resources.
• Hide NAT - The Firewall uses port numbers to translate all specified internal IP addresses to a single public IP address and hides the internal IP structure. Connections can only start from internal computers, external computers CANNOT access internal servers. The Firewall can translate up to 50,000 connections at the same time from external computers and servers.
• Hide NAT with Port Translation - Use one IP address and let external users access multiple application servers in a hidden network. The Firewall uses the requested service (or destination port) to send the traffic to the correct server. A typical configuration can use these ports: FTP server (port 21), SMTP server (port 25) and an HTTP server (port 80). It is necessary to create manual NAT rules to use Port Translation.

Using Hide NAT

For each SmartDashboard object, you can configure the IP address that is used to translate addresses for Hide NAT mode:

• Use the IP address of the external Security Gateway interface
• Enter an IP address for the object

Hide NAT uses dynamically assigned port numbers to identify the original IP addresses. There are two pools of port numbers: 600 to 1023, and 10,000 to 60,000. Port numbers are usually assigned from the second pool. The first pool is used for these services:

• rlogin (destination port 512)
• rshell (destination port 513)
• rexec (destination port 514)

If the connection uses one of these services, and the source port number is below 1024, then a port number is assigned from the first pool.

You cannot use Hide NAT for these configurations:

• Traffic that uses protocols where the port number cannot be changed
• An external server that uses IP addresses to identify different computers and clients

Sample NAT Deployments

Static NAT

Firewalls that do Static NAT, translate each internal IP address to a different external IP address.

Sample Static NAT Workflow

An external computer in the Internet sends a packet to 192.0.2.5. The Firewall translates the IP address to 10.10.0.26 and sends the packet to internal computer A. Internal computer A sends back a packet to the external computer. The Firewall intercepts the packet and translates the source IP address to 192.0.2.5.

Internal computer B (10.10.0.37) sends a packet to an external computer. The Firewall intercepts the packet translates the source IP address to 192.0.2.16.

Hide NAT

Firewalls that do Hide NAT use different port numbers to translate internal IP address to one external IP address. External computers cannot start a connection to an internal computer.

Sample Hide NAT Workflow

Internal computer A (10.10.0.26) sends a packet to an external computer. The Firewall intercepts the packet and translates the source IP address to 192.0.2.1 port 11000. The external computer sends back a packet to 192.0.2.1 port 11000. The Firewall translates the packet to 10.10.0.26 and sends it to internal computer A.

NAT Rule Base

The NAT Rule Base has two sections that specify how the IP addresses are translated:

• Original Packet
• Translated Packet

Each section in the NAT Rule Base is divided into cells that define the Source, Destination, and Service for the traffic.

Automatic and Manual NAT Rules

There are two types of NAT rules for network objects:

• Rules that SmartDashboard automatically creates and adds to the NAT Rule Base
• Rules that you manually create and then add to the NAT Rule Base

When you create manual NAT rules, it can be necessary to create the translated NAT objects for the rule.

Using Automatic Rules

You can enable automatic NAT rules for these SmartDashboard objects:

• Security Gateways
• Nodes
• Networks
• Address Ranges

SmartDashboard creates two automatic rules for Static NAT to translate both the source and destination of the packets. One rule is created for Hide NAT to translate the source of the packets.

For network and address range objects, SmartDashboard creates a different rule to NOT translate intranet traffic. IP addresses for computers on the same object are not translated.

This table summarizes the NAT automatic rules:

Order of NAT Rule Enforcement

The Firewall enforces the NAT Rule Base in a sequential manner. Automatic and manual rules are enforced differently. Automatic rules can use bidirectional NAT to let two rules be enforced for a connection.

• Manual rules - The first manual NAT rule that matches a connection is enforced. The Firewall does not enforce a different NAT rule that can be more applicable.
• Automatic rules - Two automatic NAT rules that match a connection, one rule for the Source and one for the Destination can be enforced. When a connection matches two automatic rules, those rules are enforced.

SmartDashboard organizes the automatic NAT rules in this order:

1. Static NAT rules for Firewall, or node (computer or server) objects
2. Hide NAT rules for Firewall, or node objects
3. Static NAT rules for network or address range objects
4. Hide NAT rules for network or address range objects

Sample Automatic Rules

Static NAT for a Network Object

1. Intranet connections in the HR network are not translated. The Firewall does not translate a connection between two computers that are part of the HR object.

   The Firewall does not apply rules 2 and 3 to traffic that matches rule 1.

2. Connections from IP addresses from the HR network to any IP address (usually external computers) are translated to the Static NAT IP address.
3. Connections from any IP address (usually external computers) to the HR are translated to the Static NAT IP address.

Hide NAT for Address Range

1. Intranet connections in the Sales address range are not translated. The Firewall does not translate a connection between two computers that use IP addresses that are included in the Sales object.

   The Firewall does not apply rule 2 to traffic that matches rule 1.

2. Connections from IP addresses from the Sales address range to any IP address (usually external computers) are translated to the Hide NAT IP address.

Configuring Static and Hide NAT

Use the NAT page in the Gateway Properties window to enable and configure NAT for SmartDashboard objects.

Configuring Static NAT

When you enable Static NAT, each object is translated to a different IP address. SmartDashboard can automatically create the NAT rules, or you can create them manually.

Configuring Hide NAT

Hide NAT uses different port numbers to identify the internal IP addresses. When you enable Hide NAT mode, the Firewall can translates the IP address to:

• The IP address of the external Security Gateway interface
• The IP address for the object

  Note - You cannot use Hide NAT for these configurations: Traffic that uses protocols where the port number cannot be changed An external server that uses IP addresses to identify different computers and clients

Enabling Automatic NAT

SmartDashboard can automatically create and configure the NAT rules for a network. Enable automatic NAT for each object that you are translating the IP address. Then configure the Firewall Rule Base to allow traffic to the applicable objects.

To enable automatic NAT:

1. Double-click the SmartDashboard object.

   The General Properties window opens.

2. Click NAT.
3. Select Add Automatic Address Translation rules.
4. Select the Translation method: Hide or Static.
5. Configure the NATed IP address for the object.
   • Hide behind Gateway - Use the Security Gateway IP address.
   • Hide behind IP address - Enter the IP address.
6. Click Install on Gateway and select All or the Security Gateway that translates the IP address.
7. Click OK.
8. Do these steps for all the applicable objects.
9. Click Firewall > Policy.

   The Policy page opens and shows the Firewall Rule Base.

10. Add rules that allow traffic to the applicable objects.
11. Install the policy.

Automatic Hide NAT to External Networks

For large and complex networks, it can be impractical to configure the Hide NAT settings for all the internal IP addresses. An easy alternative is to enable a Firewall to automatically Hide NAT for all traffic with external networks. The Firewall translates all traffic that goes through an external interface to the valid IP address of that interface.

In this sample configuration, computers in internal networks open connections to external servers on the Internet. The source IP addresses of internal clients are translated to the IP address of the external interface.

The source IP address is translated to the applicable external interface IP address: 192.0.2.1 or 192.0.2.100.

To enable automatic Hide NAT:

1. Double-click the Security Gateway.

   The Gateway Properties window opens.

2. From the navigation tree, click NAT.

   The NAT page opens.

3. Select Hide internal networks behind the Gateway external IP.
4. Click OK and then install the policy.

Enabling Manual NAT

For some deployments, it is necessary to manually define the NAT rules. Create SmartDashboard objects that use the valid (NATed) IP addresses. Create NAT rules to translate the original IP addresses of the objects to valid IP addresses. Then configure the Firewall Rule Base to allow traffic to the applicable translated objects with these valid IP addresses.

These are some situations that must use manual NAT rules:

• Rules that are restricted to specified destination IP addresses and to specified source IP addresses
• Translate both source and destination IP addresses in the same packet.
• Static NAT in only one direction
• Translate services (destination ports)
• Rules that only use specified services (ports)
• Translate IP addresses for dynamic objects

This procedure explains how to configure manual Static NAT for a web server. You can also configure manual Hide NAT for SmartDashboard objects.

To enable manual Static NAT:

1. Right-click the object in SmartDashboard and select Clone.

   The General Properties window of the new object opens.

2. Enter the Name. We recommend that you name the object <name>_valid_address.
3. Enter the NATed IP address.
4. Click OK.
5. Click Firewall > NAT.

   The NAT page opens and shows the NAT Rule Base.

6. Add a manual rule above the automatic NAT rules.
7. Configure the manual rule to translate the IP address. For example:
   • Original Packet Source - WebServer
   • Translated Packet Source - WebServer_valid_address
8. Click Firewall > Policy.

   The Policy page opens and shows the Firewall Rule Base.

9. Add rules that allow traffic to the applicable NATed objects.

   These objects are the cloned objects that are called <name>_valid_address.

10. Install the policy.

Sample Deployment (Static and Hide NAT)

The goal for this sample deployment is to configure:

• Static NAT for the SMTP and the HTTP servers on the internal network. These servers can be accessed from the Internet using public addresses.
• Hide NAT for the users on the internal network that gives them Internet access. This network cannot be accessed from the Internet.

To configure NAT for the network:

1. Enable automatic Static NAT for the web server.
   1. Double-click the Alaska.Web object and select NAT.
   2. Select Add Automatic Address Translation Rules.
   3. In Translation method, select Static.
   4. Select Hide behind IP Address and enter 2001:db8:0:a::5.
   5. Click OK.
2. Enable automatic Static NAT for the mail server.
   1. Double-click the Alaska.Mail object and select NAT.
   2. Select Add Automatic Address Translation Rules.
   3. In Translation method, select Static.
   4. Select Hide behind IP Address and enter 2001:db8:0:a::6.
   5. Click OK.
3. Enable automatic Hide NAT for the internal computers.
   1. Double-click the Alaska_LAN object and select NAT.
   2. Select Add Automatic Address Translation Rules.
   3. In Translation method, select Hide.
   4. Select Hide behind Gateway.
4. Click OK and then install the policy.

Sample Deployment (Manual Rules for Port Translation)

The goal for this sample configuration is to let external computers access a web and mail server in a DMZ network from one IP address. Configure Hide NAT for the DMZ network object and create manual NAT rules for the servers.

To configure NAT for the DMZ servers:

1. Enable automatic Hide NAT for the DMZ network.
   1. Double-click the Alaska_DMZ object and select NAT.
   2. Select Add Automatic Address Translation Rules.
   3. In Translation method, select Hide.
   4. Select Hide behind Gateway.
   5. Click OK.
2. Create a manual NAT rule that translates HTTP traffic from the Security Gateway to the web server.
   1. In the Firewall tab, select NAT.
   2. Add a rule below the automatic rules.
   3. Right-click the cell and select Add Object to configure these settings:
      • Original Destination - Alaska_GW
      • Original Service - HTTP
      • Translated Destination - Alaska_DMZ_Web
3. Create a manual NAT rule that translates SMTP traffic from the Security Gateway to the mail server.
   1. Add a rule below the automatic rules.
   2. Right-click the cell and select Add Object to configure these settings:
      • Original Destination - Alaska_GW
      • Original Service - SMTP
      • Translated Destination - Alaska_DMZ_Web
4. Create a rule in the Firewall Rule Base that allows traffic to the servers.
   1. In the Firewall tab, select Policy.
   2. Add a rule to the Rule Base.
   3. Right-click the cell and select Add Object to configure these settings:
      • Destination - Alaska_DMZ
      • Service - HTTP, SMTP
      • Action - Allow
5. Install the policy.

NAT Rule Base for Manual Rules for Port Translation Sample Deployment

Advanced NAT Settings

Deployment Configurations

This section discusses how to configure NAT in some network deployments.

Automatic and Proxy ARP

Giving a machine in the internal network an external IP address using NAT makes that machine appear to the Internet to be on the external network, or the Internet side of the firewall. When NAT is configured automatically, the Security Gateway replies on behalf of translated network objects to ARP requests from the Internet router for the address of the internal machine.

If you are using manual rules, you must configure proxy ARPs to associate the translated IP address with the MAC address of the Security Gateway interface that is on the same network as the translated addresses.

For more about configuring Proxy ARP for IPv4 Manual NAT, see sk30197.

For more about configuring Proxy NDP for IPv6 Manual NAT, see sk91905.

NAT and Anti-Spoofing

NAT is performed after Anti-Spoofing checks, which are performed only on the source IP address of the packet. This means that spoofing protection is configured on the interfaces of the Security Gateway in the same way as NAT.

Disabling NAT in a VPN Tunnel

When communicating within a VPN, it is normally not necessary to perform NAT. You can disable NAT in a VPN tunnel with a single click in the VPN community object. Disabling NAT in a VPN tunnel by defining a NAT rule slows down the performance of the VPN.

Connecting Translated Objects on Different Interfaces

The following sections describe how to allow connections in both directions between statically translated objects (nodes, networks or address ranges) on different Security Gateway interfaces.

If NAT is defined through the network object (as opposed to using Manual NAT Rules), then you must ensure that bidirectional NAT is enabled.

Internal Communication with Overlapping Addresses

If two internal networks have overlapping (or partially overlapping) IP addresses, Security Gateway enables:

• Communication between the overlapping internal networks.
• Communication between the overlapping internal networks and the outside world.
• Enforcement of a different security policy for each overlapping internal network.

Network Configuration

For example, assume both Network A and Network B share the same address space (192.168.1.0/24), therefore standard NAT cannot be used to enable communication between the two networks. Instead, overlapping NAT must be performed on a per interface basis.

Users in Network A who want to communicate with users in Network B must use the 192.168.30.0/24 network as a destination. Users in Network B who want to communicate with users in Network A must use the 192.168.20.0/24 network as a destination.

The Security Gateway translates the IP addresses in the following way for each individual interface:

Interface A

• Inbound source IP addresses are translated to the virtual network 192.168.20.0/24.
• Outbound destination IP addresses are translated to the network 192.168.1.0/24.

Interface B

• Inbound source IP addresses are translated to the network 192.168.30.0/24.
• Outbound destination IP addresses are translated to the network 192.168.1.0/24.

Interface C

Overlapping NAT is not configured for this interface. Instead, use NAT Hide in the normal way (not on a per-interface basis) to hide source addresses behind the interface's IP address (192.168.4.1).

Communication Examples

This section describes how to enable communication between internal networks, and between an internal network and the Internet

Communication Between Internal Networks

If user A, at IP address 192.168.1.10 in Network A, wants to connect to user B, at IP address 192.168.1.10 (the same IP address) in Network B, user A opens a connection to the IP address 192.168.30.10.

Communication Between Internal Networks

Communication Between an Internal Network and the Internet

If user A, at IP address 192.168.1.10 in network A, connects to IP address 10.10.10.10 on the Internet.

Communication Between an Internal Network and the Internet

Routing Considerations

To allow routing from Network A to Network B, routing must be configured on the Firewall.

These sections contain sample routing commands for Windows and Linux operating systems (for other operating systems, use the equivalent commands).

On Windows

• route add 192.168.30.0 mask 255.255.255.0 192.168.3.2
• route add 192.168.20.0 mask 255.255.255.0 192.168.2.2

On Linux

• route add -net 192.168.30.0/24 gw 192.168.3.2
• route add -net 192.168.20.0/24 gw 192.168.2.2

Object Database Configuration

To activate the overlapping NAT feature, use the dbedit database editor GUI (or command line utility). In the sample network configuration, the per interface values for interface A and interface B are set in the following way:

Sample Network Configuration: Interface Configuration

Security Management Behind NAT

The Security Management Server sometimes uses a private IP address (as listed in RFC 1918) or some other non-routable IP address, because of the lack of public IP addresses.

NAT (Static or Hide) for the Security Management Server IP address can be configured in one click, while still allowing connectivity with managed gateways. All gateways can be controlled from the Security Management Server, and logs can be sent to the Security Management Server. NAT can also be configured for a Management High Availability server and a Domain Log Server.

In a typical Security Management Behind NAT scenario: the Security Management Server is in a network on which Network Address Translation is performed (the "NATed network"). The Security Management Server can control Security Gateways inside the NATed network, on the border between the NATed network and the outside world and outside the NATed network.

In ordinary Hide NAT configurations, connections cannot be established from the external side the NAT A Security Gateway. However, when using Hide NAT on the Security Management Server, gateways can send logs to the Security Management Server.

When using the Security Management behind NAT feature, the remote gateway automatically selects the Security Management address to be addressed and simultaneously applies NAT considerations.

To enable NAT for the Security Management Server:

• From the NAT page of the Security Management Server object, define NAT and select Apply for A Security Gateway control connections.

Non-Corresponding Gateway Addresses

Sometimes the gateway contacts the Security Management Server with an address that does not correspond to the remote gateway's deployment, for example:

• When the gateway's automatic selection does not conform with the routing of the gateway's deployment. In this case, define the masters and loggers manually, to allow the remote gateway to contact the Security Management Server using the required address. When an inbound connection from a managed gateway enters the Security Gateway, port translation is used to translate the hide address to the real IP address of the Security Management Server.

To define masters and loggers, select Use local definitions for Log Servers and Use local definitions for Masters and specify the correct IP addresses on the gateway.

This solution encompasses different scenarios:

• The remote gateway addresses the NATed IP when you want it to address the real IP.
• The remote gateway addresses the real IP when you want it to address the NATed IP. In this case, specify the SIC name of the Security Management Server in the masters file.

Notes:

• Only one object can be defined with these settings, unless the second object is defined as a Secondary Security Management Server or as a Domain Log Server.
• Ensure that you properly define the Topology settings on all gateways. All workarounds required for previous versions still function with no changes in their behavior.

Configuring the Security Management Server Object

To configure the Security Management Server object:

1. From the NAT page on the Primary_Security_Management object, select either Static NAT or Hide NAT. If using Hide NAT, select Hide behind IP Address, for example, 192.168.55.1. Do not select Hide behind Gateway (address 0.0.0.0).
2. Select Install on Gateway to protect the NATed objects or network. Do not select All.
3. Select Apply for Security Gateway control connections.

Configuring the Security Gateway Object

To configure the Security Gateway object:

1. On the Security Gateway Topology page, define the Interface.
2. In the General tab in the Interface Properties window, define the IP Address and the Net Mask.
3. In the Topology tab of the Interface Properties window, select Network defined by the interface IP and Net Mask.

IP Pool NAT

An IP Pool is a range of IP addresses (an address range, a network or a group of one of these objects) that is routable to the gateway. IP Pool NAT ensures proper routing for encrypted connections for the following two connection scenarios:

• SecuRemote client / SecureClient to MEP (Multiple Entry Point) gateways
• Gateway to MEP gateways

When a connection is opened from a SecuRemote client / SecureClient or a client behind a gateway to a server behind the MEP Gateways, the packets are routed through one of the MEP gateways. Return packets in the connection must be routed back through the same gateway in order to maintain the connection. To ensure that this occurs, each of the MEP gateways maintains a pool of IP addresses that are routable to the gateway. When a connection is opened to a server, the gateway substitutes an IP address from the IP pool for the source IP address. Reply packets from the server return to the gateway, which restores the original source IP address and forwards the packets to the source.

The pool of IP addresses is configured in the IP Pool page of the gateway object.

IP Pool Per Interface

You can define a separate IP address pool on one or more of the gateway interfaces instead of defining a single pool of IPs for the gateway.

Defining an IP pool per interface solves routing issues that occur when the gateway has more than two interfaces. Sometimes it is necessary that reply packets return to the gateway through the same gateway interface. The following illustration shows one of the MEP Gateways in a SecuRemote client / SecureClient to MEP (Multiple Entry Point) gateway deployment.

If a remote client opens a connection to the internal network, reply packets from hosts inside the internal networks are routed to the correct gateway interface through the use of static IP pool NAT addresses.

The remote VPN client's IP address is NATed to an address in the IP pool on one of the gateway interfaces. The addresses in the IP pool can be routed only through that gateway interface so that all reply packets from the target host are returned only to that interface. Therefore, it is important that the IP NAT pools of the interfaces do not overlap.

When the packet returns to the gateway interface, the gateway restores the remote peer's source IP address.

The routing tables on the routers that lie behind the gateway must be edited so that addresses from a gateway IP pool are returned to the correct gateway interface.

Switching between IP Pool NAT per gateway and IP Pool NAT per interface and then installing the security policy deletes all IP Pool allocation and all NATed connections.

NAT Priorities

IP Pool NAT can be used both for encrypted (VPN) and non-encrypted (decrypted by the gateway) connections.

For non-encrypted connections, IP Pool NAT has the following advantages over Hide NAT:

• New back connections (for example, X11) can be opened to the NATed host.
• User-to-IP server mapping of protocols that allow one connection per IP can work with a number of hosts instead of only one host.
• IPsec, GRE and IGMP protocols can be NATed using IP Pool NAT (and Static NAT). Hide NAT works only with TCP, UDP and ICMP protocols.

Because of these advantages, you can specify that IP Pool NAT has priority over Hide NAT, if both match the same connection. Hide NAT is only applied if the IP pool is used up.

The order of NAT priorities are:

1. Static NAT
2. IP Pool NAT
3. Hide NAT

Since Static NAT has all of the advantages of IP Pool NAT and more, it has a higher priority than the other NAT methods.

Reusing IP Pool Addresses For Different Destinations

IP Pool addresses can be reused for different destinations, which makes more efficient use of the addresses in the pool. If a pool contains N addresses, then any number of clients can be assigned an IP from the pool as long as there are no more than N clients per server.

Using IP Pool allocation per destination, two different clients can receive the same IP from the pool as long as they communicate with different servers. When reusing addresses from the IP Pool, back connections are supported from the original server only. This means that connections back to the client can be opened only from the specific server to which the connection was opened.

The default Do not reuse IP Pool behavior means that each IP address in the IP Pool is used once (connections 1 and 2 in the following illustration). In this mode, if an IP pool contains 20 addresses, up to 20 different clients can be NATed and back connections can be opened from any source to the client.

Switching between Reuse and Do not reuse modes and then installing the security policy, deletes all IP Pool allocations and all NATed connections.

Configuring IP Pool NAT

To configure IP Pool NAT:

1. In the Global Properties > NAT page, select Enable IP Pool NAT and the required tracking options.
2. In the gateway General Properties page, ensure the gateway version is specified correctly.
3. For each gateway or gateway interface, create a network object that represents its IP pool NAT addresses. The IP pool can be a network, group, or address range. For example, for an address range, do the following:
   1. In the network objects tree, right-click Network Objects branch and select New > Address Range The Address Range Properties window opens.
   2. In the General tab, enter the first and last IP of the address range.
   3. Click OK. The new address range appears in the Address Ranges branch of the network objects tree.
4. Select the gateway object, access the Gateway Properties window and select NAT > IP Pool NAT.
5. In the IP Pool NAT page, select one of the following:
   1. Allocate IP Addresses from and then select the address range you created to configure IP Pool NAT for the whole gateway, or
   2. Define IP Pool addresses on gateway interfaces to configure IP Pool NAT per interface.
6. If required, select one or more of the following options:
   1. Use IP Pool NAT for VPN client connections
   2. Use IP Pool NAT for gateway to gateway connections
   3. Prefer IP Pool NAT over Hide NAT to specify that IP Pool NAT has priority over Hide NAT, if both match the same connection. Hide NAT is only applied if the IP pool is used up.
7. Click Advanced.
   1. Return unused addresses to IP Pool after: Addresses in the pool are reserved for t60 minutes (default), even if the user logs off. If the user disconnects from their ISP and then redials and reconnects, there will be two Pool NAT addresses in use for the user until the first address from the IP Pool times out. If users regularly lose their ISP connections, you may want to decrease the time-out to prevent the IP Pool from being depleted.
   2. Reuse IP addresses from the pool for different destinations: This is a good option unless you need to allow back connections to be opened to clients from any source, rather than just from the specific server to which the client originally opened the connection.
8. Click OK.
9. Edit the routing table of each internal router so that packets with an IP address assigned from the NAT pool are routed to the appropriate gateway or, if using IP Pools per interface, the appropriate gateway interface.

IP Pool NAT for Clusters

IP Pools for gateway clusters are configured in two places in SmartDashboard:

• In the gateway Cluster object NAT > IP Pool NAT page, select the connection scenario.
• In the Cluster member object IP Pool NAT page, define the IP Pool on the cluster member. A separate IP pool must be configured for each cluster member. It is not possible to define a separate IP Pool for each cluster member interface.