Strange indeed, in the FG sniffer if you look 3 lines above where 192.168.202.3 returns ACk it also gets blocked (and no PSH flag), seems like FG drops any returning traffic from 192.168.202 except SYN+ACK. On the other hand the traffic is strange as well - first 4 packets establish successfully TCP session, then instead of using this session, the host 10.49 again sends SYN out of the blue ...
if it is some SCADA/IOT irregular traffic FG may have problems statefully understanding it.
Is it in proxy mode (I see it is, have you tried FLow mode instead?)? Do you have some fancy VIP/NAT ? What does profile do (why custom, not "default")
id=20085 trace_id=1045 func=av_receive line=305 msg="send to application layer"
It indicates proxy-based utm feature is used. If it is flow-based utm, it is "send to ips".
To debug proxy-based utm: "diag debug application wad -1"
To debug flow-based utm: "diag debug application ipsengine -1" OR "diag ips debug enable all"
Note that the above commands will print out lot's of debug messages and bring a network traffic to halt.
You can specify filter like ip address to reduce debug slow down.
For proxy-based utm, it means 2 connections is done from client to wad daemon, then wad daemon to server (proxy mode). So it could be the tcp flag is processed by wad daemon but the new connection to server-side didn't use it.
Disable all utm features first so either "send to application" or "send to ips" in "diag debug flow..." doesn't show up.
This means the packet is handled by kernel directly or offloaded to npu / hw accel is used/triggered for better performance. Hope it helps.
good chance you have a different issue because as mentioned before PSH is a quite normal TCP option and gets allowed all the time. please perform the troubleshooting above to show your exact issue and start a new thread then.
also if you want a quicker answer work with Fortinet support, they can guide you through the troubleshooting and work with you on the actual device and traffic.