FortiClient Remote Access IPsec-over-TCP not working

Nope. 80F 7.6.3 and free FortiClient 7.4.3.1790. Custom port 444.
In a sniffer I only see syn and ack. In IKE debug I only see there 3 lines.
Notice a timeout occurs in 18 seconds. 
Pretty hopeless.

Hi, @ryanswj 
Try below setting 

config system settings
    set ike-tcp-port 443

end

After that 

diagnose vpn ike restart 

This will restart current VPN instance, try move this activity after hours

And change the TCP port on FortiClient accordingly 

Make sure if you are using 443 for IPSEC over TCP that you are also not using 443 for other daemons like proxy or admin interface. Does not matter what interface its bound to. Also if testing from a windows machine, make sure you have the latest visual C++ runtime installed or ipsec over TCP doesnt work. This seems dumb but this was our issue. I had tested from multiple windows machines and all had older versions of the runtime. It has to be the newest one available. You could confirm this by testing from a non windows machine. The behavior is as described, you get the ack reply and then nothing happens.

If you have issues with IPSec IKEv2 over TCP:

1. Make sure you are using FortiGate FortiOS 7.4.8+ or 7.6.3+

2. Test with TCP port other than 443 if you have issues with 443. Compare the result.

3. Wait for FortiClient 7.4.4/7.4.5

4. Contact Fortinet Technical Support with a valid FortiEMS license and ask for B6699 for tests and log collection.

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

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"

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

Instead of auto, use tcp.

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 

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.