A network engineer posts a flow session dump from an SRX5400 running Junos OS 21.3R1.9: policy hit count climbing, a single CP session ID shared by both halves of the flow, and the return leg permanently stuck at Out: Pkts: 0, Bytes: 0. The SRX can ping the destination host directly. The route is in the table. The policy is a clean permit. Nothing about it looks broken, and yet nothing is forwarding. This is one of the more disorienting SRX symptoms because every surface-level check passes while traffic still dies silently, and this guide covers the actual diagnostic order and the root causes ranked by how often each one turns out to be the answer.
What an SRX Session Out Pkts 0 Actually Means
When show security flow session shows a session with an In leg that has packet and byte counters climbing and an Out leg stuck at zero, it means the SRX accepted the first packet, matched a security policy, installed a session, and is now waiting for return traffic that never arrives at the session. It does not mean the SRX is dropping the inbound packet. The In counters prove that packet got through policy and NAT lookup cleanly.
The zero in the Out leg tells you the problem is downstream of policy evaluation. Either the return traffic from the destination host never physically reaches the SRX, or it reaches the SRX on the wrong interface and gets treated as a new, unrelated flow instead of being matched back into the existing session. Those are two very different problems with two very different fixes, and the diagnostic steps below are built to separate them quickly.
Step-by-Step Diagnosis, Cheapest Test First
Work through these in order. Each step is cheaper than the next, and most SRX session out pkts 0 cases resolve by step 4 without ever needing a packet capture.
Step 1: Confirm the destination host is actually answering
Before touching the SRX configuration, rule out the simplest explanation: the destination host itself is not responding, has a missing default gateway, or has host-based firewall rules silently dropping the probe. This is not an SRX problem at all, and in our experience it accounts for a real share of these reports, especially with ICMP, since Windows hosts block inbound ping by default.
user@srx> show security flow session destination-prefix 192.0.2.10/32 extensiveCheck the session timestamp and whether the In leg keeps incrementing on retries. If In packets climb every time you retest but Out never moves even once, move to step 2.
Step 2: Check the route the SRX will use for the return leg
The SRX picks the egress interface for return traffic based on a route lookup against the session's reverse 5-tuple, not necessarily the interface the original packet is tied to. Confirm the route actually points where you expect.
user@srx> show route 192.0.2.0/24 active-path detailIf the active route for the destination prefix resolves through a different interface or routing instance than the one the original packet arrived on, you likely have an asymmetric routing problem, covered in the first root cause below.
Step 3: Rule out interface-level drops
Before blaming flow logic, confirm the egress interface itself is not silently discarding frames at the PFE.
user@srx> show interfaces ae1.102 extensive | match "drop|error|discard"A clean counter set here does not clear the SRX of blame. It just moves the problem back into flow processing, which is where most of these cases actually live.
Step 4: Ask the SRX directly why it is dropping the packet
This is the step that usually ends the guessing. monitor security packet-drop was introduced in Junos OS 21.1R1 specifically to answer "why did the SRX drop this" without a full packet capture or a traceoptions file.
user@srx> monitor security packet-drop source-prefix 203.0.113.0/24 destination-prefix 192.0.2.0/24 count-number 50Press Ctrl+C to stop. If you see a drop reason referencing route mismatch, reverse route, or zone mismatch, you have confirmed an asymmetric routing condition rather than a policy or NAT problem.
Step 5: Confirm with a live capture if the drop reason is still unclear
When monitor security packet-drop shows nothing because the return packet is not reaching the SRX at all, confirm that directly on both interfaces.
user@srx> monitor traffic interface ae1.102 matching "host 192.0.2.10" no-resolve
user@srx> monitor traffic interface xe-2/2/8.0 matching "host 203.0.113.224" no-resolveIf the return packet never shows up on ae1.102 at all, the problem is upstream of the SRX entirely, often tied to a routing decision on the server's own gateway or a path that bypasses the SRX in the other direction.
Root Cause 1: Asymmetric Reverse-Path Routing (Most Common)
This is the cause behind the large majority of SRX session out pkts 0 reports we see, and it is almost always tied to multihomed upstreams or multiple routing instances sharing a session table. In flow mode, Junos performs a reverse route lookup for the return leg of every session. By default this lookup uses the active routing table, not the interface the original packet arrived on.
If a session enters via one upstream provider but the best route back to that source prefix points out a different upstream, the SRX's reverse route lookup can select the wrong egress path, or in dual-WAN designs without routing instance separation, can fail to resolve a return path that matches the original ingress zone at all. Juniper documents this exact behavior in its guidance on reverse route packet mode using a virtual router, which is the supported fix for exactly this scenario.
The structural reason this keeps surprising people is that Junos flow mode was built around the assumption of a single, symmetric path per zone pair. Multihomed edge designs break that assumption, and the SRX does not silently figure it out the way a stateless router would, because a stateful firewall has to re-validate the return packet against a real session, not just route it.
user@srx> show security zones
user@srx> show route table VR-UPSTREAM.inet.0If you confirm this is the cause, the supported fix is to separate the asymmetric upstream into its own routing instance so the reverse route lookup has an unambiguous path back to the session's origin zone.
set routing-instances VR-UPSTREAM instance-type virtual-router
set routing-instances VR-UPSTREAM interface xe-2/2/8.0
set routing-instances VR-UPSTREAM routing-options static route 0.0.0.0/0 next-hop 203.0.113.1
set security zones security-zone upstream-provider interfaces xe-2/2/8.0Test this in a lab or a maintenance window before touching a production edge box, since moving an interface into a new routing instance briefly interrupts existing sessions on it. Use commit confirmed 5 and keep an out-of-band console session open.
user@srx> commit confirmed 5Root Cause 2: Return Route Points to the Wrong Zone, No Multihoming Involved
Not every instance of this symptom involves a second ISP. A simpler and still common version is a static or connected route that technically reaches the destination prefix but does so through an interface sitting in a different zone than the one the security policy was written for. The session gets created against one zone pair, but the reverse route lookup resolves through an interface in a different zone, and the return packet never matches a policy that was only written for the original pair.
user@srx> show route 192.0.2.0/24 all
user@srx> show security zones upstream-providerIf the route table shows two paths to the same prefix and the preferred one lands in the wrong zone, fix the routing preference or add the missing policy pairing, whichever matches your intended topology. Do not add a blanket permit-all policy as a workaround; that just hides a routing problem behind an overly broad security policy.
Root Cause 3: The Destination Host Is Simply Not Responding
This is the cheapest to rule out and the easiest to forget once you are deep into flow traceoptions. ICMP in particular is frequently blocked by host-based firewalls, and a session with In packets climbing and Out stuck at zero looks identical whether the SRX is dropping the return leg or the host never sent one. Confirm using TCP or UDP against a port you know is listening before spending time on SRX-side packet drops.
Quick Reference: Symptom, Cause, and Fix
| Symptom | Likely Cause | Fix |
|---|---|---|
| Out: Pkts: 0, multiple upstream ISPs | Asymmetric reverse-path routing across zones | Separate the asymmetric upstream into its own routing instance |
| Out: Pkts: 0, single upstream, route exists | Return route resolves through the wrong zone | Fix routing preference or add the correct zone pairing |
| Out: Pkts: 0, ICMP only | Destination host blocking inbound ICMP | Test with TCP/UDP against a known listening port first |
| monitor security packet-drop shows a route or zone mismatch reason | Confirms reverse route lookup failure | Apply the virtual-router fix in Root Cause 1 |
| Return packet never appears in monitor traffic on egress interface | Upstream routing bypasses the SRX entirely | Fix routing outside the SRX, not inside it |
Verifying the Fix
After separating the asymmetric upstream into its own routing instance, re-run the same session check and confirm the Out leg now increments.
user@srx> show security flow session destination-prefix 192.0.2.10/32 extensiveA healthy session now shows both legs incrementing together, roughly matched in packet count for a simple ICMP exchange:
Session ID: 1241245669928, Policy: allow-all/7, State: Active
In: 203.0.113.224 --> 192.0.2.10/24;icmp, If: xe-2/2/8.0,
Pkts: 4, Bytes: 336, CP Session ID: 2673013
Out: 192.0.2.10/24 --> 203.0.113.224;icmp, If: ae1.102,
Pkts: 4, Bytes: 336, CP Session ID: 2673013If Out is still zero after the routing-instance change, go back to monitor security packet-drop with the same filters and confirm the drop reason has actually changed, rather than assuming the fix worked because the configuration committed cleanly.
A Note on Junos Release and Flow Mode Behavior
This guide is written against Junos OS 21.4R3 and later, and the commands shown, including monitor security packet-drop, require at minimum Junos OS 21.1R1. The original report that prompted this guide was running Junos OS 21.3R1.9 on an SRX5400, which is consistent with the behavior described here. Reverse route packet mode and the virtual-router based fix have been part of Junos flow processing across SRX platforms for a long time, but always verify the exact routing-instance syntax against Juniper's TechLibrary page for reverse route packet mode for your specific platform and release before committing in production.
This behavior does not differ meaningfully between standalone SRX and SRX chassis clusters, but it has not been independently verified here against Junos OS Evolved, which uses a different forwarding architecture. If you are running Junos Evolved on an SRX platform, confirm the routing-instance based fix against your own release notes before relying on it.
None of the configuration in this guide has been tested in a production environment by juniperclient.com. Validate the routing-instance change in a lab topology that mirrors your zone and interface layout before applying it to a live edge device, and keep console access available during the change.
A community thread on r/Juniper captures this exact symptom on an SRX5400, including the same In/Out session pattern and the same asymmetric-routing suspicion, and is a good reference for seeing the raw session output other engineers have hit.
Related guides: for the security policy side of session troubleshooting, see our SRX NAT troubleshooting guide, which covers the NAT-specific session table checks this guide does not. If the symptom you are chasing is actually a stuck routing protocol rather than a stuck session, see our BGP stuck in Active troubleshooting guide. For the general method of narrowing down interface-level packet loss before you get to flow logic, our show interfaces extensive walkthrough covers the counters referenced in Step 3 above. Browse the full troubleshooting category for more SRX and MX failure guides.
Juniper, Junos, MX, SRX, EX and QFX are trademarks of Juniper Networks, Inc. juniperclient.com is an independent site and is not affiliated with or endorsed by Juniper Networks.
Frequently Asked Questions
In flow-based mode, can a session exist but never forward any return traffic?
Yes. A session can show a correct policy match and a healthy In leg while the Out leg stays at zero indefinitely. This almost always means the return packet either never reaches the SRX or arrives on an interface that does not match the session's expected reverse path.
Does the flow engine detect asymmetric return paths and silently drop them?
The flow engine does not silently drop without a reason; it performs a reverse route lookup and will drop the return packet if that lookup resolves to a path inconsistent with the session. Use monitor security packet-drop to see the actual drop reason instead of assuming it is silent.
Is a routing-instance or virtual-router the only fix for asymmetric upstream routing on an SRX?
It is the Juniper-documented and most reliable fix for true multihomed asymmetric routing, separating each upstream into its own routing instance so reverse route lookups resolve unambiguously. Workarounds like security flow allow-reverse-ecmp address a narrower ECMP-specific case and do not fix a hard asymmetric split across unrelated upstreams.
Why does show security flow session show matching policy hits but Out: Pkts: 0 forever?
A policy hit count only confirms the inbound packet matched a rule; it says nothing about whether a reply ever arrived. Check show route for the destination prefix and confirm the egress interface and zone match what the session expects before assuming the policy itself is broken.
How do I tell if the destination host is the problem instead of the SRX?
Test with TCP or UDP to a port you know is listening, since ICMP is frequently blocked by host firewalls and can produce an identical-looking Out: Pkts: 0 symptom. If TCP traffic also fails to return, move on to monitor security packet-drop on the SRX itself.
What Junos release do I need for monitor security packet-drop?
The monitor security packet-drop command requires Junos OS 21.1R1 or later, with drop-reason signatures added in 21.2R2. On older releases, use security flow traceoptions with a packet filter instead to get equivalent visibility.
Discussion (0)