Created on 10-10-2023 10:04 PM Edited on 03-15-2024 01:47 AM By Anthony_E
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:
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.
|
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.
Modified Behavior: For explicit proxy setups, one set of these steps is sufficient to avoid the issue:
Modified Behavior: For SSL VPN web mode setups, the following steps are sufficient to avoid the issue:
Clarification: For SSL VPN tunnel mode, ippool vs ip-pools:
Modified Behavior: For interface mode IPsec VPN setups with local gateway configured, the following steps are sufficient to avoid the issue:
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:
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
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:
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:
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:
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.