This article explains why the No-Syn-Check and No-Seq-Check features do not work when Source NAT with port translation is applied to network traffic.

When utilizing Source NAT with port translation, packets may be dropped if the initial packet is not a SYN packet, despite having both "no-syn-check" and "no-sequence-check" enabled. Below are the symptoms observed in the logs:

Mar 19 12:45:21: THREAD_ID-06:RT: flow_first_src_xlate: Source NAT returns status: 1, rule/pool ID: 1/4, pst_nat: False, nat_eim: False.
Mar 19 12:45:22: THREAD_ID-06:RT: dip id = 4/0, 192.168.1.10/57746 -> 203.0.113.5/25395, protocol 6
Mar 19 12:45:22: THREAD_ID-06:RT: Selected interface reth2.0 (P2P) as the outgoing physical interface.
Mar 19 12:45:22: THREAD_ID-06:RT: flow_first_final_check: Input interface <reth1.0>, output interface <reth2.0>
Mar 19 12:45:22: THREAD_ID-06:RT: Packet dropped because the first packet was not a SYN packet.

This is expected SRX behavior. For traffic undergoing Source NAT with port translation, the SRX always enforces a SYN check, and the no-syn-check option does not take effect.

For port-translated packets, any packet that arrives without a SYN causes the SRX to allocate a new NAT source port, different from the one used for the original session. This changes the translated 5-tuple so it no longer matches the session created by the original SYN packet. The SRX interprets the packet as a new session attempt without a SYN, applies the SYN check, and drops the packet, which results in application failure.

However, in non-port-translated Source NAT or static NAT configurations, the translated 5-tuple remains consistent across packets. In these cases, no-syn-check can take effect normally, and the application continues to function as expected.