FortiClient Remote Access IPsec-over-TCP not working

[ryanswj]

Hi, I am running FortiOS 7.4.7 on a FortiGate-60F and am trying to migrate from SSLVPN to IPsec VPN.

I've managed to configure IPsec (IKEv2) dial-up to work fine, but I notice that when I set the mode to IPSec over TCP, FortiClient (v7.4.3) does not connect and times out. UDP mode works perfectly fine.

I also notice that TCP 4500 is not one of the local-in policies on the firewall.

Does a local-in policy need to be configured for this to work? Has anyone had any experience with this?

Thank you!

[Henry0]

I managed to fixed the issue. Must select DH group 14 or above on FortiClient if you are using the dialup vpn template on FortiGate.

Running FortiOS 7.4.8 and FortiClient 7.4.3 work well with IKE TCP

[nikriaz]

In Phase1 or PFS in Phase 2? Must be something else, I always use >DH14 and tried Phase 2 with and without PFS, it didn't help on 7.6.3

[FortiDor]

Hi,

On my side seems to work FortiClient IPSec over TCP (port tcp/443 & udp/500) only with a local user group(ldap broken I guess) with the 7.4.3 version + FGT 7.4.8

Right with only one DH 14 but with PFS

Need to uninstall the FCT if there was a previous upgrade and do a clean installation

And check network adapters from Fortinet in "Device-Manager". There were Fortinet Adapters with #2 or #3 at the end. Delete them, afterwars it started to work. 

[mycoolusername]

We are experiencing the same or a very similar issue. We are using udp-fallback-tcp because some of our users are in restrictive networks.
While UDP works without any problems, users who rely on TCP are encountering connection failures.

In the firewall's IKE debug log, we consistently see only the following three lines for TCP connections which fail:

ike V=root:accepts ike tcp-transport(vd=0, vrf=0, intf=0:45, <external-firewall-wan-ip>:443-><external-client-wan-ip>:49936 sock=43 refcnt=2 ph1=(nil)) (1).
ike V=root:deletes tcp-transport(vd=0, vrf=0, intf=0:45, <external-firewall-wan-ip>:443-><external-client-wan-ip>:49936 sock=43 refcnt=2 ph1=(nil)) (1).
ike V=root:destroys tcp-transport(vd=0, vrf=0, intf=0:45, <external-firewall-wan-ip>:443-><external-client-wan-ip>:49936 sock=43 refcnt=0 ph1=(nil)) (0).

On the client side, Wireshark shows that three packets are sent for a standard TCP 3-way handshake. After that, there is a pause of about 15–17 seconds, followed by a fourth packet with RST, ACK sent to the FortiGate.

Interestingly, TCP connections work fine on some other clients. I tried to reproduce the issue and was partially successful: a client forced to use TCP has a 50/50 chance of connecting. When clicking "Connect" in the client, it either connects successfully via TCP or fails with the same 3-way handshake and RST behavior, along with the same firewall log. Waiting a few seconds and trying again results in the same 50/50 chance behavior.
Some users, however, experience a permanent failure and are never able to connect via TCP.

Changing the default IKE TCP port to 4500 did not make any difference.

Has anyone found a workaround?

Configuration:
FortiOS v7.4.8
FortiClient VPN 7.4.3.1790

config vpn ipsec phase1-interface
    edit "VPN_User"
        set type dynamic
        set interface "VLAN_2"
        set ike-version 2
        set local-gw <external-wan-ip>
        set peertype any
        set net-device enable
        set mode-cfg enable
        set proposal aes256-sha256 aes256gcm-prfsha256
        set comments "VPN for employees (remote work)"
        set dhgrp 14
        set eap enable
        set eap-identity send-request
        set authusrgrp "LDAP_VPN_USER"
        set transport udp-fallback-tcp
        set fallback-tcp-threshold 10
        set ipv4-start-ip 10.10.10.10
        set ipv4-end-ip 10.10.10.240
        set dns-mode auto
        set ipv4-split-include "VPN_User_Allowed_NW_1"
        set save-password enable
        set psksecret ENC <key>
    next

In the working case, the client proceeds with many additional events after HandleTunnelConnectRequest, such as Preflight_*, StartConnection, TunnelConnecting, etc.
In the error case, the client remains stuck in the Wait state after HandleTunnelConnectRequest, and no further events are triggered.

Client Log – Error Case:

[2025-07-29 19:00:29.8992854] [FortiVPN 161 debug] In state: TunnelConnectRequest
[2025-07-29 19:00:29.8992862] [FortiVPN 1107 debug] => fortivpn::StateMachine::HandleTunnelConnectRequest(Mobile Arbeit)
...
[2025-07-29 19:00:29.9027386] [FortiVPN 161 debug] In state: Wait

Client Log – Working Case:

[2025-07-29 19:31:41.8430029] [FortiVPN 161 debug] In state: TunnelConnectRequest
[2025-07-29 19:31:41.8430041] [FortiVPN 1107 debug] => fortivpn::StateMachine::HandleTunnelConnectRequest(Mobile Arbeit)
...
[2025-07-29 19:31:36.5124044] [FortiVPN 161 debug] In state: Wait
[2025-07-29 19:31:36.5767789] [FortiVPN 322 debug] fortivpn::IDataManager::ValidateSessionVPNs
[2025-07-29 19:31:36.5768208] [FortiVPN 101 debug] fortivpn::StateMachine::AddEvent type=15 (GlobalVPNEnvironmentChanged)
...
[2025-07-29 19:31:41.8429960] [FortiVPN 385 debug] Got event: 17 "TunnelConnectRequest"
[2025-07-29 19:31:41.8548741] [FortiVPN 385 debug] Got event: 18 "Preflight_EnvironmentCompliance"
...
[2025-07-29 19:31:42.0790388] [FortiVPN 385 debug] Got event: 28 "StartConnection"

[nikriaz]

Thank you for detailed investigation. I just want to say that is simply unbelievable that Forti dropped VPN over SSL, released IKE over TCP into production instead, it is simply does not work, potentially hurting millions of users, and they just keep silence with zero comments. The quintessence of irresponsibility.

[riccardo_roveri_labs]

I am facing the exact same issue, did you manage to solve it? 

[KyuBi]

I am facing the exact same issue, did you manage to solve it? 

[VinayHM]

Instead of auto, use tcp.

[riccardo_roveri_labs]

I am using only tcp transport and i set it explicitly using

set transport tcp

I am trying with a w11 vm to replicate my user issues and it seems that the first connection is successfull but the other ones fail with the same ike message of @mycoolusername 

[mycoolusername]

For us, simply setting "tcp" instead of "udp-fallback-tcp" didn’t work either. It turns out that most of the clients experiencing this issue were still running very old Windows builds, like 1809 or newer, but still outdated.

We reinstalled those machines with more recent Windows versions, and the problems were almost entirely resolved. So, it’s unclear whether the Windows reinstall itself helped or if the outdated Windows versions were the root cause.

That said, we’re still seeing this issue occasionally on some newer clients, but far less frequently than before.