FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
Session helpers in FortiOS provide basic Application Layer Gateway functionality. 

This article describes session helpers setup expectation sessions.

Session helpers keep track of the communication of the Layer-7 protocols such as FTP and will dynamically open up the ports as required for the communication.
The record of these dynamic ports is kept by the session helpers in the form of the expectation sessions.

Expectation session is a pseudo-session that is created by the session helper for the ports negotiated by the upper layer protocols.
The expectation session usually has a timeout value of 30 seconds.

Hence, if the communication from the server is not initiated within 30 seconds the expectation session will time out and the traffic will be denied.

The following debug commands can be executed to verify that the session helper is opening up the ports as required.

1) Determining whether sessions helpers are being used.

Debug flow trace can show if the session helper is running for the particular traffic or not.
id=13 trace_id=1098 msg="vd-root received a packet(proto=6,> from internal1.flag
id=13 trace_id=1098 msg="Find an existing session, id-008423f4, original direction"
id=13 trace_id=1098 msg="SNAT>"
id=13 trace_id=1098 msg="run helper-ftp(dir=original)"
2) Listing the expectation sessions.

The pin-hole ports that the session helper opened can be verified using the following command:-
FGT_A # diagnose sys session list expectation
session info: proto=6 proto_state=00 duration=6 expire=23 timeout=3600 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=3
ha_id=0 policy_dir=1 tunnel=/
state=new npu acct-ext complex
statistic(bytes/packets/allow_err): org=0/0/0 reply=0/0/0 tuples=2
orgin->sink: org pre->post, reply pre->post dev=5->7/7->5 gwy=

hook=pre dir=org act=dnat>
hook=pre dir=org act=noop>
pos/(before,after) 0/(0,0), 0/(0,0)
misc=0 policy_id=25 id_policy_id=0 auth_info=0 chk_client_info=0 vd=0
serial=008423f4 tos=ff/ff ips_view=0 app_list=0 app=0
dd_type=0 dd_mode=0
per_ip_bandwidth meter: addr=, bps=223
npu info: flag=0x00/0x00, offload=0/0, ips_offload=0/0, epid=0/0, ipid=0/0, vlan=0/0
'policy_id=25' in the expect session does not really mean that the traffic matches policy 25.

The value 'policy_id=25' in the expect session is just a copied value from the master session which is the oldest helper-ftp session.
Once an expect session is created, it acts as a pinhole on the firewall policy.

Traffic matching the expect session does not need the approval of firewall policy to be forwarded by the system.

If the master session is cleared, all its expect sessions are cleared as well.
To establish the connection, a new helper-ftp session needs to be established.

The new session must match a firewall policy and hence all its expect sessions will copy this new policy_id.
The value of policy_id in the expect session, no matter it is 25 or other value, does not impact on how the corresponding traffic is forwarded.

Overall, a newly created regular session, either dce-rpc or icmp or other protocols, must match a forwarding policy, and its policy_id value indicates the policy it matches.
However, if the traffic hits an expect session, it does not mean that the traffic really matches the firewall policy.
Actually, traffic hitting an expect session does not need a corresponding firewall policy, which is what session helpers are used for.

If it is preferred that the firewall policy controls all the traffic between the source and destination hosts, including the traffic matching the 'master session' and 'expect session', then the corresponding helper should be deleted and the service should be appropriately configured in the corresponding firewall policy.

It is not a workaround, because expectation sessions are designed to be not controlled by firewall policies.