Julien, what you talk about is an entirely different story. IIRC, SRX handles TCP RST differently than ScreeOS when a server closes a session. I don't remember all the details, but something like not passing TCP RST back to the user, just closing a session or something.
On the user experience side it looks like a hung session in at least GNU/Linux clients instead an expected "connection reset by remote side". But this has nothing to do with the original topic, which is, I would say, is something related to broken routing. 13.11.2012 10:08 пользователь "Julien Goodwin" <jgood...@studio442.com.au> написал: > On 12/11/12 16:03, Tim Eberhard wrote: > > Benny, > > > > I've been working with the SRX since before it was in beta loading it > > up on a SSG550-M and netscreen previous to that. TCP keep alives, or > > any tcp packet that transverses that session has ALWAYS reset the > > timeout. The only time where you would see this "not working" is if > > you had a situation of asymmetric routing or some time of crazy load > > balancing through firewalls. > > All I can say is that as of late 2009 on branch SRX (specifically > SRX650, using then-current JunOS, probably 9.5) this was not the case > with SSH traffic (which IIRC doesn't have an ALG). > > It wouldn't kill the session, just wouldn't extend it. > > > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp