I am really having trouble to get our SRXes to log sessions that are not in the state table and get dropped because of that.

For example, if you reboot the firewall and some old NFS implementation keeps sending traffic through the same session, once the SRX comes back it drops those packets because it didn't see a three-way-handshake. However, it doesn't log those drops. Yes, logging on the cleanup rule is enabled.

  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.
    – Ron Maupin
    Commented Jan 5, 2021 at 1:47

3 Answers 3


Packets should be classified regardless of the TCP handshake being watched or not. If there isn't a session defined for that flow (fast path) a new one should be created (first path).

Do you have any screen configured?? Maybe it's the screen that's dropping the traffic.

More details on Troubleshooting Traffic Flows and Session Establishment

Maybe you can configure a log file with traceoptions:

security {
  flow {
        traceoptions {
            file trace_file;
            flag basic-datapath;
            packet-filter Match {
                protocol tcp;
                source-prefix <source-ip>;
                destination-prefix <dest-ip>;
                destination-port <tcp-port>;

Beware of these traces, since it can cause high CPU load on the SRX if it's carrying a lot of traffic. Limit the filter as much as possible and run it during a maintenance window.

  • Thanks Diego. There are no screens. Traffic is allowed as per policy. We opened a case with Juniper for this and they confirmed that the SRX is unable to log out-of-state sessions that have been dropped. Unbelievable. Commented May 13, 2013 at 12:12

As a temp work around you could always disable tcp-syn-checking with will allow the traffic to return if it matches security policy but does not have a proper 3 way set up already complete. Basically it will allow a data packet to create a session.

This is less secure and not ideal, but in the short term til you get your stuff fixed it maybe a viable work around.

Additional info: http://www.juniper.net/techpubs/software/junos-security/junos-security10.2/junos-security-swconfig-security/topic-44055.html


  • I know I can turn it off. I am looking for a way to log these "violations". Every cheap firewall on the market does that, so the SRX should be able to do so too? Commented May 17, 2013 at 17:45

I'd be curious to test this or see it documented somewhere. I've seen logs that appeared to be out of state sessions, or that is at least what I interpreted them as so it would surprise me to find that out.

  • JTAC have confirmed to me that the SRX is unable to log out of state sessions. You can check some counters, but they are global and do not contain any information on the actual session's that were blocked. Commented May 31, 2013 at 7:11
  • Perhaps we're talking about two different things then. I'm referring to syslog for denied connections, and you appear to be talking about counters. I believe that out of state sessions would be shown as a normal deny in syslog. Commented May 31, 2013 at 15:41
  • No, we are talking about the same thing. I am talking about connections that were denied because they are out of state (no syn packet first). These connections are NOT logged. Neither in syslog nor on-box. I had this confirmed by JTAC. I would love to proven wrong about this (that's why I created this thread in the first place). Commented Jun 2, 2013 at 14:40
  • Just for reference , firewalls don't log sessions that are discarded before reaching the state table by design , to avoid a DDOS attack increasing the logging for the device so much that it causes service disruption. ( similar to a re-protect filter ) a specific flow trace log will log all packets , but as Diego stated its cpu intensive.
    – DrBru
    Commented Jul 9, 2013 at 18:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.