Technical Tip: FTP port open on FortiGate WAN IPs

To resolve this issue, it is essential to understand that the FTP port being open does not necessarily mean that the FortiGate is accepting external connections on that port. The diagnose sys tcpsock command lists all TCP ports on which the FortiGate is listening, along with the responsible processes.

1. Run the command diagnose sys tcpsock to verify the listening ports and their corresponding processes.
2. Check the output for the FTP port (port 21) and verify that it is being used by the wad process.

Example: 

FortiGate # diagnose sys tcpsock | grep  :21
0.0.0.0:21->0.0.0.0:0->state=listen err=0 socktype=2 rma=0 wma=0 fma=0 tma=0 inode=103733 process=751/wad

3. Understand that the wad process is used for proxy inspection and that the FTP port being open is an expected behavior in this case.

    

4. To block incoming connections on port 21, configure a local-in policy with the following settings: 

config firewall local-in-policy

    edit

        set intf "portx"

        set srcaddr "all"

        set dstaddr "all"

        set action deny

        set service "FTP"

        set schedule "always"

    next

end

The packet captures and the flow debugs can be taken to confirm the same:

Start the logging by following the document below:

diagnose sniffer packet any "host x.x.x.x " 6 0 a  <----- x.x.x.x is the IP address of the destination.

Open another PuTTY client, start the session logging, and run the commands below:

diagnose debug reset

diagnose debug flow filter clear

diagnose debug flow filter add x.x.x.x

diagnose debug console timestamp enable

diagnose debug flow show function-name enable

diagnose debug flow show iprope enable

diagnose debug enable

diagnose debug flow trace start 1000

Let the issue be reproduced, and then run the command below to stop the debug.

diagnose debug flow trace stop

In the collected packet captures, only the TCP-SYN packet will be found and not the response as TCP-SYN-ACK.
As demonstrated, the source is sending the SYN packet and re-transmitting from the client. However, the FortiGate is not responding with SYN-ACK, as shown in the picture.


Also, in the flow debugs, it may provide the possible cause for dropping the traffic.

Debug example:

2026-03-24 03:46:10 id=65308 trace_id=6 func=print_pkt_detail line=6336 msg="vd-root:0 received a packet(proto=6, 172.26.154.28:65338->10.5.149.50:21) tun_id=0.0.0.0 from port1. flag [S], seq 3631759747, ack 0, win 65535" <----- Traffic incoming on port1 and destination as 10.5.149.50 and dport 21.
2026-03-24 03:46:10 id=65308 trace_id=6 func=init_ip_session_common line=6550 msg="allocate a new session-006d070c"
2026-03-24 03:46:10 id=65308 trace_id=6 func=iprope_dnat_check line=5592 msg="in-[port1], out-[]"
2026-03-24 03:46:10 id=65308 trace_id=6 func=iprope_dnat_tree_check line=826 msg="len=0"
2026-03-24 03:46:10 id=65308 trace_id=6 func=iprope_dnat_check line=5617 msg="result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000"
2026-03-24 03:46:10 id=65308 trace_id=6 func=__vf_ip_route_input_rcu line=2116 msg="find a route: flag=80000000 gw-0.0.0.0 via root" <----- Gateway is root as traffic is destined for FortiGate.
2026-03-24 03:46:10 id=65308 trace_id=6 func=iprope_access_proxy_check line=463 msg="in-[port1], out-[], skb_flags-02000000, vid-0"
2026-03-24 03:46:10 id=65308 trace_id=6 func=__iprope_check line=2485 msg="gnum-100017, check-ffffffffc02e22f7"
2026-03-24 03:46:10 id=65308 trace_id=6 func=iprope_policy_group_check line=5014 msg="after check: ret-no-match, act-accept, flag-00000000, flag2-00000000"
2026-03-24 03:46:10 id=65308 trace_id=6 func=iprope_in_check line=503 msg="in-[port1], out-[], skb_flags-02000000, vid-0"
2026-03-24 03:46:10 id=65308 trace_id=6 func=__iprope_check line=2485 msg="gnum-100011, check-ffffffffc02e3346"
2026-03-24 03:46:10 id=65308 trace_id=6 func=iprope_policy_group_check line=5014 msg="after check: ret-no-match, act-drop, flag-00000000, flag2-00000000"
2026-03-24 03:46:10 id=65308 trace_id=6 func=__iprope_check line=2485 msg="gnum-100001, check-ffffffffc02e22f7"
2026-03-24 03:46:10 id=65308 trace_id=6 func=__iprope_check_one_policy line=2202 msg="checked gnum-100001 policy-1, ret-no-match, act-accept"
2026-03-24 03:46:10 id=65308 trace_id=6 func=__iprope_check_one_policy line=2202 msg="checked gnum-100001 policy-2, ret-matched, act-accept"
2026-03-24 03:46:10 id=65308 trace_id=6 func=__iprope_user_identity_check line=1965 msg="ret-matched"
2026-03-24 03:46:10 id=65308 trace_id=6 func=__iprope_check_one_policy line=2455 msg="policy-2 is matched, act-drop"
2026-03-24 03:46:10 id=65308 trace_id=6 func=__iprope_check line=2502 msg="gnum-100001 check result: ret-matched, act-drop, flag-08010800, flag2-00000000"
2026-03-24 03:46:10 id=65308 trace_id=6 func=iprope_policy_group_check line=5014 msg="after check: ret-matched, act-drop, flag-08010800, flag2-00000000"
2026-03-24 03:46:10 id=65308 trace_id=6 func=fw_local_in_handler line=630 msg="iprope_in_check() check failed on policy 2, drop" <----- Dropped the packet matching the local-in policy ID 2.