Virtual session timeout

[SkipperNavy]

Hello all,

scenario: i  have a resource web that is published behind pulse secure and Checkpoint Gateway.

flow travel from pulse secure to the web server by a checkppint security gateway on a specific service.

i tried modifiyn the virtual session time out on the service but still losing session after 334 seconds.

17:48:50 5 N/A N/A a.b.c.d > N/A LogId: <max_null>; ContextNum: <max_null>; OriginSicName: <max_null>; : -----------------------------------(+); Direction: 0; Source: ip_of_pulse; SPort: 48667; Dest: server_ip; DPort: 7800; Protocol: tcp; CPTFMT_sep: ;; Type: 122881; Rule: 45; Timeout: 334; Handler: 0; Ifncin: 10; Ifncout: -1; Ifnsin: -1; Ifnsout: 9; Bits: 020000000007c800; ACT_Starttime: 24Sep2021 17:48:04; ACT_Segtime: 24Sep2021 17:48:04; ACT_Lastseen: 24Sep2021 17:48:27; ACT_Cliinpack: 16; ACT_Clioutpack: 0; ACT_Srvinpack: 30; ACT_Srvoutpack: 0; ACT_Cliinbyte: 15; ACT_Clioutbyte: 0; ACT_Srvinbyte: 32; ACT_Srvoutbyte: 0; Expires: 7182/7202; LastUpdateTime: 24Sep2021 17:48:50; ProductName: VPN-1 & FireWall-1; ProductFamily: Network;

virtual time out is configured to 7200 seconds on service tcp-7800

i verified on the pulse secure and it seems ok because it is working for other resource that is not going through the checkpoint gateway.

it seems like the gateway kill the session before attemping the idle timeout.

can you help on this issue please?

[PhoneBoy]

Looks like from what you pasted there the connection is still active in the connections table: Expires: 7182/7202

You're going to need to do some tcpdumps to see what’s actually going on with this session. 

[SkipperNavy]

Can you tell me what does "timeout: 334" means please? 

Because it correspond to the same time befaure my connection to the server is break down.

This happens only when there is no activity between the client and the server.

Thank you in advance

[PhoneBoy]

While I'm not certain exactly what it refers to, I'm fairly certain it doesn't mean what you think it means.
The "Expires" line refers to the entry in the connections table, which is the obvious first step.
There should be some other evidence of why it's failing, either in the logs, in debugs (try something like fw ctl zdebug | grep ip_of_pulse or possibly some other options from sk171943) or in packet traces why the connection is suddenly stops flowing.

[ihis_asoc_infra]

Hello 

this is very nice observation for me. 

could you please help me here how to do tcpdumps to find more about this.