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
You are correct, these are not the same thing.
"Interface Filters" / Firewall Filters
The
show interfaces filters
command is used to show what firewall filters are applied to each interface, and in which direction. Firewall filters are supported on just about every Juniper hardware platform.In a general sense, firewall filters are far less robust than the application firewall feature. They cannot do deep packet inspection (they operate on Layers 3 and 4), they can see things like source/destination IP or source/destination port. The most common use for firewall filters is to protect your control/management plane on a Juniper device, here's a very basic example on how to only allow SSH.
NOTE: Firewall filters are generally called ACL's by other vendors and the industry.
NOTE: Firewall filters can also be used in CoS configuration.
If you want some good information, check out the Juniper Documentation.
Application Firewall
The other command you referenced,
show security application-firewall rule-sets all
relates to SRX's application firewall feature.The full feature set of application firewalls can get pretty unwieldy, but in short they do a much more thorough analysis of the traffic. If you check out the Application Firewall Overview you'll see the following text:
The reference to "standard network firewall policies" is pretty much a direct comparison to the above mentioned "firewall filters". Let me know if this isn't clear, and I'll happily edit my answer.