Support Center > Search Results > SecureKnowledge Details
IP Pool NAT for Clear (Non-VPN) Connections Technical Level
Solution

This solution describes a feature, designed to enable dynamic NAT (IP Pool NAT) for connections that are not encrypted/decrypted by the Security Gateway (for example, PPTP Clients or IPSec). 


IP Pool NAT enables N hosts to be NATed using M IP addresses (N:M, where N > M), unlike Static NAT which translates N:N IP addresses (from subnet to subnet), or Hide NAT which translates N:1 and does not support incoming connections.

IP Pool NAT has the following advantages over Hide NAT and Static NAT:

  • Over Static NAT: Does not require an IP for every NATTED host.
  • Over Hide NAT: Provides a unique IP per NATTED host.
  • Over Hide NAT: Allows back-connections: incoming connections to the NAT address of the host.



Example scenarios for using IP Pool NAT as a solution:

  • Protocols that are not supported by Hide NAT (meaning non-TCP/UDP/ICMP), such as IPSec.
  • Servers and protocols that allow a single user per IP address.
  • Protocols that require support of back-connections, such as X-11.



Configuration

For configuration of the IP addresses of the pool, see the notes below.
For activation of the IP Pool NAT, the clients to be NATed and the servers and services to which NAT is to be applied must be defined in INSPECT via user.def file (see sk98239 how to edit this file). 

The INSPECT tables should be defined in the user.def file as follows:

  1. The Services tables.

    These tables should have the following format, and any name:
    ip_pool_server_services = { <IP Proto, Low Port, High Port>, ... };

  2. The Server tables.

    Any valid name can be used for these tables, but they must be defined before the Clients table:
    ip_pool_server_ips = {<First IP, Last IP ; Name of Services table - Optional>, ..... };

  3. A single table holding IP address ranges for the clients. This table must have the following name and structure:
    ip_pool_client_ips = {<First IP, Last IP ; Name of Servers table>,             
    <First IP, Last IP ; Name of Servers table>,
    ...
    <First IP, Last IP ; Name of Servers table> };


    To use a single IP address, enter it as First IP and Last IP (and not <IP> or <IP ; ...>).
    To specify any IP address, enter 0.0.0.0 as First IP and 255.255.255.255 as Last IP.



Examples:

  • In the most simple scenario:

  • #ifndef IPV6_FLAVOR
    ip_pool_server_ips = { <120.120.120.99, 120.120.120.99> };
    ip_pool_client_ips = { <212.180.180.0, 212.180.180.255 ; ip_pool_server_ips>,
    <213.190.190.0, 213.190.190.255 ; ip_pool_server_ips> };
    #endif


    This will result in the dynamic NAT of IP addresses 212.180.180.# or 213.190.190.# connecting to server 120.120.120.99.

  • In a different scenario where there are two PPTP servers and different client networks for the each server:

    #ifndef IPV6_FLAVOR
    ip_pool_server_1 = { <120.120.120.99, 120.120.120.99> };
    ip_pool_server_2 = { <10.10.10.152, 10.10.10.152> };
    ip_pool_client_ips = { <212.180.180.0, 212.180.180.255 ; ip_pool_server_1>,
    <213.190.190.0, 213.190.190.255; ip_pool_server_2> };
    #endif


  • To allow ALL clients to NAT to a specific server:

    #ifndef IPV6_FLAVOR
    ip_pool_server = { <120.120.120.99, 120.120.120.99> };
    ip_pool_client_ips = { <0.0.0.0, 255.255.255.255 ; ip_pool_server> };
    #endif


  • To allow dynamic NAT of a client network to any destination:

    #ifndef IPV6_FLAVOR
    ip_pool_all_servers = { <0.0.0.0, 255.255.255.255> };
    ip_pool_client_ips = { <212.180.180.0, 212.180.180.255 ; ip_pool_all_servers> };
    #endif


  • Example with Services:

    To allow IP Pool NAT for internal clients (suppose 10.#.#.# network) and any server, for services IPSec (IPProto 50 + IKE) and PPTP (IPProto 47-GRE + PPTP Control-1723):

    #ifndef IPV6_FLAVOR
    ip_pool_services = { <50, 0, 0>, <17, 500, 500>, <6, 1723, 1723>, <47, 0, 0> };
    ip_pool_server_ips = { <0.0.0.0, 255.255.255.255 ; ip_pool_services> };
    ip_pool_client_ips = { <10.0.0.0, 10.255.255.255 ; ip_pool_server_ips> };
    #endif


  • Example with multiple servers:

    Configure ip pool nat only to servers - 192.168.61.10, 192.168.61.20, 192.168.61.30
    From clients 192.168.70.21-192.168.70.28

    #ifndef IPV6_FLAVOR
    ip_pool_server_ips = {<192.168.61.10, 192.168.61.10>, <192.168.61.20, 192.168.61.20>, <192.168.61.30, 192.168.61.30>};
    ip_pool_client_ips = {<192.168.70.21, 192.168.70.28; ip_pool_server_ips>};
    #endi
    f

 

Notes

  1. IP Pool must be defined on the Security Gateway in following ways (the Security Policy must be installed afterwards): 

    • In SmartConsole:

      • Select Global Properties -> NAT -> Enable IP Pool NAT

      • Define a new Address Range or Network (or Group) for the IP Pool.
      • Select the Security gateway object -> NAT -> IP Pools, and associate the pool object to the gateway (or to gateway interfaces, depending on the configuration).



        What does the "Prefer IP Pool NAT over Hide NAT" option mean:

        If connection matches a Hide NAT rule in the NAT rulebase and also matches the user.def configuration, the security gateway will do the IP Pool NAT and not the Hde NAT in the NAT rulebase.

        Static NAT rule will overide IP Pool NAT:
        If connection matches a static NAT rule on the translated source, and the connection also matches the user.def configuration, the security gateway will perform the Static NAT and not the IP Pool NAT.
        Original in the translated source is consider as static NAT rule on the translated source:



        What happens when we have IP Pool exhaustion (all IP addresses are occupied by active connections): In this case, the Security gateway works according to the regular NAT rulebase. Set the fwx_ippool_exhausted_should_drop_conn kernel parameter to 1 (see sk26202). This will drop the connection when reaching pool exhaustion.

    • In the INSPECT Table:

      • Directly define the IP addresses of the pool in a table in the user.def file, in the following format:
        all@gateway xlate_pool = { <First IP, Last IP>, <First IP, Last IP>, ... };
        where gateway is the name of the Security Gateway.
        For clusters, add a table for each cluster member.
      • For the xlate_pool definition, do not use both methods at the same time. Doing so will result an an INSPECT compilation error.

  2. The ip_pool_client_ips and ip_pool_server_ips inspect tables must be configured in the user.def file, regardless of which configuration method was used to define the ippool table, i.e., SmartDashboard or INSPECT table. In addition, the ip_pool_client_ips table is a reserved name that must be used, while the ip_pool_server_ips table's name can be changed (see examples section).

  3. After an IP address is allocated for a client, every connection from that client will be NATed in the same way (regardless of destination or service) as long as the client continues to use the allocated IP address.

  4. IP addresses from the pool should be routed to the Security Gateway (like Static NAT), either by manual ARP or by manual routing.

  5. If there is Static NAT on the servers, the addresses of the servers in the tables should be their real IP addresses (their IP addresses from their view), as it should be when there is no NAT.
    Only if the global attribute 'NAT -> Translate destination on client side' (manual or automatic, depending on the defined server NAT) is off, the server address should be its NAT address.

  6. INSPECT Tables: ip_pool_client_ips is a fixed name and should always be used (unlike the server tables). Servers tables should be defined before the Clients table. These tables are defined on the Security Management server, therefore they are defined in all Security Gateways.

  7. IP Pool NAT for Clear Connections is NOT supported for 41000/61000 Scalable Platforms devices.


Also see
the Security Management R80.20 Administration Guide

Give us Feedback
Please rate this document
[1=Worst,5=Best]
Comment