Description
This article describes the ippool behavior and changes in default operation for different firmware versions.
Solution
'IP pool' is a mechanism that allows sessions leaving the FortiGate firewall to use NAT to a specific address, other than the IP assigned on the interface.
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.
When enabled in a particular policy, the ippool addresses will be used instead of the IP address assigned to that FortiGate interface.
In most FortiOS versions, once configured, even if it is never explicitly used/referenced in a firewall policy, FortiGate considers them as local addresses, and will not forward the traffic according to the routing table.
Starting with v6.4.9 and 7.0.1, this default behavior is changed (Check Technical Tip: IP pool and virtual IP behavior changes in FortiOS 6.4, 7.0, 7.2, and 7.4 for other FortiOS versions)
Now, once an ippool is defined and referenced in a policy, the source-nat is performed as expected, but the FortiGate does not consider them local IPs, meaning there will be no arp-reply for them (even if arp-reply is enabled in ippool configuration). This most certainly can cause communication to fail.
This will affect IPsec tunnels, for example, that have configured IPpools as local gateway using the command set local-gw.
The fix is to add these IPs as secondary IPs on the corresponding interface.
(How to set a secondary IP on a FortiGate interface)
If the next hop device IP, or destination IP that shall be allowed by firewall policy, is mistakenly configured as IP Pool, traffic will be terminated in FortiGate.
# id=20085 trace_id=381 func=print_pkt_detail line=5375 msg="vd-root received a packet(proto=6, 10.116.1.177:60192->52.52.208.2:443) from port2. flag [S], seq 3608362859, ack 0, win 65340"
id=20085 trace_id=381 func=init_ip_session_common line=5534 msg="allocate a new session-00056c55"
id=20085 trace_id=381 func=vf_ip_route_input_common line=2574 msg="find a route: flag=04000000 gw-10.47.3.254 via port1"
id=20085 trace_id=381 func=fw_forward_handler line=743 msg="Allowed by Policy-1: SNAT"
id=20085 trace_id=381 func=__ip_session_run_tuple line=3282 msg="SNAT 10.116.1.177->10.47.1.85:60192"
A Snippet of debug flow above shows host 10.116.1.177 was trying to accessing to 52.52.208.2 on port 443.
The access has been allowed by firewall policyid#1 and host 10.116.1.177 gets translated to egress interface IP 10.47.1.85.
When 52.52.208.2 is being configured as IP Pool, and not being used in any firewall policy.
# Alza-kvm55 (root) # diag firewall iplist list
list iplist info:(vf=root)
one IPlist entry:
dev=0 devname= type=1 used=1 ip range=52.52.208.2-52.52.208.2
Access to 52.52.208.2 will be terminated in FortiGate.
# id=20085 trace_id=581 func=print_pkt_detail line=5375 msg="vd-root received a packet(proto=6, 10.116.1.177:60325->52.52.208.2:443) from port2. flag [S], seq 1295495056, ack 0, win 65340"
id=20085 trace_id=581 func=init_ip_session_common line=5534 msg="allocate a new session-0005737a"
id=20085 trace_id=581 func=vf_ip_route_input_common line=2574 msg="find a route: flag=80000000 gw-52.52.208.2 via root"
id=20085 trace_id=581 func=fw_local_in_handler line=402 msg="iprope_in_check() check failed on policy 0, drop"
To avoid any destination IP being false-positively dropped by FortiGate, any unused IP Pool must be removed from the FortiGate configuration.
Most of the time, IP Pool addresses are within the same subnet of the FortiGate interface IP.
If IP Pool addresses and FortiGate interface IP are from different subnet ranges, then the next hop unit has to be able to re-route IP Pool addresses back to FortiGate.
Note:
The KB article Technical Tip: IP pool and virtual IP behavior changes in FortiOS 6.4, 7.0, 7.2, and 7.4 cover all other FortiOS versions as well.
