Intermittent SaaS Stalls and a Logging Blind Spot

The absence of session-create logging is expected in event mode, which typically logs at session close rather than at session open. If the SaaS flows are long-lived, they may not close during the observation period, so no close message appears. The deny messages appear because deny logging is configured separately. To see session setup and teardown, enable stream mode logging for the relevant policy or configure session-init and session-close logging on the specific policy, then send those events to syslog. I would scope the change to the SaaS destination and the affected user group rather than logging every session. I would also verify that the syslog host and facility are correct and that the policy actually has logging enabled; a global log configuration does not automatically log every session. Stream mode gives you open and close events, which is what you need to correlate stalls with session resets, policy changes, or application timeouts.

That plan is too broad for a 30-minute production window. Unfiltered flow tracing on a 1 Gbps edge with tens of thousands of sessions can generate large trace files, consume CPU and disk, and wrap the file before the useful event is captured. Enabling all logging can also flood syslog, overwhelm the server, and make correlation harder. A better plan is a targeted flow trace with a packet filter for one or two affected client IPs and the SaaS destination, limited in duration, and with a file size cap. Enable session logging only for the relevant policy. Capture interface statistics and flow session counts at the same time. If the stalls are caused by session timeouts, the trace should show whether the SRX receives a reset, drops a packet, or simply stops seeing traffic. The goal is a narrow, reversible diagnostic, not maximum data volume.

Start with the flow session for the affected client and SaaS destination: look at the state, timeout, policy, NAT, and whether the session is active or pending. Check flow trace output for drops, policy denies, and TCP state transitions. Examine interface statistics for drops, queue drops, and errors on both the trust and untrust sides, not just errors. Review NP or session counters for resource pressure, and check whether the session table is near capacity. If the SRX shows the packets leaving cleanly and returning, the problem is more likely application or path related. If the trace shows the SRX dropping or not forwarding return traffic, focus on policy, screen, UTM, or session timeout. Also compare a failing save with a successful one: if the successful flow uses a different path or source NAT, that difference is a clue. Correlate the timestamps with syslog and any ISP latency data before changing configuration.