TCP handshake timeout on the SRX is 20 seconds by default and you can't manually set it lower than 4 seconds, so that's definitely not the issue.
Did you do the security flow trace in the other direction? It would be nice to see the session initiation (the SRX processing the initial TCP SYN) to see what the initial session actually looks like. That might shine some light on why the return traffic doesn't match the session.
To answer your question though, in checking to see if a session is already established, the SRX will look at six match criteria:
To determine if a packet belongs to an existing flow, the device attempts to match the packet’s information to that of an existing session based on the following six match criteria:
• Source address
• Destination address
• Source port
• Destination port
• Protocol
• Unique token from a given zone and virtual router
Sources:
http://www.juniper.net/techpubs/en_US/junos12.1x47/information-products/pathway-pages/security/security-processing-flow-based.pdf
http://www.juniper.net/techpubs/en_US/junos12.1/information-products/topic-collections/security/software-all/security/junos-security-swconfig-security.pdf
Specific ingress/egress interfaces do not have to be the same as the initial session creation as long as they are in the same security zones as the interfaces used to set up the session.
Source:
https://kb.juniper.net/InfoCenter/index?page=content&id=KB21983
*see the note, just above purpose.
Also - if interfaces/zones were an issue, you'd typically get specific output based on that. In my experience, I've seen drops in security flow traces that referenced the reason being that the egress interface (in the return direction) was not in the same security zone that the initial ingress traffic that established the session came in on. It's pretty verbose for the most part.
Even with a chassis cluster, not much should be different as far as "session" matching goes, although there are some extra things that happen in some cases.
If you're running an active/active cluster, where forwarding redundancy groups are primary/active on different nodes, you could end up with z-mode traffic. So if the ingress is on node 0 and the egress is on node 1, the active session will be maintained on node 1 (egress of the initial sync) and the backup session will be maintained on node 0.
With Z-mode processing, the first packet of a sessionis received on one cluster node (the ingress node). When flow determinesthat the egress interface is located on the second node, the packet is forwarded over the fabric link with a forward session setup on the ingress node. The packetis then processed by the second node upon which anActive session is installed and the packet is forwarded out the egress link. Finally a backup session is created for the Active session in the initial ingress node.
Source:
http://kb.juniper.net/library/CUSTOMERSERVICE/GLOBAL_JTAC/NT260/SRX_HA_Deployment_Guide.pdf
Unless you're doing this with asymmetric routing and the return traffic is leaving an interface on node 1 and returning on node 0 (or vice versa), then we don't have to explore this further - although I believe the backup session can be used and if the zones match and the traffic should still pass. I'll have to explore that more if that's what's going on.
Best Answer
Having spent many weeks working with JTAC to find a solution... the answer was simply to reboot the node which is missing from the SNMP output.
I have set up a few SRX (345) clusters since having this issue and each time they have exhibited the fault. JTAC could not replicate so it's unlikely they will fix it.