Technical Tip: FTP connections Fail after Upgrading the FortiGate to v7.6.x

[Dokoye]

Description	This article describes a known issue with passive mode FTP communication through FortiGates after upgrading to firmware v7.6.x. FortiGate may send a TCP reset (RST) packet to the client during FTP data transfer.
Scope	FortiGate v7.6.0 and above.
Solution	This behavior occurs only when the FTP server is configured to use its public IP address in Passive Mode responses. The root cause has been identified as an incorrect DNAT operation for the FTP data session. In the example below, the PC client is located outside the network and attempts to access an internal FTP server behind the FortiGate firewall. Topology: The session below was created for the control plane communication for FTP over port 21. The traffic is forwarded from port 1 to port 6. diagnose sys session filter src 10.119.200.37 diagnose  sys  session list session info: proto=6 proto_state=01 duration=5 expire=3596 timeout=3600 refresh_dir=both flags=00000000 socktype=0 sockport=0 av_idx=0 use=4 origin-shaper= reply-shaper= per_ip_shaper= class_id=0 ha_id=0 policy_dir=0 tunnel=/ helper=ftp vlan_cos=0/255 state=log may_dirty npu npd f00 statistic(bytes/packets/allow_err): org=427/9/1 reply=641/9/1 tuples=2 tx speed(Bps/kbps): 0/0 rx speed(Bps/kbps): 0/0 orgin->sink: org pre->post, reply pre->post dev=9->14/14->9 gwy=192.168.8.2/10.21.15.254 hook=pre dir=org act=dnat 10.119.200.37:58296->10.21.12.17:21(192.168.8.2:21) hook=post dir=reply act=snat 192.168.8.2:21->10.119.200.37:58296(10.21.12.17:21) ... FTP data channels use high-numbered TCP ports, not the FTP control channel port TCP 21. In normal operation, the FortiGate FTP session helper opens expectation sessions based on observed FTP control traffic. On affected firmware versions, the session is created, but traffic is incorrectly forwarded to the root interface of the FortiGate. session info: proto=6 proto_state=02 duration=5 expire=6 timeout=3600 refresh_dir=both flags=00000000 socktype=0 sockport=0 av_idx=0 use=4 origin-shaper= reply-shaper= per_ip_shaper= class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=255/255 state=log npu intree statistic(bytes/packets/allow_err): org=0/0/0 reply=200/5/1 tuples=2 tx speed(Bps/kbps): 0/0 rx speed(Bps/kbps): 0/0 orgin->sink: org pre->post, reply pre->post dev=9->28/14->9 gwy=10.21.12.17/0.0.0.0 hook=pre dir=org act=dnat 10.119.200.37:58297->10.21.12.17:50007(10.21.12.17:50007) hook=post dir=reply act=snat 10.21.12.17:50007->10.119.200.37:58297(10.21.12.17:50007) ... This causes FTP data traffic to be dropped. Interface indexes can be seen in the output of 'diagnose ip address list'. diagnose ip address list IP=192.168.88.204->192.168.88.204/255.255.255.0 index=3 devname=mgmt IP=10.21.12.16->10.21.12.16/255.255.252.0 index=9 devname=port1 IP=192.168.8.30->192.168.8.30/255.255.255.0 index=14 devname=port6 IP=172.16.1.200->172.16.1.200/255.255.255.0 index=19 devname=port11 IP=127.0.0.1->127.0.0.1/255.0.0.0 index=28 devname=root Workaround: There are two potential workarounds for this issue: Disable the FTP session helper. One approach is to remove the session helper for FTP. Since expectation sessions will no longer be created in this case, a firewall policy must be manually created to allow inbound connections for data transfer. show system session-helper 9 config system session-helper     edit 9         set name ftp         set protocol 6         set port 21     next end config system session-helper     delete 9 end Configure the FTP server to use its local IP address in passive mode: For example, in the FileZilla server application, configure the local IP under Protocols settings -> FTP and FTP over TLS -> Public IP or hostname. Once either of these methods is applied, FTP data traffic should pass as expected. Resolved in: This issue has been resolved in v7.6.4 (scheduled to be released in August 2025). These Timelines for firmware release are estimates and may be subject to change.