Description
This article describes a known conflict that can occur when using the same IP Address range/pool/subnet for SSL VPN and dial-up IPsec VPNs.
Scope
All FortiOS versions.
Solution
It is generally recommended to avoid using the same IP range for both SSL VPN and IPsec. The reason is that SSL VPN (sslvpnd) and IPsec (iked) are separate processes within the FortiOS and they do not share information regarding IP address allocation between each other.
For example, if the same IP address range of 10.11.11.10 - 10.11.11.254 is used for both IPsec Dial-Up and SSLVPN, IKE will give an IP address of 10.11.11.10 to its first dial-up connection and the SSL VPN will give the same IP address to its first connected user. This causes a route conflict on the FortiGate and results in only the traffic for the IPsec user to work as expected.
SSL VPN:
IPsec dial-up:
See the routing overlap on the kernel routing table:
get router info kernel | grep 10.11.11.10
tab=254 vf=4 scope=0 type=1 proto=11 prio=1 0.0.0.0/0.0.0.0/0->10.11.11.10/32 pref=0.0.0.0 gwy=10.11.11.10 dev=87(EAP-Dialup_0)
tab=254 vf=4 scope=0 type=1 proto=17 prio=10 0.0.0.0/0.0.0.0/0->10.11.11.10/31 pref=0.0.0.0 gwy=0.0.0.0 dev=32(ssl.WAN)
Currently there is no configuration or internal checking process within FortiOS that prevents admin users from this configuration.
Workaround:
If the VPN IP address ranges cannot be changed to use a new subnet (i.e. due to various internal routing/design restrictions), then a workaround is available.
When users are connected to the dial-up IPsec VPN and the SSL VPN, a corresponding /32 and /31 kernel address entry is created (i.e. an individual address within the range). With that in mind, a viable workaround option is to split the existing IP address range into two non-overlapping chunks to be assigned to the IPsec and SSL VPN tunnels. For example, the 10.11.11.10-10.11.11.254 range could be split into 10.11.11.10-10.11.11.131 and 10.11.11.132-10.11.11.254.
This will allow the internal routing after traffic leaves firewall to be able to use the subnet 10.11.11.10/24 without any problem.
