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...
On 13/11/12 00:30, Pavel Lunin wrote:
> 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 sess
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
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 wo
Tim Eberhard 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 see this "not
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 situatio
Tim Eberhard 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 not sure what y
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
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 th
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 t
Tim Eberhard 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 wouldn't
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
Julien Goodwin 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
___
juniper-nsp mailin
On 12/11/12 06:37, Benny Amorsen wrote:
> Andrew Yager 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
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;
Andrew Yager 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
tcp_keepalives_cou
;s the cause of your 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
Subject: [j-nsp] Weird SRX flow timeout issue
Hi,
We're working with a client on a strange issue with an SRX.
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 there
18 matches
Mail list logo