Dial-Up IPSec VPN SAML Dual-WAN TCP issues

[info-dcsistemas]

Hi guys!

We are currently experiencing some issues trying to transition from SSL-VPN to IPSec Dial-Up using SAML with MS Entra ID.We are using FortiOS 7.4.8 and FortiClient 7.4.3 1790 VPN Only Version.

As far as the authentication via SAML goes, it all works perfectly, we followed the official guide on how to set it up and as long as we use UDP as transport, it all works just fine. The problem comes because we were having some stability issues using UDP (FortiClient randomly disconnects while actively working over the VPN) and we wanted to try TCP transport to see if that change would impact stability. 

In the original setup, we had two tunnels configured, one for each WAN connection, with the same following config:

edit "VPN-IPSec-Iplan"
set type dynamic
set interface "wan1"
set ike-version 2
set peertype one
set net-device disable
set mode-cfg enable
set ipv4-dns-server1 192.168.2.88
set ipv4-dns-server2 192.168.2.90
set proposal aes256-sha256 aes256-sha512
set ip-fragmentation pre-encapsulation
set dpd on-idle
set dhgrp 21 18
set eap enable
set eap-identity send-request
set fragmentation-mtu 1100
set transport udp
set peerid 
set assign-ip-from name
set ipv4-split-include "VPN-IPSec-Networks"
set ipv4-name "IPSec_Tunnel_Addr1"
set save-password enable
set client-auto-negotiate enable
set client-keep-alive enable
set psksecret 
set dpd-retryinterval 60

These two tunnels are part of an interface zone (not SD-WAN), and then we made the necessary FW policies to allow the traffic. The DNS record that the clients receive on the XML config has both public IPs. We tested on different endpoints connecting using one IP or the other (using hosts file on the PCs) and both IPs respond and connect with no problems (except for the stability ones).

The FortiClient config is as follows:

 <ipsecvpn>
<options>
<enabled>1</enabled>
<beep_if_error>0</beep_if_error>
<usewincert>1</usewincert>
<use_win_current_user_cert>1</use_win_current_user_cert>
<use_win_local_computer_cert>1</use_win_local_computer_cert>
<no_dns_registration>1</no_dns_registration>
<block_ipv6>1</block_ipv6>
<uselocalcert>0</uselocalcert>
<usesmcardcert>1</usesmcardcert>
<enable_udp_checksum>0</enable_udp_checksum>
<disable_default_route>0</disable_default_route>
<show_auth_cert_only>0</show_auth_cert_only>
<disallow_invalid_server_certificate>0</disallow_invalid_server_certificate>
<check_for_cert_private_key>0</check_for_cert_private_key>
<enhanced_key_usage_mandatory>0</enhanced_key_usage_mandatory>
<prefer_ipsecvpn_dns>1</prefer_ipsecvpn_dns>
<mtu_size>1100</mtu_size>
</options>
<connections>
<connection>
<name>DC</name>
<single_user_mode>0</single_user_mode>
<machine>0</machine>
<type>manual</type>
<ui>
<show_passcode>0</show_passcode>
<show_remember_password>1</show_remember_password>
<show_alwaysup>0</show_alwaysup>
<show_autoconnect>0</show_autoconnect>
<save_username>0</save_username>
<save_password>1</save_password>
</ui>
<keep_running>1</keep_running>
<ike_settings>
<version>2</version>
<implied_SPDO>0</implied_SPDO>
<implied_SPDO_timeout>0</implied_SPDO_timeout>
<xauth_timeout>0</xauth_timeout>
<prompt_certificate>0</prompt_certificate>
<description />
<server>server</server>
<authentication_method>Preshared Key</authentication_method>
<auth_data>
<preshared_key>PSK</preshared_key>
</auth_data>
<azure_auto_login>
<azure_app />
</azure_auto_login>
<mode>aggressive</mode>
<dhgroup>21;</dhgroup>
<key_life>86400</key_life>
<localid>localid</localid>
<peerid />
<nat_traversal>1</nat_traversal>
<transport_mode>0</transport_mode>
<udp_port>500</udp_port>
<mode_config>1</mode_config>
<enable_local_lan>0</enable_local_lan>
<session_resume>0</session_resume>
<childless_mode>0</childless_mode>
<cert_subjectcheck>0</cert_subjectcheck>
<failover_sslvpn_connection />
<block_outside_dns>0</block_outside_dns>
<nat_alive_freq>5</nat_alive_freq>
<dpd>1</dpd>
<dpd_retry_count>3</dpd_retry_count>
<dpd_retry_interval>5</dpd_retry_interval>
<enable_ike_fragmentation>1</enable_ike_fragmentation>
<sso_enabled>1</sso_enabled>
<ike_saml_port>12443</ike_saml_port>
<use_external_browser>0</use_external_browser>
<xauth>
<enabled>1</enabled>
<prompt_username>1</prompt_username>
<username></username>
<vpn_before_logon>
<username_format>username</username_format>
</vpn_before_logon>
<password />
</xauth>
<proposals>
<proposal>AES256|SHA1</proposal>
<proposal>AES256|SHA256</proposal>
</proposals>
</ike_settings>
<ipsec_settings>
<remote_networks>
<network>
<addr>0.0.0.0</addr>
<mask>0.0.0.0</mask>
</network>
<network>
<addr>::/0</addr>
<mask>::/0</mask>
</network>
</remote_networks>
<ipv4_split_exclude_networks />
<dhgroup>21</dhgroup>
<key_life_type>seconds</key_life_type>
<key_life_seconds>43200</key_life_seconds>
<key_life_Kbytes>5120</key_life_Kbytes>
<replay_detection>1</replay_detection>
<pfs>1</pfs>
<use_vip>1</use_vip>
<virtualip>
<type>modeconfig</type>
<ip>0.0.0.0</ip>
<mask>0.0.0.0</mask>
<dnsserver>0.0.0.0</dnsserver>
<winserver>0.0.0.0</winserver>
</virtualip>
<proposals>
<proposal>AES128|SHA1</proposal>
<proposal>AES256|SHA256</proposal>
</proposals>
</ipsec_settings>
<keep_fqdn_resolution_consistency>0</keep_fqdn_resolution_consistency>
<on_connect>
<script>
<delay>3</delay>
<os>windows</os>
<script>
</script>
</script>
</on_connect>
<on_disconnect>
<script>
<delay>0</delay>
<os>windows</os>
<script>
</script>
</script>
</on_disconnect>
</connection>
</connections>
</ipsecvpn>

Instead, when we change the transport in the tunnels and the client to TCP (with a custom port, because we are using 443 for other things) only one of the WAN interface allows the connections, when using the other one, we get a timeout.

config system settings
set ike-tcp-port 11443

Again, testing with the hosts file on the endpoints, we noticed that once you establish a connection using TCP on one of the WAN interfaces, the other one doesn't allow any connection using TCP, it just drops the connection. We used the diagnostics tools via CLI to get more info and we noticed that on the interface that rejects the connections, nothing is logged in the IKE debug, it seems like it doesn't even arrive there. We do see the SAML request using "diagnose debug app saml -1", but once the SAML exchange ends, the FortiClient gives a timeout on the connection and nothing shows on the IKE debug log on the CLI. When we disconnect every client on TCP from the other interface, the one that was rejecting the connections now works, seemingly indicating that we cannot use both of them at the same time.

We are not sure if this is the intended behavior or if we have something wrong on our side. We are out of ideas of how to get both of the WANs to work on TCP connections. We would appreciate any feedback you can give us.

Thanks a lot!

PD:

Also, we noticed that using the setting "set fortinet-esp enable" on the phase1-interface causes the VPN to connect correctly over TCP and UDP but now traffic doesn't return, we don't see any "bytes received" on the FortiClient, even though if we sniff the interface on the FortiGate, the traffic is being sent. We believe that this has something to do with the FortiClient, not necessarily with the FortiGate. 

[Jean-Philippe_P]

Hello info-dcsistemas, 

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible. 

Thanks, 

[Jean-Philippe_P]

Hello,

We are still looking for an answer to your question.

We will come back to you ASAP.

Thanks,

[Jean-Philippe_P]

Hello again info-dcsistemas,

I found this solution. Can you tell us if it helps, please?

To address the issues you're experiencing with transitioning from SSL-VPN to IPsec Dial-Up using SAML and TCP transport, follow these steps:

1. Check TCP Port Configuration: Ensure that the custom TCP port (11443) is correctly configured on both FortiGate and FortiClient. Verify that the port is not blocked by any firewall rules or network devices between the client and FortiGate.
   
   
2. WAN Interface Configuration: Verify that both WAN interfaces are correctly configured to accept TCP connections on the specified port. Ensure that there are no conflicting settings or policies that might prevent one of the interfaces from accepting connections.
   
   
3. IKE TCP Configuration: Confirm that the `set ike-tcp-port 11443` command is applied correctly on both WAN interfaces. This setting should be consistent across all interfaces intended to handle TCP connections.
   
   
4. SAML and IKE Debugging: Since you mentioned that SAML requests are logged but IKE is not, ensure that the IKE settings are correctly configured for TCP transport. Use `diagnose debug application ike -1` to capture detailed logs and identify any discrepancies.
   
   
5. Interface Zone and Policies: Review the interface zone configuration and ensure that both WAN interfaces are part of the same zone. Check the firewall policies to ensure they allow traffic over the specified TCP port.
   
   
6. FortiClient Configuration: Double-check the FortiClient configuration to ensure it matches the FortiGate settings, especially the transport mode and port settings. Ensure that the `transport_mode` is set to TCP.
   
   
7. Testing and Isolation: Test each WAN interface independently by temporarily disabling the other to isolate the issue. This can help determine if the problem is specific to one interface or a configuration issue.
   
   
8. Fortinet-ESP Setting: If enabling `set fortinet-esp enable` causes traffic issues, consider disabling it temporarily to see if it resolves the traffic flow problem. This setting might not be compatible with your current configuration.
   
   
9. Consult Fortinet Support: If the issue persists after these steps, consider reaching out to Fortinet Support for further assistance. Provide them with detailed logs and configuration settings for a more in-depth analysis.

By following these steps, you should be able to identify and resolve the issues with your IPsec Dial-Up configuration using TCP transport.

[info-dcsistemas]

Hi Jean-Philippe! 

Thank you very much for your response. We followed every step that you mentioned and had no luck. (I should mention that step 3 is a global setting, not a per interface setting).

We are still making some tests and will contact support if we continue to experience this issues. 

Regards, 

Juan.

[Rino_B]

Have you also tested these issues with FortiClient VPN version 7.2.10?

[info-dcsistemas]

Hi Rino_B! 

We did not test that version, given that version 7.2.10 does not support TCP transport, at least according to the XML reference guide.

Thanks!

Regards,

Juan.