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.
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.
jhead@MX-WS-ZT-1> show interfaces filters ge-0/0/0
Interface Admin Link Proto Input Filter Output Filter
ge-0/0/0 up up
ge-0/0/0.0 up up inet MGMT
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.
jhead@SRX1> show configuration firewall
family inet {
filter MGMT {
term SSH {
from {
port 22;
}
then accept;
}
}
}
jhead@SRX1> show configuration interfaces ge-0/0/0
unit 0 {
family inet {
filter {
input MGMT;
}
address 172.16.67.2/24;
}
}
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:
Many dynamic applications use HTTP static ports to tunnel non-HTTP
traffic through the network. Such applications can send traffic that
might not be adequately controlled by standard network firewall
policies, leading to a security threat. Standard policies function
based on IP address and port and therefore are not effective with
these dynamic applications.
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.
Best Answer
The vSRX doesn't support switching features, so the answer is:
vSRX is designed to be a virtual firewall, therefore it doesn't need "switching". It's only the physical SRX devices, that support switching. Take a look at this product datasheet from Juniper, it lists all of the available features on that platform.