SRX

last person joined: 14 hours ago 

Ask questions and share experiences about the SRX Series, vSRX, and cSRX.
  • 1.  What happens when TCP Idle Timeout is reached?

    Posted 05-27-2011 05:44

    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

     



  • 2.  RE: What happens when TCP Idle Timeout is reached?

    Posted 05-27-2011 05:54

    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-service/td-p/63011

     

    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.



  • 3.  RE: What happens when TCP Idle Timeout is reached?

    Posted 05-27-2011 06:57

    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,