Skip to main content
jmlux
jmlux
New Member
February 12, 2016
Solved

Session timeout/TTL expiration counter not updated?

  • February 12, 2016
  • 2 replies
  • 18517 views

Hi,

 

"diag sys session list" shows this:

 

 
 
 
session info: proto=6 proto_state=01 duration=722 expire=28077 timeout=28800 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=3
origin-shaper=
reply-shaper=
per_ip_shaper=
ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/7
state=log may_dirty npu synced none log-start
statistic(bytes/packets/allow_err): org=1031/6/1 reply=659/6/1 tuples=2
orgin->sink: org pre->post, reply pre->post dev=31->41/41->31 gwy=192.168.x.x/192.168.y.y
hook=pre dir=org act=noop 172.x.x.x:61697->192.x.x.x:1521(0.0.0.0:0)
hook=post dir=reply act=noop 192.x.x.x:1521->172.x.x.x:61697(0.0.0.0:0)
pos/(before,after) 0/(0,0), 0/(0,0)
misc=0 policy_id=1 auth_info=0 chk_client_info=0 vd=4
serial=00863f17 tos=ff/ff ips_view=0 app_list=0 app=0
dd_type=0 dd_mode=0
npu_state=0x003000
npu info: flag=0x81/0x81, offload=8/8, ips_offload=0/0, epid=128/129, ipid=129/128, vlan=0x801e/0x801c
vlifid=129/128, vtag_in=0x001e/0x001c in_npu=1/1, out_npu=1/1, fwd_en=0/0  
After that I perform some activity. I clearly see using Wireshark that the corresponding IP/port src/dest is used (PSH/ACK, etc.)
However the session expiry timer does not seem to be updated:
 

session info: proto=6 proto_state=01 duration=895 expire=27904 timeout=28800 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=3
origin-shaper=
reply-shaper=
per_ip_shaper=
ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/7
state=log may_dirty npu synced none log-start
statistic(bytes/packets/allow_err): org=1031/6/1 reply=659/6/1 tuples=2
orgin->sink: org pre->post, reply pre->post dev=31->41/41->31 gwy=192.168.x.x/192.168.y.y
hook=pre dir=org act=noop 172.x.x.x:61697->192.x.x.x:1521(0.0.0.0:0)
hook=post dir=reply act=noop 192.x.x.x:1521->172.x.x.x:61697(0.0.0.0:0)
pos/(before,after) 0/(0,0), 0/(0,0)
misc=0 policy_id=1 auth_info=0 chk_client_info=0 vd=4
serial=00863f17 tos=ff/ff ips_view=0 app_list=0 app=0
dd_type=0 dd_mode=0
npu_state=0x003000
npu info: flag=0x81/0x81, offload=8/8, ips_offload=0/0, epid=128/129, ipid=129/128, vlan=0x801e/0x801c
vlifid=129/128, vtag_in=0x001e/0x001c in_npu=1/1, out_npu=1/1, fwd_en=0/0
 
Why can that be?
 
Bye,
Marki
 
    Best answer by ede_pfau
    But the FGT doesn't seem to count any traffic bytes between both snapshots. Could be a misleading status because of NP-offloading.
    Does the session really expire then (you could test that after setting a lower value for the session TTL)?
    2 replies
    ede_pfau
    SuperUser
    ede_pfauAnswer
    SuperUser
    February 12, 2016
    But the FGT doesn't seem to count any traffic bytes between both snapshots. Could be a misleading status because of NP-offloading.
    Does the session really expire then (you could test that after setting a lower value for the session TTL)?
    jmlux
    jmluxAuthor
    New Member
    February 12, 2016
    I tried with a telnet session set to 300 seconds TTL. There seems to be no reset of the counter if you create traffic right after the connection has been established. Strange. Or there is some lag with the update. But I don't think so because the counter either seems to be updated immediately or never. Just not during the first 20 seconds or so.
     
    The connection in question previously has been offloaded, right. It seems to behave similarly, however the initial period where no update occurs seems to be way larger than 20 seconds. But its timeout is also higher (28800s).
    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    February 13, 2016
    Nice debugging. I think the latency at the start is related to the offloading, and it's duration is relative to the TTL of that policy (apparantly >20%).
    One thing missing is to check if the session really expires because of the missing reset, or if this really is a lack of timely updating the GUI or the counters. Maybe you could look into this, too. If the session expires, ongoing traffic would open a new session, so the session ID would change. Or you could directly observe a session setup in 'diag deb flow'.
     
    IMHO Fortinet should be made aware of this, and one way would be to open a ticket. Combined with a note that either the displayed values are stale (but the TTL mechanism as such is working correctly), or there is a lack of internally updating them (which would mean a shorter TTL than specified/wanted). I'd think the former is the case.
    jmlux
    jmluxAuthor
    New Member
    February 13, 2016
    Ok, here is the missing experiment: I tested using a TELNET session with manually set ttl=300 seconds in the policy.
    [ul]
  • t=0s: session is established
  • t=10s: traffic is generated, expire counter is NOT reset to expire=300 but remains at expire=290
  • t=301s: traffic is generated, session is dropped[/ul]
    This is wrong behavior as there was traffic at t=10s, so the connection should be valid until t=310s because the TTL is 300s.  BTW this is a FG400D with FOS 5.2.6. Can someone confirm this on their devices?  I'm not really keen on talking to support anymore because their policy seems to be that everything is a feature and there are no bugs as everything is hardcoded and therefore can't be changed ;) Well, we'll see.  
    • emnoc
    emnoc
    New Member
    February 13, 2016
    Good job , did you do a telnet to the unit or a host behind the  unit? I'm sure the outcome would be different. I tested this under   5.2.1 and 5.0.11 on a FGT100D. I have access to a 140D , 600D and 3240C but none are running  5.2.6
     
     
    
        
                                                
    
        
    
    
    

            
    
                                        
    
            
                        
    
                                                                                                            
            
    

    

    

        
    
                    
    
    
    
    

    

    
    
    

                                        
    
                                                        
    
            
        
    
    

    

    

                                    
    Terms & ConditionsAccessibility statement