SRX Services Gateway
Showing results for 
Search instead for 
Do you mean 
Reply
chg
Contributor
Posts: 21
Registered: ‎06-24-2010
0 Kudos

What happens when TCP Idle Timeout is reached?

We had some connection issues when we exchanged a Checkpoint FW-1 with a Juniper SRX650.

 

It seems that Checkpoint behaves very different when a TCP Idle Timeout is reached:

- The default for TCP idle timeout is 1 hour on Checkpoint whereas it seems to be 4 hours on a SRX650 (10.3R2)

- Checkpoint sends a reset to the source and destination when removing a connection from the session table

 

What's the behaviour of an SRX?

Is the TCP idle timeout always 4 hours?

What does an SRX do when the timeout is reached? Silently remove it from the session table without notifying the source/destination? Is this configurable?

 

I couldn't find any hints to the above questions in this forum and in the Internet. Any feedback is welcome.

 

Regards,

Christoph

 

Distinguished Expert
Distinguished Expert
Posts: 938
Registered: ‎10-09-2008
0 Kudos

Re: What happens when TCP Idle Timeout is reached?

Hi

 

The default TCP timeout on SRX is 30 minutes (1800 sec.), not 4 hours.

Here's how to check it

http://forums.juniper.net/t5/Tech-Cafe-Current-Event/Tips-How-to-check-inactivity-timeout-for-a-serv...

 

When timeout is reached - I believe yes, it just deletes the entry without notifying the peers.

There is no option to send a TCP reset, but there is an option to disable SYN checking,

 

set security flow tcp-session no-syn-check

If you enable it then timed out sessions can be resumed - at the cost of lower security.

Best Regards,
PK

Juniper Ambassador, Juniper Networks Certified Instructor,
JNCIE-SEC #98, JNCIE-ENT #393, JNCIE-SP #2253
[Juniper Authorized Education & Support in Russia]
chg
Contributor
Posts: 21
Registered: ‎06-24-2010
0 Kudos

Re: What happens when TCP Idle Timeout is reached?

Hi pk

 

 

Thank you for the quick response.

 

Finally, we've solved the problem by enabling the keep-alive feature in the affected client.

This way we can avoid that connections get idle when they are still in use.

 

The funny part is, that we enabled strict tcp syn checking recently because of the "TCP Split Handshake Attack" described here http://kb.juniper.net/InfoCenter/index?page=content&id=KB20877

So I think it's not recommended to turn this off.

 

Regards,