Interpreting fwaccel conns

[waschminator]

hi,

if i check out fwaccel conns i get 2 entries per session. fine so far. the weird thing: it is hwoing the same througput in both directions ...this is incorrect in theory. 

we are talking of a filetransfer here and i would have expected maybe 494 GB in one directon and in the other direction maybe 100Mbyte becuase this are just ACKs. can anybody explain this?

10.101.68.43 2049 10.222.242.148 34889 6 .........T.L.........  494.05GB 0s 11h28m51s 86400/86400
10.222.242.148 34889 10.101.68.43 2049 6 .........T...........   494.05GB 0s 11h28m51s 86400/86400

[PhoneBoy]

Not sure it's actually supposed to show the directional volume or not.
This probably needs a TAC case to confirm the correct/expected behavior.

[waschminator]

thx for reply. it seems that the amount of transported traffic is correct. only the bidirectional stuff seems to be incorrect. but i guess it has something todo with the way this connection is handled within this table.

let´s see if somebody else has experience. worst case i ask our support partner or vendor. 

[Timothy_Hall · Accepted solution]

The key is the "L" (link) flag on one of those entries in your screenshot.  SecureXL and Check Point in general track what we would consider a "connection" as separate flows of packets.  For a connection not subject to NAT there are just two flows (c2s and s2c).  The second line in your output is the original initiating c2s flow (looks like the 10.222 host initiated a NFS connection to 10.101), and the first line is the corresponding linked s2c response flow for that single NFS connection.  Because the two flows are linked together as being associated with the same connection, many of their elements such as consumed bandwidth, idle timeout, and duration are synchronized which is why they are the same value.

[waschminator]

thanks for this explanation and confirmation