SRX

Short question: Is there any Juniper document (or TCP RFC or anything comparable) that would count as an "official reasoning" why the idle timeout defaults for applications in SRX are what they are?

Basically it seems that many home-brew firewall devices never kill the idle sessions or leave them hanging out there for 24 hours or even longer times, and after changing to Juniper devices the application administrators start complaining of their badly-written software dying because of lost connections.

I would love to have an "official" copy-paste answer to those instead of explaining it from the scratch over and over again. 99% of the problems can be resolved by properly closing the unused connections or enabling keepalives anyway.

Seems like I couldn't find any such document so far.

Hi stnz,

have a look at: IETF - rfc793

Best Regards

NULL

Thanks, although I did check that out before asking the question, and it did not exactly fit the need. It does not set any recommended timeout values or anything like that, for example.

---

@stnz wrote:

Thanks, although I did check that out before asking the question, and it did not exactly fit the need. It does not set any recommended timeout values or anything like that, for example.

---

I don't think there's really any one definitive answer for that question.

It's universally-agreed that firewalls need to time out idle sessions at some point, but it's not universally-agreed what that point should be.

It all comes down to the people who make the firewalls and the judgement calls of their engineers as to what a reasonable timeout is.

Cisco's defaults are not the same as Juniper's, which are not the same as Palo Alto's, which are not the same as Checkpoint's... etc.

Different firewalls have different capabilities and limits on concurrent sessions, and some are more aggressive than others on aging out idle sessions to free up space in the session tables.

I usually just use the simplest answer I can when I get a question like that -- "All firewalls must age out idle sessions at some point, because they have finite resources.  The engineers make a judgement as to the optimal way to tune their particular devices as best as they can."

Beyond that, defaults can be modified to work around edge cases -- but that's not a replacement for smarter application design.  It's not that hard to send a keepalive, or close your TCP session after you're done with it for a while and open another one next time you need it... or at least CHECK if the connection is still there before assuming it is and just sending data over a TCP connection you opened 8 hours ago... LOL

Ok, thanks. That much I pretty much knew already, I was just looking for a written manufacturer opinion of the issue, to make it easier to explain it to the not-so-technical application admins. 🙂

Anyway, I guess I have to continue giving self-written explanations then. If anybody ever happens to find such a document, feel free to post it here as I think I'm not the only one having to answer those questions.

And yea, I know the predefined applications can be modified but as far as I know that doesn't apply to the "any" application, right? So, in many cases it would require excessive amounts of extra policies to fix the timeout issues. And in most cases it is much easier to fix the application behaviour.

Unfortunately I don't have an answer to your question.  But if it's of any help per-application timeouts can be modified with custom applications, as follows:

applications {
    application a1 {
        term t1 protocol tcp destination-port 1234 inactivity-timeout 28800;
    }
}

 http://www.juniper.net/techpubs/en_US/junos12.1x44/topics/concept/policy-application-timeout-configuration-lookup-understanding.html

Thanks!