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] The application timeout value for data sessions cannot be changed when using FTP ALG

0

0

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

This article explains why the application timeout value for data sessions cannot be changed when using FTP ALG.

Symptoms:

The application timeout value can be changed by setting inactivity-timout as follows:

set applications application junos-ftptest term t1 alg ftp
set applications application junos-ftptest term t1 protocol tcp
set applications application junos-ftptest term t1 destination-port 0-65535
set applications application junos-ftptest term t1 inactivity-timeout 86400

With ALG, the control traffic timeout value changes to -1 as expected, but the data traffic does not:
 
Session ID: 9399, Policy name: LineManagementServer/6, Timeout: 86337, Valid
Resource information : FTP ALG, 1, 0
  In: 192.168.11.11/57378 --> 192.168.1.1/21;tcp, If: vlan.1, Pkts: 16, Bytes: 859
  Out: 134.237.73.252/21 --> 134.237.132.204/57378;tcp, If: vlan.2, Pkts: 12, Bytes: 826
 
Session ID: 9622, Policy name: LineManagementServer/6, Timeout: 300, Valid
Resource information : FTP ALG, 1, 1
  In: 134.237.73.252/20 --> 134.237.132.204/58717;tcp, If: vlan.2, Pkts: 9959, Bytes: 10628132
Out: 192.168.11.11/58717 --> 192.168.1.1/20;tcp, If: vlan.1, Pkts: 4975, Bytes: 199012
Cause:

This behavior is by design.The ALG looks for a message originating from the server's data channel port after the two initial messages on the control channel port had completed. When that first data channel message was received, the ALG creates a “dynamic session” for that traffic. This “dynamic session” or “pinhole” in the firewall is based on the policy that allowed the original control traffic.

The data channel traffic is expected to arrive at the firewall within a certain amount of time from the control channel establishment. If it takes longer, the pinhole would not be created as the session would have timed out. Effectively, the session that supports the pinhole is a child session of the control traffic.

Solution:

Disable ALG and add a reverse policy. Then the timeout setting can be changed.

Session ID: 9977, Policy name: LineManagementServer/6, Timeout: 86312, Valid
  In: 192.168.11.11/65302 --> 192.168.1.1/21;tcp, If: vlan.1, Pkts: 17, Bytes: 1092
  Out: 134.237.73.252/21 --> 134.237.132.204/65302;tcp, If: vlan.2, Pkts: 12, Bytes: 974
 
Session ID: 10199, Policy name: LineManagementServer-reverse/22, Timeout: 86249, Valid
  In: 134.237.73.252/20 --> 192.168.11.11/51022;tcp, If: vlan.2, Pkts: 12968, Bytes: 14838348
  Out: 192.168.11.11/51022 --> 192.168.1.1/20;tcp, If: vlan.1, Pkts: 7479, Bytes: 299172
Modification History:
2021-04-03: Updated to demonstrate the same effect without using 'timeout never'.
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