Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[SRX] How to prevent TCP sessions from being removed from session table

0

0

Article ID: KB34994 KB Last Updated: 03 Apr 2021Version: 2.0
Summary:

This article explains how to clear a particular TCP session from the session table only when the client closes the application, regardless of the protocol timeout.

Symptoms:

Some applications may be ended by the SRX for inactivity when the application session is still in use.

Cause:

Some applications were not written to take into account the fact that most modern networks use stateless firewalls. These applications may not keep their sessions alive and allow the industry standard timeouts to close the session that the application is still used.

Solution:

By default, TCP has a session timeout of 1800 seconds. However, there can be a requirement where the TCP session in the SRX has to be timed out only when the clients close the application. Until then, the session should be present in the SRX's session table.

If the application behavior cannot be changed, adjust the timeout up to a reasonable time. The SRX allows the application timeout to be increased to up to 24 hours.

Configuration:

  1. Create a custom application and include the inactivity-timeout for the desired application to never

    set applications application HTTPS protocol tcp
    set applications application HTTPS destination-port https
    set applications application HTTPS inactivity-timeout 86400
  2. Call the custom application under the security policy.

    set security policies from-zone trust to-zone untrust policy TRUST-TO-UNTRUST match source-address any
    set security policies from-zone trust to-zone untrust policy TRUST-TO-UNTRUST match destination-address any
    set security policies from-zone trust to-zone untrust policy TRUST-TO-UNTRUST match application HTTPS
    set security policies from-zone trust to-zone untrust policy TRUST-TO-UNTRUST then permit

Verification:

The timeout value is displayed as -1 which indicates the session never times out. As soon as the browser is closed, the sessions are cleared from the session table:

root@SRX> show security flow session destination-port 443
Sep 01 18:39:21
Session ID: 19777, Policy name: TRUST-TO-UNTRUST/6, Timeout: 86400, Valid
  In: 172.16.31.110/63709 --> 172.217.26.164/443;tcp, Conn Tag: 0x0, If: ge-0/0/0.0, Pkts: 11, Bytes: 1396,
  Out: 172.217.26.164/443 --> 10.219.19.97/19514;tcp, Conn Tag: 0x0, If: ge-0/0/1.0, Pkts: 14, Bytes: 4166,

Session ID: 19778, Policy name: TRUST-TO-UNTRUST/6, Timeout: 86359, Valid
  In: 172.16.31.110/63710 --> 172.217.26.164/443;tcp, Conn Tag: 0x0, If: ge-0/0/0.0, Pkts: 70, Bytes: 5875,
  Out: 172.217.26.164/443 --> 10.219.19.97/15537;tcp, Conn Tag: 0x0, If: ge-0/0/1.0, Pkts: 127, Bytes: 116282,

root@SRX> show security flow session destination-port 443
Sep 01 18:39:35
Total sessions: 0


In some cases, it is decided to use inactivity-timeout never. This should only be used in very extreme circumstances where TCP sessions may be expected to pass no traffic at all for more than 24 hours and restarting that session is very disruptive.

In these cases, the policy should be extremely specific. Where possible, the source and destination addresses should be /32 and the destination port should be one specific port.

CAUTION: This should never be used for UDP. UDP sessions can be restarted from the SRX without the endpoints knowing the SRX has closed the session. Additionally, UDP has no control messages and the SRX will never have cause to clear the session.
The danger in using a inactivity-timeout never is that it can fill the session table and then prevent other traffic from creating sessions. This can also prevent NAT pools from clearing, resulting in NAT exhaustion.
 

Modification History:
2021-03-23: Updated content and added caution message.

Related Links

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search