Old connection with looping TTL

[itcs]

Hello everybody,

We’ve found that some connections are stuck for days in the connection table of one of our R80.20 gateway and that the TTL counter is looping.

You can find an example below of a session that was established on 30th April for the last time and closed in both ends since then. However, it’s still in the connections table.

Global TCP timeout session is 64800 (a high value but historically configured like that since some years ago because of problems with some peers) but in the rule for this connection, we are using a custom https service with 3600 as virtual session timeout. Then, we can’t understand why some sessions like in the example are getting the global timeout value and specially why the counter is restarting.

Anyone has seen that before ?

Thank you very much for your help.

From fwaccel conss command:

172.31.3.132 443 192.168.83.76 42245 6 ............... 4/2 2/4 1 0 778400849 0 0 64194/64200
192.168.83.76 42245 172.31.3.132 443 6 .........L..... 4/2 2/4 1 0 778400849 0 0 64194/64200

172.31.3.132 443 192.168.83.76 42245 6 ............... 4/2 2/4 1 0 778400849 0 0 374/512
192.168.83.76 42245 172.31.3.132 443 6 .........L..... 4/2 2/4 1 0 778400849 0 0 374/512

172.31.3.132 443 192.168.83.76 42245 6 ............... 4/2 2/4 1 0 778400849 0 0 372/512
192.168.83.76 42245 172.31.3.132 443 6 .........L..... 4/2 2/4 1 0 778400849 0 0 372/512

172.31.3.132 443 192.168.83.76 42245 6 ............... 4/2 2/4 1 0 778400849 0 0 16/151
192.168.83.76 42245 172.31.3.132 443 6 .........L..... 4/2 2/4 1 0 778400849 0 0 16/151

172.31.3.132 443 192.168.83.76 42245 6 ............... 4/2 2/4 1 0 778400849 0 0 64188/64200
192.168.83.76 42245 172.31.3.132 443 6 .........L..... 4/2 2/4 1 0 778400849 0 0 64188/64200

[PhoneBoy]

Can you confirm that NO traffic on that tuple is being received (eg with fw monitor or tcpdump)?

[itcs]

Hi,

I'm sorry for my late answer. I was some days off.

First of all, thank you for your answer.

We observed that the connection got the global timeout and not the custom one after a policy installation. Maybe there was a problem rematching the connection. We opened a TAC case but they would have needed to debug in real-time in order to try to understand.

About de timer looping, we saw that it was restarting when a new SYN on that tuple was received while the connection was still in the connections table. I understand then that it is the normal behaviour.

For this connection, we ended deleting it manually.

Regards.