| IPsec tunnels predominantly use UDP ports 500 and 4500 for their connections. With the latest development, modern IPsec tunnels are being established over TCP ports too. This had been a solution for cases where ISPs have certain ports blocked due to various reasons.
Modern-day FortiClient uses IPsec connections more often than SSLVPN due to various reasons. Also, new features have been introduced where an ongoing IPSEC connection on UDP can be failed over to TCP.
There is a misconception that this failover will take place automatically from UDP to TCP, and the tunnel will establish itself. But once the IPSec connection over UDP is down due to some reason, such as UDP was blocked or otherwise, it is required to reinitiate the IPSec connection from the FortiClient, where it will establish over TCP. Related FortiClient configuration. 
FortiGate configuration. config vpn ipsec phase1-interface
edit "ipsec"
set type dynamic
set interface "port2"
set ike-version 2
set peertype any
set net-device disable
set mode-cfg enable
set proposal aes128-sha256 aes256-sha256 aes128gcm-prfsha256 aes256gcm-prfsha384
set comments "VPN: ipsec (Created by VPN wizard)"
set eap enable
set eap-identity send-request
set wizard-type dialup-forticlient
set authusrgrp "testgrp"
set transport udp-fallback-tcp <-- Select this option.
set ipv4-start-ip 192.168.111.1
set ipv4-end-ip 192.168.111.5
set dns-mode auto
set ipv4-split-include "ipsec_split"
set save-password enable
set psksecret ENC Ys2d7YIVgfjkfWnext
end config sys settings set ike-tcp-port 5500 end Testing and results. Tunnel is up with UDP 4500: kvm81 # diagnose sniffer packet any ' port 500 or port 4500 or port 5500 ' 4 0 l
Using Original Sniffing Mode
interfaces=[any]
filters=[ port 500 or port 4500 or port 5500 ]
2026-02-26 23:17:23.208180 port2 in 10.3.2.150.59641 -> 10.55.3.193.4500: udp 842
2026-02-26 23:17:23.286816 port2 out 10.55.3.193.4500 -> 10.3.2.150.59641: udp 364
2026-02-26 23:17:23.301930 port2 in 10.3.2.150.59641 -> 10.55.3.193.4500: udp 552
2026-02-26 23:17:23.301951 port2 in 10.3.2.150.59641 -> 10.55.3.193.4500: udp 88
In the LAB setup, another FortiGate has been used to block UDP packets. Once UDP packets are blocked, the FortiGate keeps sending requests on UDP ports. FortiGate is sending keepalives in IKE debugs. ike V=root:0:ipsec_0:10: sent IKE msg (INFORMATIONAL_RESPONSE): 10.55.3.193:4500->10.3.2.150:59641, len=80, vrf=0, id=1d3827fc604e04cb/ef51edd37d9e4db3:00000037, oif=4
ike V=root:0:ipsec_0: NAT keep-alive 4 10.55.3.193->10.3.2.150:59641.
ike 0:ipsec_0:10: out FF
ike V=root:0:ipsec_0:10: sent IKE msg (keepalive): 10.55.3.193:4500->10.3.2.150:59641, len=1, vrf=0, id=ff00000000000000/8100000000000000, oif=4
ike V=root:0:ipsec_0: NAT keep-alive 4 10.55.3.193->10.3.2.150:59641.
ike 0:ipsec_0:10: out FF
ike V=root:0:ipsec_0:10: sent IKE msg (keepalive): 10.55.3.193:4500->10.3.2.150:59641, Sniffer output. 2026-02-26 23:34:38.758377 port2 in 10.3.2.150.59641 -> 10.55.3.193.4500: udp 116
2026-02-26 23:34:38.758413 port2 out 10.55.3.193.4500 -> 10.3.2.150.59641: udp 132
2026-02-26 23:34:38.758435 port2 out 10.55.3.193.4500 -> 10.3.2.150.59641: udp 132
2026-02-26 23:34:42.766021 port2 in 10.3.2.150.59641 -> 10.55.3.193.4500: udp 116
2026-02-26 23:34:42.766087 port2 in 10.3.2.150.59641 -> 10.55.3.193.4500: udp 116
2026-02-26 23:34:42.766133 port2 out 10.55.3.193.4500 -> 10.3.2.150.59641: udp 132
2026-02-26 23:34:42.766156 port2 out 10.55.3.193.4500 -> 10.3.2.150.59641: udp 132
2026-02-26 23:34:52.765482 port2 out 10.55.3.193.4500 -> 10.3.2.150.59641: udp 1 << Oneway traffic
2026-02-26 23:35:02.765548 port2 out 10.55.3.193.4500 -> 10.3.2.150.59641: udp 1
2026-02-26 23:35:12.765529 port2 out 10.55.3.193.4500 -> 10.3.2.150.59641: udp 1
2026-02-26 23:35:22.765493 port2 out 10.55.3.193.4500 -> 10.3.2.150.59641: udp 1
2026-02-26 23:35:32.765508 port2 out 10.55.3.193.4500 -> 10.3.2.150.59641: udp 1 FortiClient IPsec down. 
After selecting 'Connect' on FortiClient again, a new negotiation starts on TCP port 5500 as shown in the debug output below. ike V=root:0:ipsec_0:10: sent IKE msg (keepalive): 10.55.3.193:4500->10.3.2.150:59641, len=1, vrf=0, id=ff00000000000000/8100000000000000, oif=4
ike V=root:accepts ike tcp-transport(vd=0, vrf=0, intf=0:4, 10.55.3.193:5500->10.3.2.150:58518 sock=34 refcnt=2 ph1=(nil)) (1). <-- New negotiation with TCP port 5500.
ike V=root:0: comes 10.3.2.150:58518->10.55.3.193:5500,ifindex=4,vrf=0,len=838....
ike V=root:0: IKEv2 exchange=SA_INIT id=9702480b582147c9/0000000000000000 len=838
ike 0: in 9702480B582147C900000000000000002120220800000000000003462200019C020000440101000703000008030000020 Sniffer output with TCP negotiation commences. 2026-02-26 23:39:52.765478 port2 out 10.55.3.193.4500 -> 10.3.2.150.59641: udp 1
2026-02-26 23:40:02.765546 port2 out 10.55.3.193.4500 -> 10.3.2.150.59641: udp 1
2026-02-26 23:40:12.765517 port2 out 10.55.3.193.4500 -> 10.3.2.150.59641: udp 1
2026-02-26 23:40:21.594070 port2 in 10.3.2.150.58518 -> 10.55.3.193.5500: syn 309505874 <-- First Sync packet.
2026-02-26 23:40:21.594225 port2 out 10.55.3.193.5500 -> 10.3.2.150.58518: syn 3060518285 ack 309505875
2026-02-26 23:40:21.595270 port2 in 10.3.2.150.58518 -> 10.55.3.193.5500: ack 3060518286
2026-02-26 23:40:21.595404 port2 in 10.3.2.150.58518 -> 10.55.3.193.5500: psh 309505875 ack 3060518286
2026-02-26 23:40:21.595413 port2 out 10.55.3.193.5500 -> 10.3.2.150.58518: ack 309505881
2026-02-26 23:40:21.597153 port2 in 10.3.2.150.58518 -> 10.55.3.193.5500: psh 309505881 ack 3060518286
2026-02-26 23:40:21.597166 port2 out 10.55.3.193.5500 -> 10.3.2.150.58518: ack 309506725 FortiClient IPsec is up with TCP. 
| 
