# Juniper SRX Flow & Session Troubleshooting — First Path, Fast Path & Traceoptions Source: https://ai.techclick.in/blog_juniper_srx_flow_session_troubleshooting Markdown: https://ai.techclick.in/blog_juniper_srx_flow_session_troubleshooting.md Publisher: Techclick Infosec Pvt Ltd Master Juniper SRX flow session troubleshooting in 2026: understand first-path vs fast-path, read the session table, use security-flow traceoptions, check policy hit-counts, and diagnose the most common SRX firewall issues. Juniper SRX Flow & Session Troubleshooting — First Path, Fast Path & Traceoptions student learning map A visual study map for Juniper SRX Flow & Session Troubleshooting — First Path, Fast Path & Traceoptions showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Juniper SRX Flow & Session Troubleshooting —... Juniper · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① First path vs fast path — how... 4. Practice ② Reading the session table — show... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. Most engineers think… Most people assume the SRX runs every packet through a full policy lookup and NAT evaluation. That model leads you wrong in every troubleshooting scenario. The SRX flow engine has two distinct paths . The first path is the expensive one: only the session-opening packet gets zone checks, route lookup, policy match, NAT evaluation and ALG processing. Once a session entry exists, every subsequent packet uses the fast path and skips all of that. Understanding this split tells you exactly where to look — session table for established flows, traceoptions for the first packet that gets dropped before a session is ever created. ## ① First path vs fast path — how the SRX decides how hard to work When a packet arrives on an SRX, the flow daemon checks the session table by matching the 5-tuple. If no entry exists, the packet is on the first path — the SRX performs zone resolution, route lookup, security policy match, NAT rule evaluation, ALG detection and screen checks, then creates a session entry with the result. All subsequent packets in the same connection hit the fast path : the session entry is found, headers are rewritten per the stored NAT info, and the packet is forwarded — no policy re-evaluation. Why does this matter for troubleshooting? A policy deny, a NAT mismatch, or a screen hit only shows up on the first path. If traffic worked yesterday and fails today, check whether the session was torn down (timeout, RST, asymmetric routing) and a new first-path attempt is now being blocked. Conversely, a session stuck in the table long after traffic stopped means a timeout is not firing — look at the timeout counter in the session output. Figure 1 — First path vs fast path on the SRX Only the session-opening packet runs the full first-path gauntlet. All subsequent packets skip straight to fast-path forwarding. - First path vs fast path on the SRX Packet arrives ingress interface / zone Session lookup 5-tuple in session table? First path policy, NAT, ALG, screen Session created entry stored in table Fast path rewrite & forward Only the session-opening packet runs the full first-path gauntlet. All subsequent packets skip straight to fast-path forwarding. Figure 2 — What the SRX checks on the first path First-path processing layers — each check can drop the packet before the next one runs. What the SRX checks on the first path Screen checks DoS protection, SYN flood, port scan Zone & policy lookup permit, deny or reject + log NAT evaluation source NAT, dest NAT, static NAT ALG & services SIP, FTP, H.323, IPsec tunnel Session entry write result stored for fast path First-path processing layers — each check can drop the packet before the next one runs. Quick check · Q1 of 10 · Understand Which SRX processing path performs the full security policy lookup, NAT evaluation and screen checks? a) Fast path — it handles all packets b) First path — only the session-opening packet c) Both paths equally d) Express path for all UDP traffic Correct: b. Only the first packet of a new connection takes the first path, which performs zone resolution, policy match, NAT evaluation, ALG detection and screen checks, then creates a session entry. Subsequent packets use the fast path and skip that processing. 👉 So far: First path = full policy + NAT + ALG + screen for the session-opening packet only. Fast path = session lookup + rewrite for all subsequent packets in the same flow. ## ② Reading the session table — show security flow session The primary diagnostic command is show security flow session . Each session entry shows the session ID, the matched security policy by name, the ingress and egress interfaces, source and destination with ports, protocol, NAT translations, bytes and packets in each direction, and the remaining timeout in seconds. ### Useful filters Add filters to avoid thousands of lines of output: show security flow session destination-prefix 10.1.1.1/32 to narrow to a specific host; show security flow session protocol tcp destination-port 443 for HTTPS flows. The show security flow session summary gives total active sessions versus the platform maximum — a near-full session table is a silent killer that drops new first-path connections without any explicit policy deny log. 🔍 show security flow session tap to flip The primary session table command. Shows session ID, matched policy name, interfaces, 5-tuple, NAT translations, bytes/packets, and remaining timeout. Add destination-prefix or protocol filters to narrow output. 📋 show security policies hit-count tap to flip Reveals policy utility: zero hits = shadowed or dead rule; huge hits = possibly too broad. Reset counters with clear security policies statistics after tuning to start a fresh baseline. 🔦 security-flow traceoptions tap to flip X-rays the first-path journey. Always set a packet filter (source + destination IP) before enabling. Read with show log. Disable and commit immediately after — traceoptions can degrade SPU performance at scale. ⚡ Fast path tap to flip After the session entry is created by the first path, all subsequent packets in the same flow skip policy lookup, NAT evaluation and most checks — they just rewrite headers per the stored entry and forward. The fast path is why the SRX scales. Session summary before you dig deeper Always run show security flow session summary first. If active sessions are near the platform maximum, new first-path connections are being silently dropped — no policy deny log, no traceoptions output. Fix the table exhaustion before any other troubleshooting step. ### ▶ Watch a TCP SYN get permitted and a session created A first-path packet traversing the SRX flow engine end-to-end. Press Play for the healthy path, then Break it to see the classic silent drop. ① SYN arrives A client sends a TCP SYN to the payment server. The packet hits the SRX ingress interface in the Trust zone. ▼ ② First-path check No session entry matches the 5-tuple. The flow daemon runs zone check, policy lookup (permit rule found), source NAT evaluation and screen checks — all pass. ▼ ③ Session created A session entry is written with the policy name, NAT translation and timeout. The SYN is forwarded to the Untrust zone interface. ▼ ④ SYN-ACK fast path The server's SYN-ACK arrives on the return interface, matches the session entry via fast path, headers are rewritten per NAT and the packet is forwarded to the client. Press Play to step through a healthy TCP SYN being permitted by the SRX. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · Q2 of 10 · Apply You want to check active sessions for destination IP 192.168.10.5 only. Which command is best? a) show security flow session b) show route 192.168.10.5 c) show security flow session destination-prefix 192.168.10.5/32 d) show security policies detail Correct: c. The destination-prefix filter on show security flow session restricts output to sessions matching that host, avoiding thousands of lines of unrelated sessions. The other commands serve different purposes. 👉 So far: show security flow session: check session ID, matched policy name, interfaces, NAT translations and remaining timeout. Add destination-prefix or protocol filters to avoid wall-of-text output. ## ③ Traceoptions — pinpoint exactly where a packet is dropped When a session never appears in the table — meaning the first-path packet was dropped before a session could be created — security-flow traceoptions is your X-ray. Configure it under set security flow traceoptions file with a flag (basic-datapath is the go-to) and critically a packet filter to limit tracing to a specific source and destination IP pair. Without the packet filter, traceoptions generates enormous log volume and degrades the SPU. Read the trace file with show log . Look for the verdict line: RT: indicates a policy deny, RT: followed by a reason (e.g. no-reverse-route, screen hit) pinpoints the exact drop cause, and the policy name in the output confirms which rule (or the implicit deny) is matching. Always disable traceoptions immediately after collecting output: delete security flow traceoptions and commit. Since Junos 24.2R1, the local-debug-buf option lets you tune the in-memory trace buffer up to 40,000 lines. Figure 3 — Traceoptions — one flag, many clues The basic-datapath flag traces the full first-path journey; the packet filter keeps it surgical. Traceoptions — one flag, many clues security flow traceoptions packet filter basic-datapath policy verdict NAT result drop reason show log file The basic-datapath flag traces the full first-path journey; the packet filter keeps it surgical. Traceoptions without a packet filter = SPU stress Enabling security-flow traceoptions with the basic-datapath flag but no packet filter on a busy SRX traces every single first-path packet and can degrade forwarding performance or crash the SPU under high load. Always scope it to a specific source/destination IP pair and disable immediately after collecting the log. Quick check · Q3 of 10 · Analyze A traceoptions file shows 'RT: ' next to a policy named 'block-internet'. What does this tell you? a) The packet was allowed by block-internet and then dropped by NAT b) The session was created but timed out c) The packet matched the block-internet policy and was denied at first-path d) The fast path was bypassed Correct: c. RT: in the trace output means the policy verdict for that packet was deny. The policy name alongside it identifies which rule matched. The session was never created because the first-path dropped the packet. 👉 So far: Traceoptions: always use a packet filter (src + dst IP), enable only as long as needed, read with show log, then delete and commit. RT: = policy drop; no-reverse-route = asymmetric routing drop. ## ④ Security policy hit-counts & common fixes show security policies hit-count lists every configured policy sorted by the number of times it has matched traffic since the last reset. This instantly reveals shadowed rules (hit-count zero for a rule that should be firing — something above it is catching the traffic first), overly broad permit rules (enormous counts that should be multiple narrower rules), and dead rules you can safely remove. ### Common fixes The five issues you will see most often: (1) Policy deny — policy name in the session or trace log does not match what you expected; check zone pair and address book. (2) Asymmetric routing drop — SRX sees the return packet on a different SPU or interface; enable set security flow allow-dns-reply or fix the routing. (3) NAT mismatch — source or destination NAT rule did not apply because zone or address match failed; verify with show security nat source rule all . (4) Session table full — add show security flow session summary and compare active vs maximum; reduce timeouts or upgrade platform. (5) ALG interference — SIP/FTP control channel opens fine but data channel fails; check show security alg status . Figure 4 — Policy deny vs session table drop Two common SRX drops look similar but need different fixes — traceoptions tells them apart. Policy deny vs session table drop Policy deny Session never created Policy name in trace: deny Fix: check zone pair & address Hit-count on deny rule rises Session table drop Session created, then packets lost Trace: no-reverse-route or timeout Fix: routing symmetry or timeout Session summary shows near-max Two common SRX drops look similar but need different fixes — traceoptions tells them apart. Arjun at a Mumbai fintech company faces this Application team says HTTPS to the payment gateway (10.20.5.10) worked yesterday but drops silently today. show security flow session shows no active session for the destination. Likely cause A routing change moved the return path through a different interface, causing asymmetric routing — the SRX receives the TCP SYN reply on an interface that has no matching session entry and drops it silently. Diagnosis show security flow session destination-prefix 10.20.5.10/32 — no session. Enable traceoptions with a packet filter for 10.20.5.10 and look for 'no-reverse-route' or 'asymmetric' in the drop reason. Operational mode ▸ show security flow session + set security flow traceoptions Fix Restore symmetric routing so both directions traverse the same SRX path. If asymmetric routing is unavoidable, enable flow-based asymmetric routing support on the affected zone, or consider using a stateless filter instead. Verify Disable traceoptions, retest HTTPS to 10.20.5.10 — show security flow session now shows an active session with the correct policy name and both byte counters incrementing. Confirm the fix from the session, not a ping A ping passing proves ICMP is working, not that TCP port 443 is working. After any SRX fix, verify with show security flow session filtered to the exact destination and port, confirm the correct policy name appears in the session, and check that byte counters in both directions are incrementing. Quick check · Q4 of 10 · Evaluate A security policy shows zero hit-count after a week of production traffic. What is the most likely cause? a) The policy is working correctly and blocks high-volume attacks b) A rule higher in the policy list matches the same traffic first — the rule is shadowed c) Hit-counts only increment for UDP traffic d) The session table is full Correct: b. Zero hits on a policy that should fire almost always means a broader rule above it in the policy list is catching the traffic first, shadowing this rule. Check the order of rules and compare address/zone/application matches. 👉 So far: show security policies hit-count: zero hits = shadowed or dead rule; huge hits = possibly too broad. Verify fixes from the session table, not a ping — session entry + incrementing byte counters = working flow. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. What is the difference between first-path and fast-path on a Juniper SRX? How do I read the output of show security flow session? How do I safely use traceoptions to debug a dropped packet on the SRX? What does show security policies hit-count tell me? What causes a silent drop with no policy deny log on the SRX? How do I confirm a fix worked after SRX troubleshooting? Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember Which command shows the number of times each security policy rule has matched traffic? a) show security flow session b) show security policies hit-count c) show security screen statistics d) show interfaces detail Correct: b. show security policies hit-count lists every policy rule with its match count since boot or last clear. It is the primary tool for detecting shadowed, dead or overly broad rules. Q6 · Understand Why does the SRX NOT run a security policy lookup on the second and subsequent packets of an established TCP session? a) TCP packets are always trusted after the handshake b) The policy engine is turned off for TCP c) A session entry was created by the first-path packet — subsequent packets use the fast path and look up the existing entry instead d) Only UDP requires a policy lookup Correct: c. The first-path creates a session entry storing the policy result, NAT translation and other per-flow data. Fast-path packets look up this entry and reuse the stored results, which is why the SRX can forward established sessions at high throughput. Q7 · Apply Traceoptions output shows 'no-reverse-route' for a packet from 10.1.1.1 to 10.2.2.2. What should you check first? a) The security policy zone pair b) The NAT source pool c) Whether the return path from 10.2.2.2 to 10.1.1.1 traverses a different SRX interface than the forward path d) The DNS resolver configuration Correct: c. no-reverse-route means the SRX cannot find a session entry for the return packet — classic asymmetric routing. The fix is to ensure both directions of the flow traverse the same SRX path, or to enable asymmetric flow support. Q8 · Analyze A session table summary shows active sessions at 98% of the platform maximum. What will happen to new connections? a) New connections are queued and processed when space frees up b) The SRX reboots automatically to flush the table c) New first-path packets are silently dropped — no session can be created and no policy deny log is generated d) Only UDP new sessions are dropped; TCP sessions are always accepted Correct: d. When the session table is nearly full, new first-path connection attempts are dropped silently before the policy engine is even consulted — no deny log, no traceoptions output from a policy hit. Reducing timeouts or upgrading to a higher-capacity platform is the fix. Q9 · Evaluate An engineer enables security-flow traceoptions with the basic-datapath flag but no packet filter on a 10 Gbps SRX. What is the most serious risk? a) The SRX will log only 100 packets and stop b) Tracing every first-path packet can overwhelm the SPU and degrade or crash forwarding performance c) Traceoptions only works without a filter on older Junos releases d) The log file will fill up /var/log and the SRX will reboot Correct: b. Without a packet filter, basic-datapath traces every first-path packet on a busy link. The SPU overhead from writing trace entries at line rate can degrade forwarding and in severe cases crash the process. Always use a source/destination IP packet filter and disable immediately after collection. Q10 · Evaluate After fixing an SRX policy issue, a colleague says 'I pinged the server successfully so the fix works.' Why is this insufficient verification? a) Ping always fails through an SRX b) ICMP (ping) can succeed while TCP port 443 is still denied — the session table must show an entry for the correct destination and port with the intended policy name and incrementing byte counters c) Only traceoptions can confirm a fix d) Ping proves all protocols are working since it uses the same session table Correct: a. ICMP is a separate protocol from TCP. A policy may permit ICMP but still deny TCP 443. Verification requires show security flow session filtered to the exact destination and port, confirming the correct policy name and byte counters incrementing in both directions. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one line: what is the difference between a first-path drop and a fast-path drop on an SRX, and how do you find each one? Then compare with the expert version. Compare with expert answer Expert version: A first-path drop happens before a session is ever created — the session-opening packet is rejected by a screen, a policy deny, a NAT failure or because the session table is full. You find it by checking show security flow session (no entry for the destination), then enabling traceoptions with a packet filter to see the exact reason (RT: , no-reverse-route, screen hit). A fast-path drop is rarer and means an established session is losing packets mid-flow — check for interface errors, MTU mismatches, or a software upgrade that flushed the session table. The session entry exists but byte counters stop incrementing. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Juniper SRX at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary First path SRX processing path for the session-opening packet: zone check, policy lookup, NAT evaluation, ALG detection and screen checks. Creates the session entry. Fast path SRX processing path for established-flow packets: looks up the existing session entry, rewrites headers per stored NAT info, and forwards. No policy re-evaluation. Session table In-memory table of active connections, keyed on 5-tuple. Each entry stores the matched policy, NAT translations and timeout. show security flow session reads it. security-flow traceoptions Junos diagnostic feature that logs the first-path journey of matching packets to a file. Must be scoped with a packet filter to avoid SPU performance impact. Packet filter (traceoptions) A source/destination IP filter applied to traceoptions that limits logging to packets matching those criteria, preventing trace output from flooding the SPU. show security policies hit-count Command that lists every security policy rule with the number of times it has matched traffic. Zero hits = shadowed or dead rule. Asymmetric routing Condition where forward and return packets traverse different SRX interfaces or nodes. The return packet finds no session entry and is silently dropped (no-reverse-route). ALG (Application Layer Gateway) SRX feature that inspects control-channel protocols (SIP, FTP, H.323) to dynamically open pinholes for their data channels. Detected and configured on the first path. Session table exhaustion Condition where active sessions reach the platform maximum. New first-path connections are silently dropped — no policy log. Detected with show security flow session summary. RT: Token that appears in security-flow traceoptions output indicating the packet was dropped by a security policy deny action at first-path processing. #### 📚 Sources Juniper Networks — Traffic Processing on SRX Series Firewalls Overview (first path, fast path, session table) . juniper.net/documentation/us/en/software/junos/flow-packet-processing/topics/topic-map/security-srx-devices-processing-overview.html - Juniper Networks — Monitoring Security Flow Sessions — show security flow session reference . juniper.net/documentation/us/en/software/junos/flow-packet-processing/topics/topic-map/security-flow-session-and-error-handling.html - Juniper Networks — traceoptions (Security Flow) — configuration reference . juniper.net/documentation/us/en/software/junos/flow-packet-processing/topics/ref/statement/security-edit-traceoptions-flow.html - Juniper Networks — Monitoring and Troubleshooting Security Policies — show security policies hit-count . juniper.net/documentation/us/en/software/junos/security-policies/topics/topic-map/monitoring-troubleshooting-security-policy.html - Juniper Networks — Flow-Based Sessions on SRX Series Devices . juniper.net/documentation/us/en/software/junos/flow-packet-processing/topics/topic-map/security-flow-based-session-for-srx-series-devices.html - Juniper Networks — Express Path Overview (fast-path acceleration) . juniper.net/documentation/us/en/software/junos/flow-packet-processing/topics/topic-map/security-express-path.html ### What's next? Mastered the flow engine? Next, go deep on Juniper SRX security zones, address books and policy hierarchy — why zone ordering matters and how to build a clean policy set without shadow rules. Next · All interview lessons → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt