Skip to main content
alif
Staff
Staff
May 15, 2015

Technical Tip : Session helpers and expectation sessions

  • May 15, 2015
  • 0 replies
  • 43391 views

Description


This article describes how session helpers set up expectation sessions. Session helpers in FortiOS provide basic Application Layer Gateway functionality. 

 

Scope

 

FortiGate.


Solution


Session helpers keep track of the communication of Layer-7 protocols, such as FTP (passive), DCE-RPC, or SIP, and will dynamically open up ports as required for the communication.
The record of these dynamic ports is recorded by the session helpers in the expectation session table.

An expectation session is a pseudo-session created by the session helper for the ports negotiated by the upper-layer protocols.
Depending on the protocol, the expectation session will usually timeout after 30 seconds, or have no strict timeout set, and track the state of the parent session. If no strict timeout is set, the expectation session list can show a negative expiry value.

If the expectation session is removed before any matching traffic is seen (either by timeout or the parent session closing), the dynamic pinhole is closed.

The following debug commands can be executed to verify that the session helper is opening up the ports as required. This example will use FTP (Control traffic TCP port 21).


diagnose debug flow filter clear
diagnose debug flow filter port 21
diagnose debug enable
diagnose debug flow trace start 6

 

This debug flow trace can show if the session helper is running for the particular traffic or not.

 

id=13 trace_id=1098 msg="vd-root received a packet(proto=6, 10.1.1.2:53541->93.157.14.94:21) from internal1.flag
id=13 trace_id=1098 msg="Find an existing session, id-008423f4, original direction"
id=13 trace_id=1098 msg="SNAT 10.1.1.2->172.17.97.24:53541"
id=13 trace_id=1098 msg="run helper-ftp(dir=original)"

 

The pinhole ports that the session helper opened can be verified using the following command to list the expectation session:

 

FGT # diagnose sys session filter policy 25 <-- Firewall policy handling original control traffic.

FGT # diagnose sys session list expectation
session info: proto=6 proto_state=00 duration=6 expire=23 timeout=3600 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=3
origin-shaper=
reply-shaper=
per_ip_shaper=
ha_id=0 policy_dir=1 tunnel=/
state=new npu acct-ext complex
statistic(bytes/packets/allow_err): org=0/0/0 reply=0/0/0 tuples=2
orgin->sink: org pre->post, reply pre->post dev=5->7/7->5 gwy=10.1.1.2/172.17.97.3
hook=pre dir=org act=dnat 93.157.14.94:0->172.17.97.24:60456(10.1.1.2:53584)
hook=pre dir=org act=noop 0.0.0.0:0->0.0.0.0:0(0.0.0.0:0)
pos/(before,after) 0/(0,0), 0/(0,0)
misc=0 policy_id=25 id_policy_id=0 auth_info=0 chk_client_info=0 vd=0
serial=008423f4 tos=ff/ff ips_view=0 app_list=0 app=0
dd_type=0 dd_mode=0
per_ip_bandwidth meter: addr=10.1.1.2, bps=223
npu_state=00000000
npu info: flag=0x00/0x00, offload=0/0, ips_offload=0/0, epid=0/0, ipid=0/0, vlan=0/0

 

Firewall Policy Matching:

In the example above, the value 'policy_id=25' in the expectation session list is a value copied from the original TCP port 21 parent session. Child expectation sessions inherit policy_id and session serial number from the parent active session. If matching remote traffic is seen and generates forward traffic logs, the logs will contain the original policy ID. However, this does not mean the traffic actually matched the firewall policy. 

Once an expectation session is created, it acts as a pinhole on the firewall policy (typically, in the reverse direction to the control traffic). Traffic matching the expected session does not need to match or be allowed by the firewall policy to be forwarded by the system. If the parent session is cleared, all associated expectation sessions are cleared as well. To establish the connection, a new helper session needs to be established.

If it is required that firewall policies be explicitly matched for all traffic between the source and destination hosts, including both control and data traffic, then the corresponding helper must be deleted, and required services should be appropriately configured in a corresponding firewall policy. This is not generally recommended, since it may require configuring an additional firewall policy in the reverse direction. Generally, opening these additional ports on the firewall statically using firewall policy is more permissive than allowing the session helper to operate and open and close pinholes dynamically.


Related article:
Technical Tip: DCERPC session-helper not creating expectation sessions when using 'Packet privacy'