Client VPN Migration running both SSL and IPsec VPN

[kois]

Sorry all, long post... Any help would be appreciated

Just before I start, I have already reached out to Fortinet support regarding the below, unfortunately I was provided with a few generic documentation links and directed to contact a partner/distributor for assistance.

The partner/distributor we engage is well not the best and hasn't really been able to help, and so I'm hoping the community can provide some insights or point me toward more specific resources.

We are currently running FortiOS 7.4.8 and need to implement both SSL VPN and IPsec VPN services simultaneously. Our environment consists of multiple locations where we currently use Fortigate firewalls for SSL client VPN. We have a few ASA's around where we are using them for Client VPN also, but we are planning a migration all sites to Fortinet and use IPsec VPN.

At our first migration site, we have a specific configuration challenge. Currently, all inbound TCP 443 traffic is port forwarded to an ASA firewall that handles SSL VPN connectivity for our users. We are needing to migrate these users from the ASA SSL VPN to FortiGate IPsec VPN, but both systems need to remain operational during the transition period. Our primary requirement is to run both VPN services on port 443 for client connectivity, as many of our remote users experience port blocking issues with non-standard ports, this mean we are looking to use both TCP/UDP 443 for IPSEC.

We have multiple WAN IP addresses available and have been testing configurations where the ASA continues to receive SSL VPN traffic on the current WAN IP (WAN 1 interface IP on the firewall) via port forwarding, whilst we configure IPsec VPN to use a different WAN IP address. However, we have encountered several challenges during our testing. When configuring IPsec VPN with SAML authentication, the Fortinet official documentation states that the SAML server must be bound to the WAN interface, which forces all SAML authentication communication to use the primary WAN interface IP address that is currently used for port forwarding SSL VPN traffic to the ASA. Whilst we can configure SAML authentication to use a different TCP port, the core issue is that SAML authentication uses the primary WAN IP rather than our intended IPsec tunnel IP. When clients attempt SAML authentication, they encounter certificate errors because the cert we are using has a domain name that is tied to the secondary WAN IP, but the SAML authentication process communicates through the primary WAN IP address. We are using Azure for SAML. 

Can anyone confirm if there is a supported method to have IPsec VPN SAML authentication use a specific secondary IP address rather than defaulting to the primary WAN interface IP? We have tried using VIP configurations including a secondary IP on the WAN interface, but the SAML authentication still appears to communicate using the original interface IP. I am not sure if policed base routing may help here? Maybe a VIP on a loopback but then the concern is, will IPSEC be processed in software instead hardware on the firewall because of the loopback?

We are also exploring whether we can configure multiple IPsec tunnels, each with a different SAML group configuration. For instance, one tunnel might handle our company users via one server, whilst another tunnel handles external company users using SAML for authentication. What we are trying to achieve is something similar to SSL VPN realms and portals. If this approach is supported, how does the FortiGate determine which tunnel and associated SAML configuration to apply when a user attempts to connect?

We also have concerns about changing the global IPsec port settings since this affects all IPsec tunnels rather than being configurable per tunnel. Currently, we have existing IPsec tunnels, including SD-WAN configurations that are operational. If we modify the global ike tcp port setting to use port 443 instead of the default 4500, and similarly change the UDP port settings from 500 to 443, we want to confirm that changing these ports will not cause any issues with the existing IPsec VPN tunnels.

We have read about using different IP address ranges for SSL VPN and IPsec VPN to avoid routing conflicts. Can anyone provide guidance on best practices for IP address allocation when both services are running simultaneously? Are there any other network configuration considerations we should account for during the transition period?

Finally, we would like to understand the roadmap for SSL VPN tunnel mode deprecation. We know that SSL VPN tunnel mode is being phased out in favour of IPsec VPN. This is already seen in FortiOS 7.6.3 and later. Given that we are currently on FortiOS 7.4 branch, does any know if there will be any interim updates to the 7.4 branch that will affect SSL VPN functionality? We thought tech support could at least provide some clarity on this, but we got no response on this one.

[funkylicious]

hi,

you can avoid the SAML WAN situation by creating a loopback interface with another free public IP and enable ike-saml-server on it, in theory it should work - i havent tried it yet.

you would need a firewall policy for the traffic, WAN > loopback in order for allowing internet access towards it for IPsec/SAML/etc.

you can also define/select the Loopback for the IPsec dialup in the VPN configuration as the remote gateway for users.

for ipsec TCP/443 you can use this link, https://docs.fortinet.com/document/fortigate/7.4.8/administration-guide/567401 , since only IKEv2 supports SAML , ipsec tunnel with IKEv1 in theory should not be affected but again i havent tested this scenario and couldnt tell for sure.

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Do-not-use-the-same-IP-address-range-for-b... 

[kois]

Hi funkylicious,

Thanks for the quick response!

The loopback interface approach for avoiding the SAML WAN binding issue is exactly the kind of thing we were looking for. However, we do have one concern and that is how IPsec traffic is processed in the firewall when a loopback is in use. Do you know if IPsec will still use hardware acceleration (encryption/decryption) when a loopback is in use for the tunnel, or if it forces software processing? if it forces software processing, just worried  what the performance impact would be like.

Oh and thanks for this one https://community.fortinet.com/t5/FortiGate/Technical-Tip-Do-not-use-the-same-IP-address-range-for-b... 

I learnt the hard way, good to see this in the form of a technical tip

[funkylicious]

hardware acceleration could be done depending on the FGT model , https://community.fortinet.com/t5/FortiGate/Technical-Tip-Information-about-IPsec-on-loopback-interf... 

[kois]

Thank you!!!

I followed through with loopback, yes SAML config works on the loopback, created VIP for port forwarding IKE ports from a public IP to Loopback. All seem well, test client worked, received SAML authentication, tunnel came up, split tunnel routes ok but only saw traffic sent but not received....
I looked around and then came across this document
https://community.fortinet.com/t5/FortiGate/Technical-Tip-IPsec-dial-up-connection-to-a-Loopback-Int...

At the bottom of the doc it mentions VIP is not support with LOOPBACK for IPSEC? But the document runs you through Loopback with VIP? I'm I missing something?

[funkylicious]

try setting directly a public IP on the Loopback /32 and bypass this limitation with VIP.