Just by way of being complete, we closed the issue by enabling the Postgres
keep alive settings which now ensures the flows stay open.
There may still be a bug in there somewhere, but in true network style we'll
just pretend it's not there now we have found another solution.
Until next time...
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
Hi,
We're working with a client on a strange issue with an SRX.
The client has a Postgres application that regularly runs long queries across a
route-based IPSEC VPN connection (taking several hours to return a result).
By default the SRX closes the flow after 30 minutes (1800 seconds) as
problems.
- Original Message -
From: Andrew Yager [mailto:and...@rwts.com.au]
Sent: Monday, November 12, 2012 06:50 AM
To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
Subject: [j-nsp] Weird SRX flow timeout issue
Hi,
We're working with a client on a strange issue with an SRX
Andrew Yager and...@rwts.com.au writes:
By default the SRX closes the flow after 30 minutes (1800 seconds) as there
is no activity on the wire during this time.
I have no SRX firewalls, so I cannot help you with your actual problem,
but I can provide an ugly workaround...
If you play with
12.11.2012 15:55, James S. Smith пишет:
after the first hour (on a brand new session)
Session ID: 29151, Policy name: vpn-usa2-out-postgres/7, Timeout: 20, Valid
In: 10.2.2.5/49214 -- 192.168.2.10/5432;tcp, If: vlan.3, Pkts: 3, Bytes:
180
Out: 192.168.2.10/5432 -- 10.2.2.5/49214;tcp,
On 12/11/12 06:37, Benny Amorsen wrote:
Andrew Yager and...@rwts.com.au writes:
By default the SRX closes the flow after 30 minutes (1800 seconds) as there
is no activity on the wire during this time.
I have no SRX firewalls, so I cannot help you with your actual problem,
but I can
Julien Goodwin jgood...@studio442.com.au writes:
Sadly SRX doesn't (or at least a few years ago didn't) consider TCP
keepalives sufficient to keep the session open.
Thank you for that heads-up, that is certainly something to keep in
mind.
/Benny
While I haven't read this entire thread, it's worth mentioning that
this is a correct statement. TCP connections (by default) must be
initiated by a standard 3-way handshake. You can disabled this by
turning off tcp-syn-checking under security - flow.
I wouldn't recommend it however, as enforcing
Tim Eberhard xmi...@gmail.com writes:
While I haven't read this entire thread, it's worth mentioning that
this is a correct statement. TCP connections (by default) must be
initiated by a standard 3-way handshake. You can disabled this by
turning off tcp-syn-checking under security - flow.
I
The SRX's behavior is if any packet passes over that session to reset
the timeout on that session, keep alive, data packet, whatever. As
long as it matches that session it will reset the timeout to the
default value and start decrementing again. So I'm not sure what you
mean when it says dropping
Just as a bit of a follow on…
Early I made the assertion that I was using a route-based VPN. Of course, I
wasn't (and thanks Cooper for pointing that out to me.)
We removed the inactivity-timeout definition, tried disabling tcp sun checking
in tunnel, etc; but none of these seemed to restore
On 11/12/2012 08:34 PM, Tim Eberhard wrote:
The SRX's behavior is if any packet passes over that session to reset
the timeout on that session, keep alive, data packet, whatever. As
long as it matches that session it will reset the timeout to the
default value and start decrementing again. So I'm
Tim Eberhard xmi...@gmail.com writes:
The SRX's behavior is if any packet passes over that session to reset
the timeout on that session, keep alive, data packet, whatever. As
long as it matches that session it will reset the timeout to the
default value and start decrementing again. So I'm
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
Tim Eberhard xmi...@gmail.com writes:
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
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
17 matches
Mail list logo
