Dynamic SNAT

Dynamic SNAT maps the private IP addresses to the first available public address from a pool of addresses. In the FortiGate firewall, this can be done by using IP pools. IP pools is a mechanism that allows sessions leaving the FortiGate firewall to use NAT. An IP pool defines a single IP address or a range of IP addresses to be used as the source address for the duration of the session. These assigned addresses are used instead of the IP address assigned to that FortiGate interface.

IP pool types

FortiGate uses four types of IPv4 IP pools. This topic focuses on some of the differences between them.

Overload

This type of IP pool is similar to static SNAT mode. We need to define an external IP range that contains one or more IP addresses. When there is only one IP address it is almost the same as static SNAT, the outgoing interface address is used. When it contains multiple IP addresses, it is equivalent to an extended mode of static SNAT.

For instance, if we define an overload type IP pool with two external IP addresses (172.16.200.1—172.16.200.2), since there are 60,416 available port numbers per IP, this IP pool can handle 60,416*2 internal IP addresses to the same service, where a service is defined by a specific protocol, destination IP address, and destination port.

The mapped IP address can be calculated from the source IP address. The index number of the address in the pool is the remainder of the source IP address, in decimal, divided by the number addresses in the pool.

To calculate the decimal value of the source IP address, either use an online calculator, or use the following equation: a.b.c.d = a * (256)3 + b * (256)2 + c * (256) + d For example: 192.168.0.1 = 192 * (256)3 + 168 * (256)2 + 0 * (256) + 1 = 3232235521

If there is one IP pool, where:

• P₁ = the first address in the IP pool
• R₁ = the number of IP addresses in the IP pool
• X = the source IP address as a decimal number
• Y = the mapped IP address

Then the equation to determine the mapped address is:

Y = P₁ + X mod R₁

For example:

IP pool	Source IP address
172.26.73.20 to 172.26.73.90	192.168.1.200

1. Convert the source IP address to a decimal number:

   192 * (256)³ + 168 * (256)² + 1 * (256) + 200 = 3232235976

2. Determine the number of IP addresses in the pool:

   172.26.73.90 - 172.26.73.20 = 71

3. Find the remainder of the source IP address divided by the number of addresses in the pool:

   3232235976 mod 71 = 26

4. Add the remainder to the first IP address in the pool:

   172.26.73.20 + 26 = 172.26.73.46

   So, the mapped IP address is 172.26.73.46.

If there are multiple IP pools, the calculation is similar to when there is only one pool.

If there are two IP pools, where:

• P₁ = the first address in the first IP pool
• P₂ = the first address in the second IP pool
• R₁ = the number of IP addresses in the first IP pool
• R₂ = the number of IP addresses in the second IP pool
• X = the source IP address as a decimal number
• Y = the mapped IP address

Then the equations to determine the mapped address are:

If X mod (R₁ + R₂) >= R₁, then Y = P₂ + X mod R₂

If X mod (R₁ + R₂) < R₁, then Y = P₁ + X mod R₁

For example:

IP pools	Source IP address
pool01: 172.26.73.20 to 172.26.73.90	192.168.1.200
pool02: 172.26.75.50 to 172.26.75.150

1. Convert the source IP address to a decimal number:

   192 * (256)³ + 168 * (256)² + 1 * (256) + 200 = 3232235976

2. Determine the total number of IP addresses in the pools:

   (172.26.73.90 - 172.26.73.20) + (172.26.75.50 - 172.26.75.150) = 71 + 101 = 172

3. Find the remainder of the source IP address divided by the number of addresses in the pools:

   3232235976 mod 172 = 108

4. The remainder is greater than the number of addresses in pool01, so the address is selected from pool02 and the remainder is recalculated based only on pool02:

   3232235976 mod 101 = 40

5. Add the new remainder to the first IP address in pool02:

   172.26.75.50 + 40 = 172.26.75.90

   So, the mapped IP address is 172.26.75.90.

One-to-one

This type of IP pool means that the internal IP address and the external (translated) IP address match one-to-one. The port address translation (PAT) is disabled when using this type of IP pool. For example, if we define a one-to-one type IP pool with two external IP addresses (172.16.200.1 - 172.16.200.2), this IP pool only can handle two internal IP addresses.

Fixed port range

For the overload and one-to-one IP pool types, we do not need to define the internal IP range. For the fixed port range type of IP pool, we can define both internal IP range and external IP range. Since each external IP address and the number of available port numbers is a specific number, if the number of internal IP addresses is also determined, we can calculate the port range for each address translation combination. So we call this type fixed port range. This type of IP pool is a type of port address translation (PAT).

For instance, if we define one external IP address (172.16.200.1) and ten internal IP addresses (10.1.100.1-10.1.100.10), we have translation IP+Port combination like following table:

Port block allocation

This type of IP pool is also a type of port address translation (PAT). It gives users a more flexible way to control the way external IPs and ports are allocated. Users need to define Block Size/Block Per User and external IP range. Block Size means how many ports each Block contains. Block per User means how many blocks each user (internal IP) can use.

The following is a simple example:

• External IP Range: 172.16.200.1—172.16.200.1
• Block Size: 128
• Block Per User: 8

Result:

• Total-PBAs: 472 (60416/128)
• Maximum ports can be used per User (Internal IP Address): 1024 (128*8)
• How many Internal IP can be handled: 59 (60416/1024 or 472/8)

Sample configuration

To configure overload IP pool in the GUI:

1. In Policy & Objects > IP Pools, click Create New.
2. Select IPv4 Pool and then select Overload.

   

To configure overload IP pool in the CLI:

config firewall ippool
    edit "Overload-ippool"
        set startip 172.16.200.1
        set endip 172.16.200.1
    next
end

To configure one-to-one IP pool using the GUI:

1. In Policy & Objects > IP Pools, click Create New.
2. Select IPv4 Pool and then select One-to-One.

   

To configure one-to-one IP pool in the CLI:

config firewall ippool
    edit "One-to-One-ippool"
        set type one-to-one
        set startip 172.16.200.1
        set endip 172.16.200.2
    next
end

To configure fixed port range IP pool in the GUI:

1. In Policy & Objects > IP Pools, click Create New.
2. Select IPv4 Pool and then select Fixed Port Range.

   

To configure fixed port range IP pool in the CLI:

config firewall ippool
    edit "FPR-ippool"
        set type fixed-port-range
        set startip 172.16.200.1
        set endip 172.16.200.1
        set source-startip 10.1.100.1
        set source-endip 10.1.100.10
   next
end

To configure port block allocation IP pool in the GUI:

1. In Policy & Objects > IP Pools, click Create New.
2. Select IPv4 Pool and then select Port Block Allocation.

   

To configure port block allocation IP pool in the CLI:

config firewall ippool
    edit PBA-ippool
        set type port-block-allocation
        set startip 172.16.200.1
        set endip 172.16.200.1
        set block-size 128
        set num-blocks-per-user 8
    next
end

IP pools and blackhole route configuration

In FortiOS 6.4.8 and below, all IP addresses used as IP pools and VIPs are considered local IP addresses if responding to ARP requests on these external IP addresses is enabled (set arp-reply enable, by default). In this case, the FortiGate is considered a destination for those IP addresses and can receive reply traffic at the application layer successfully.

In FortiOS 6.4.9 and above, all IP addresses used as IP pools and VIPs are no longer considered local IP addresses if responding to ARP requests on these external IP addresses is enabled (set arp-reply enable, by default). In this case, the FortiGate is not considered a destination for those IP addresses and cannot receive reply traffic at the application layer without special handling.

• This behavior affects FortiOS features in the application layer that use an IP pool as its source IP pool including SSL VPN web mode, explicit web proxy, and the Phase 1 local gateway of an interface mode IPsec VPN.

• The FortiGate will not receive reply traffic at the application layer and the corresponding the FortiOS feature will not work as desired.

• Configuring an IP pool as the source NAT IP address in a regular firewall policy works as before.

For explicit proxy setups, one set of these steps is sufficient to avoid the issue:

• Delete the blackhole route and ensure another route is defined that matches traffic for the IP pool reply traffic, or

• Keep the blackhole route and if the IP pool consists of a single IP address, configure this IP address as a secondary IP address on an outgoing FortiGate interface. In this case, the secondary IP address is considered a local address, which allows the FortiGate to be considered a destination that can receive IP pool reply traffic.

For SSL VPN web mode setups, the following steps are sufficient to avoid the issue:

• Configure the first IP address in the IP pool as a secondary IP address on the outgoing FortiGate interface defined in the SSL VPN web mode firewall policy. In this case, the secondary IP address is considered a local address, which allows the FortiGate to be considered a destination that can receive IP pool reply traffic.

For a given VDOM, if different SSL VPN web mode destinations need to go out from different interfaces, then each destination would need to have a different IP pool specified in the corresponding firewall policy.

For interface mode IPsec VPN setups with local gateway configured, the following steps are sufficient to avoid the issue:

• Keep the interface mode IPsec VPN Phase 1 local gateway configured as the IP pool and if the IP pool consists of a single IP address, configure this IP address as a secondary IP address on an outgoing FortiGate interface. In this case, the secondary IP address is considered a local address which allows the FortiGate to be considered a destination that can receive IP pool reply traffic.

Explicit proxy configuration example

In this explicit proxy configuration example, an IP pool with a single IP address is configured with set arp-reply enable configured by default along with a blackhole route that matches the reply traffic destined to the IP pool.

config firewall ippool
    edit “ippool1”
        set startip 1.1.1.1
        set endip 1.1.1.1
    next
end
config router static
    edit 1
        set dst 1.1.1.0 255.255.255.0
        set blackhole enable
    next
end

Suppose the explicit web proxy on the FortiGate has already been enabled and configured using steps described in Explicit web proxy. In the corresponding proxy policy, configure the IP pool ippool1 as the source IP address.

config firewall proxy-policy
    edit 1
        set name "allow_traffic"
        set proxy explicit-web
        set dstintf "port1"
        set srcaddr "all"
        set poolname "ippool1"
        set dstaddr "all"
        set service "webproxy"
        set action accept
        set schedule "always"
    next
end

Because the blackhole route matches the reply traffic to the IP pool and drops it, then reply traffic cannot reach the explicit web proxy on the FortiGate.

To resolve the issue caused by the blackhole route configuration, you can consider configuring one of the following settings:

• Delete the blackhole route and ensure another route is defined that matches traffic for the IP pool reply traffic.

  In the example below, a default route for outgoing interface port1 is defined which matches the IP pool reply traffic.

  config router static
      delete 1
      edit 2
          set dst 0.0.0.0 0.0.0.0
          set device port1
      next
  end

• Keep the blackhole route and if the IP pool consists of a single IP address as in this example, configure this IP address as a secondary IP address on an outgoing FortiGate interface.

  In the example below, the outgoing interface port1 has a secondary IP of 1.1.1.1/24 defined on it.

  config system interface
      edit DMZ
          set secondary-IP enable
          config secondaryip
              edit 1
                  set ip 1.1.1.1 255.255.255.0
              next
          end
      next
  end

SSL VPN web mode configuration example

In this SSL VPN web mode configuration example, an IP pool with a single IP address is configured with set arp-reply enable configured by default along with a blackhole route that matches the reply traffic destined to the IP pool.

config firewall ippool
    edit “ippool1”
        set startip 1.1.1.1
        set endip 1.1.1.1
    next
end
config router static
    edit 1
        set dst 1.1.1.0 255.255.255.0
        set blackhole enable
    next
end

Suppose SSL VPN web mode has already been configured on the FortiGate using steps described in SSL VPN web mode for remote user. In the corresponding SSL VPN web mode firewall policy, configure the IP pool ippool1 as the source IP address and dynamic SNAT pool.

config firewall policy
    edit 1
        set name "SSL_Web_SFTP"
        set srcintf "ssl.root"
        set dstintf "DMZ"
        set action accept
        set srcaddr "all"
        set dstaddr "SFTP_SERVER"
        set schedule "always"
        set service "ALL"
        set logtraffic all
        set nat enable
        set fixedport enable
        set ippool enable
        set poolname "SSL_Web_SFTP"
        set groups "SSL_VPN_WEB_SFTP"
    next
end

Because the blackhole route matches the reply traffic to the IP pool and drops it, then reply traffic from the secure FTP server connected to the FortiGate DMZ interface cannot reach the FortiGate SSL VPN web portal.

To resolve the issue caused by the blackhole route configuration, configure the following settings:

• Keep the blackhole route. If the IP pool consists of a single IP address as in this example, configure this IP address as a secondary IP address on the outgoing FortiGate interface defined in the SSL VPN web mode firewall policy.

  For a given VDOM, if different SSL VPN web mode destinations need to go out from different interfaces, then each destination would need to have a different IP pool specified in the corresponding firewall policy.

  In the example below, the DMZ interface is the outgoing interface used to reach the secure FTP server that requires a secondary IP of 1.1.1.1/24 to be defined on it.

  config system interface
      edit DMZ
          set secondary-IP enable
          config secondaryip
              edit 1
                  set ip 1.1.1.1 255.255.255.0
              next
          end
      next
  end

Interface mode IPsec VPN with local gateway configuration example

In this interface mode IPsec VPN with local gateway configuration example, an IP pool with a single IP address is configured with set arp-reply enable configured by default and this IP pool is specified with the local gateway setting.

config firewall ippool
    edit “ippool2”
        set startip 1.2.3.4
        set endip 1.2.3.4
    next
end
config vpn ipsec phase1-interface
    edit “VPN1”
        ...
        set local-gw 1.2.3.4
        ...
    next
end

Since the local gateway is configured with the IP address that matches an IP pool, this IP address is not considered local. Then, the IPsec VPN Phase 1 negotiation will fail and the IPsec tunnel will not come up as expected.

To resolve the issue caused by the IP pool not being considered a local address for the interface mode IPsec VPN local gateway setting, configure the following settings:

• Keep the interface mode IPsec VPN Phase 1 local gateway configured as the IP pool and if the IP pool consists of a single IP address, configure this IP address as a secondary IP address on the outgoing FortiGate interface used with the interface mode IPsec VPN tunnel. In this case, the secondary IP address is considered a local address, which allows the FortiGate to be considered a destination that can receive IP pool reply traffic.

In the example below, the outgoing interface port2 is the physical interface used for the interface mode IPsec VPN tunnel. Therefore, define a secondary IP of 1.2.3.4/24 on this interface to ensure that IPsec Phase 1 negotiation succeeds and allows the IPsec tunnel to come up.

config system interface
    edit port2
        set secondary-IP enable
        config secondaryip
            edit 1
                set ip 1.2.3.4 255.255.255.0
            next
        end
    next
end