SYN - Client-----SWITCH-----EDGE RTR------FGT----Server
SYN-ACK - Server-----FGT-----SWITCH-----Client (Router won't get this packet as switch is aware about the source IP/MAC) ACK - Client-----SWITCH-----EDGE RTR ------FGT------Server (Now the edge router is getting an ACK packet for a TCP handshake where there is no SYN-ACK). Can you check if the router is dropping this?
- Have you found a solution? Then give your helper a "Kudos" and mark the solution.
I would rather try, to just test, adding a static route to the client machine for the DMZ subnet to 10.0.2.16 because likely the problem is due to the fact the SYN hits the router first then forwarded to the FGT, while SYN-ACK tries to go directly to the client from the FGT, and I'm suspecting the FGT is dropping it.
Or, you could just sniff the traffic at the interface w/ 10.0.2.16 to see what's coming in and what's going out (nor not going out).
<edit>Or, the switch might be learning the destination MAC from the router-forwarded SYN packet, and intercepting the ACK packet and redirecting to the FGT instead of sending to the router. The sniffing the interface would tell something.
I think so. You probably need to check how your switch is handing next by like setting up port mirroring if the switch doesn't support packet capture like above 2xx models of FortiSwitch. Also run Wireshark on the client machine side at the same time to see if the SYN-ACK is reaching and if it's responding with ACK.
In any case putting the FGT in the same subnet/broadcast domain with the GW device would cause some unexpected/unwanted L2 frame routing behavior like this. With your topology, I would set up a /30 interconnect subnet between the GW router and the FGT instead.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.