Pevangelista,
TCP Syn check basically ensures 3-way handshake taken place before allowing traffic to pass.
The risk you take by turning off TCP SYN, is that you're basically allowing partial TCP connection, that can potenially lead to many type(s) of DoS attack. An attacker's incoming SYNs floods is an attemp choke the hosts kernal memory, and eventually to fill up TCB (transmission control block) that contributes to other delays in network to establish TCP session on target host device.
Also, as pointed out in the following document:
https://www.juniper.net/documentation/en_US/junos/topics/concept/reconnaissance-deterrence-attack-evasion-tcp-syn-check-understanding.html
Session Table Floods—If SYN checking is disabled, an attacker can bypass the Junos OS SYN flood protection feature by flooding a protected network with a barrage of TCP segments that have non-SYN flags set. Although the targeted hosts drop the packets—and possibly send TCP RST segments in reply—such a flood can fill up the session table of the Juniper Networks device. When the session table is full, the device cannot process new sessions for legitimate traffic.
And for failure to a secondary firewall, the following KB & doc can help:
Configuring TCP SYN Check options on a per policy basis:
https://kb.juniper.net/InfoCenter/index?page=content&id=KB21266&actp=METADATA
How to selectively disable TCP SYN or Sequence checking:
https://kb.juniper.net/InfoCenter/index?page=content&id=KB25094
[KUDOS! If you think I earned it!
If this solution worked for you please flag my post as an "Accepted Solution" so others can benefit..]
Regards,
Karan Dhanak