Session timeout/TTL expiration counter not updated?

[jmlux]

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

[jmlux]

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 chan... ;) Well, we'll see.

[emnoc]

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

[jmlux]

emnoc wrote:

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

I guess the 100D is out of the question because it has no fast-path architecture like the other devices...

I tested from and to hosts behind the firewall, as that is the primary purpose of the firewall. I can test with a local connection but that doesn't matter much to me...

Update: I have tested on a 100D with 5.2.5 too. Works correctly. I'd love to have someone confirm this on a device with actual NPUs, no matter if they are running exactly FOS 5.2.6 or not.

[jmlux]

Update 2: (Update 1, see previous post) So FWIW I have also tested a local connection (SSH to the firewall itself). diag sys session list shows two connections for this:

[ul]

an unaccelerated one on VDOM vsys-hamgmt),

and another accelerated one on VDOM prod[/ul]

The first has a TTL of 3600 (default of VDOM vsys-hamgmt probably) and is updated with every event on the CLI. The second has a TTL of 43200 (default system TTL for VDOM prod) and is not correctly updated either.

[jmlux]

Hey, I just wanted to let you know that I got feedback from support about this. They confirm it, and it apparently is working as designed. You can't fully trust the counters on accelerated connections. Details are classified...