Technical Note: Session TTL values and Policy RST for Sessions

[FiFa_FTNT]

Purpose

There are many places in the configuration to set session-TTL.  The purpose of this document is to explain the available options and to explain how session-TTL is actually enforced.    

Expectations, Requirements

FortiOS v5.0, v5.2 or v5.4 is deployed, and traffic is traversing the FortiGate to an external resource.    

Configuration
There are many places in the configuration to set session-TTL.  The value which is actually applied to a specific session follows the hierarchical rules outlined below.

Session-TTL values are selected in the following order

1) Application Control Sensor entry (if applicable) #   <--- Highest level

2) Custom Service (if applicable)

3) Policy (if applicable)

4) System #   <--- Lowest level

When configured, upper levels override lower levels.

By default:

• the Application Control,  Custom Service, and Policy level TTL arguments are undeclared. 
• only the system value is configured/applicable.
  
  

SAMPLE CONFIGURATION:

 --------------  Begin Application Control Sensor entry example:

(root) # conf application list
(list) # edit App-Sensor-SSH-Monitor
(App-Sensor-SSH-M~tor) # conf entries
(entries) # edit 1
(1) # show

config entries

    edit 1
        set category 7 15
        set action pass
        set session-ttl 7200
    next
end

--------------  End Application Control Sensor entry example. 

--------------   Begin Custom Service config example:

 (vdom)
config firewall service custom
edit "SSH"
set category "Remote Access"
set tcp-portrange 22
set session-ttl 600
next
end 

-------------- End Custom Service config example:

---------------Begin Firewall Policy config example: 

(root) # conf firewall policy
(policy) # edit 10
(10) # show
config firewall policy
edit 10
set uuid 43fb62ac-95d6-51e4-234b-7f454fa4824a
set srcintf "Lab"
set dstintf "port3"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "SSH"
set utm-status enable
set logtraffic all
set session-ttl 300
set timeout-send-rst enable   <<<  when the RST is sent is related to the actual session-ttl applicable to the session*
set application-list "App-Sensor-SSH-Monitor"
set profile-protocol-options "default"
set ssl-ssh-profile "deep-inspection-5-0"
next
end

* determination of the actual session-ttl follows the rules outlined in this article but a RST is still sent regardless of which session-TTL is the one used

---------------End Firewall Policy config example.

---------------Begin System config example for v5.0 or v5.2:

(global) # sys session-info ttl
list session timeout:
Default timeout=3600 

--------------  End System config example.

---------------Begin System config example for v5.4:

# show full system session-ttl

config system session-ttl
  set default 3600
end

--------------  End System config example.

Verification
Scenario #1

1) Application Control, set to 7200.
2) Custom Service SSH, set to 600.
3) Firewall Policy, set to 300.
4) System Setting, set to 360.

Launch an SSH connection to a resource behind the FortiGate and then query the session table for sessions relating to Policy ID # 10.

Here we can see the timeout is determined by the Application Control level, and the session will expire in 7200 seconds. 

(global) # get sys session-info list | grep -B 12 policy_id=10

session info: proto=6 proto_state=01 duration=102 expire=7100 timeout=7200 flags=00000010 sockflag=00000000 sockport=0 av_idx=0 use=3

origin-shaper=

...

pos/(before,after) 0/(0,0), 0/(0,0)

misc=0 policy_id=10 auth_info=0 chk_client_info=0 vd=0

As instructed via the policy invocation of the set timeout-send-rst argument,  the SSH client would receive a RST at the session timeout of { timeout=7200}, which would override any TTL values denoted for the policy. 

Scenario #2

Assume another change is made and consider the following scenario:

1) Application Control, values are left unset/undeclared.
2) Custom Service SSH, set to 600.
3) Firewall Policy, set to 300.
4) System Setting, set to 3600.

As before, launch an SSH connection to a resource beyond the FortiGate and then query the session table for sessions relating to Policy ID 10.

Here we can see the session timeout is now determined by the Custom Service level, and the session will expire in 600 seconds.  

(global) # get sys session-info list | grep -B 12 policy_id=10

session info: proto=6 proto_state=01 duration=12 expire=590 timeout=600 flags=00000010 sockflag=00000000 sockport=0 av_idx=0 use=3
...
pos/(before,after) 0/(0,0), 0/(0,0)
misc=0 policy_id=10 auth_info=0 chk_client_info=0 vd=0

 ---

Verifying that a TCP Reset is sent

To observe the RST from the FortiGate, run the following from the CLI:  diag sniff pack any "tcp[13] & 4 != 0"

Related Articles

Troubleshooting Tip: FortiGate session table information