Description
This article describes the IP pool and virtual IP (VIP) behavior changes in FortiOS v6.4, v7.0, v7.2, and v7.4.
Scope
This article also provides workarounds for the modified IP pool and VIP behavior changes that apply to these ranges of FortiOS firmware versions only:
- 6.4.9 and later.
- 7.0.1 to 7.0.12.
- 7.2.0 to 7.2.5.
- 7.4.0.
Solution
This table summarizes the IP pool and virtual IP (VIP) behavior depending on the FortiOS firmware version:
|
Case
|
FortiOS Firmware Version
|
IP pool behavior when set arp-reply enable configured (by default).
|
|
1
|
6.4.8 and below
7.0.0
|
IP pools and virtual IPs (VIPs) are considered local IP addresses.
|
|
2
|
6.4.9 and later
7.0.1 to 7.0.12
7.2.0 to 7.2.5
7.4.0
|
IP pools and virtual IPs (VIPs) are not considered local IP addresses.
See issues and workarounds below.
|
|
3
|
Upcoming 6.4
Upcoming 7.0
7.2.6 and later
7.4.1 and later
|
IP pools and virtual IPs (VIPs) are considered local IP addresses.
- Workarounds in case (2) should not be required.
- Devices with workarounds configured in case (2) should not be affected. If issues are observed, please contact Fortinet Support to investigate further.
|
Previous and Current Behavior – IP pools and VIPs are considered local IP addresses
For cases (1) and (3) above, 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.
However, as a side-effect, once an IP pool or VIP has been configured, even if it is never used in a firewall policy, the FortiGate considers it as a local address and will not forward traffic based on the routing table.
Modified behavior – IP pools and VIPs are not considered local IP addresses and workarounds are required
For case (2), 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.
Modified Behavior: 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 as in this example, 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.
Modified Behavior: For SSL VPN web mode setups, the following steps are sufficient to avoid the issue:
- Configure set web-mode-snat enable within config vpn ssl settings and 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. set web-mode-snat enable was added in FortiOS 7.0.6 and 7.2.0 and then removed in FortiOS 7.2.6, 7.4.0, and future versions after 7.0.12.
- 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.
Clarification: For SSL VPN tunnel mode, ippool vs ip-pools:
- Return traffic not going back to the SSL client if there is an IP pool. The unused IP pool should be removed or set arp-reply to disable.
- GUI
- VPN -> SSL-VPN Portal -> edit -> "Source IP Pools" = Policy & Objects -> Addresses
- VPN -> SSL-VPN Portal -> edit -> "Source IP Pools" ≠ Policy & Objects -> IP Pools
- CLI
- "ip-pools" in "config vpn ssl web portal" = "config firewall address"
- "ip-pools" in "config vpn ssl web portal" ≠ "config firewall ippool"
Modified Behavior: 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.
Modified Behavior: 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 the steps described in the 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, the reply traffic cannot reach the explicit web proxy on the FortiGate.
To resolve the issue caused by the blackhole route configuration, 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 port1
set secondary-IP enable
config secondaryip
edit 1
set ip 1.1.1.1 255.255.255.0
next
end
next
end
Modified Behavior: 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 the 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, 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, configure set web-mode-snat enable within config vpn ssl settings 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 the outgoing FortiGate interface defined in the SSL VPN web mode firewall policy. set web-mode-snat enable was added in FortiOS 7.0.6 and 7.2.0 and then removed in FortiOS 7.2.6, 7.4.0, and future versions after 7.0.12.
- 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 web-mode-snat option is enabled and 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 vpn ssl settings
...
set web-mode-snat enable
...
end
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
Modified Behavior: 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
Because the local gateway is configured with the IP address that matches an IP pool, since this IP address is not considered local then the IPsec VPN Phase 1 negotiation fails and the IPsec tunnel does 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
Note (thanks to @toy4two for the contribution):
The above workaround for an IPsec phase1 interface involves a secondary IP address on the interface.
In some cases, the setup involves VDOM links to an Internet VDOM for each tenant.
VDOM links do not allow setting up secondary IPs where the public IP can be set for IPsec.
The workaround is to use Loopback Interfaces, source the IPsec VPN from loopback, and allow in the policy the ESP, AH, IKE in and out of the VDOM link towards the Internet.
Related articles:
