<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Old connection with looping TTL in General Topics</title>
    <link>https://community.checkpoint.com/t5/General-Topics/Old-connection-with-looping-TTL/m-p/84390#M17030</link>
    <description>&lt;P&gt;Can you confirm that NO traffic on that tuple is being received (eg with fw monitor or tcpdump)?&lt;/P&gt;</description>
    <pubDate>Thu, 07 May 2020 03:12:43 GMT</pubDate>
    <dc:creator>PhoneBoy</dc:creator>
    <dc:date>2020-05-07T03:12:43Z</dc:date>
    <item>
      <title>Old connection with looping TTL</title>
      <link>https://community.checkpoint.com/t5/General-Topics/Old-connection-with-looping-TTL/m-p/84013#M16988</link>
      <description>&lt;P&gt;Hello everybody,&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;Anyone has seen that before ?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thank you very much for your help.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;From fwaccel conss command:&lt;/P&gt;&lt;P&gt;&lt;FONT face="courier new,courier"&gt;172.31.3.132 443 192.168.83.76 42245 6 ............... 4/2 2/4 1 0 778400849 0 0 64194/64200&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="courier new,courier"&gt;192.168.83.76 42245 172.31.3.132 443 6 .........L..... 4/2 2/4 1 0 778400849 0 0 64194/64200&lt;/FONT&gt;&lt;/P&gt;&lt;P&gt;&lt;FONT face="courier new,courier"&gt;172.31.3.132 443 192.168.83.76 42245 6 ............... 4/2 2/4 1 0 778400849 0 0 374/512&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="courier new,courier"&gt;192.168.83.76 42245 172.31.3.132 443 6 .........L..... 4/2 2/4 1 0 778400849 0 0 374/512&lt;/FONT&gt;&lt;/P&gt;&lt;P&gt;&lt;FONT face="courier new,courier"&gt;172.31.3.132 443 192.168.83.76 42245 6 ............... 4/2 2/4 1 0 778400849 0 0 372/512&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="courier new,courier"&gt;192.168.83.76 42245 172.31.3.132 443 6 .........L..... 4/2 2/4 1 0 778400849 0 0 372/512&lt;/FONT&gt;&lt;/P&gt;&lt;P&gt;&lt;FONT face="courier new,courier"&gt;172.31.3.132 443 192.168.83.76 42245 6 ............... 4/2 2/4 1 0 778400849 0 0 16/151&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="courier new,courier"&gt;192.168.83.76 42245 172.31.3.132 443 6 .........L..... 4/2 2/4 1 0 778400849 0 0 16/151&lt;/FONT&gt;&lt;/P&gt;&lt;P&gt;&lt;FONT face="courier new,courier"&gt;172.31.3.132 443 192.168.83.76 42245 6 ............... 4/2 2/4 1 0 778400849 0 0 64188/64200&lt;/FONT&gt;&lt;BR /&gt;&lt;FONT face="courier new,courier"&gt;192.168.83.76 42245 172.31.3.132 443 6 .........L..... 4/2 2/4 1 0 778400849 0 0 64188/64200&lt;/FONT&gt;&lt;/P&gt;</description>
      <pubDate>Mon, 04 May 2020 08:57:36 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/Old-connection-with-looping-TTL/m-p/84013#M16988</guid>
      <dc:creator>itcs</dc:creator>
      <dc:date>2020-05-04T08:57:36Z</dc:date>
    </item>
    <item>
      <title>Re: Old connection with looping TTL</title>
      <link>https://community.checkpoint.com/t5/General-Topics/Old-connection-with-looping-TTL/m-p/84390#M17030</link>
      <description>&lt;P&gt;Can you confirm that NO traffic on that tuple is being received (eg with fw monitor or tcpdump)?&lt;/P&gt;</description>
      <pubDate>Thu, 07 May 2020 03:12:43 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/Old-connection-with-looping-TTL/m-p/84390#M17030</guid>
      <dc:creator>PhoneBoy</dc:creator>
      <dc:date>2020-05-07T03:12:43Z</dc:date>
    </item>
    <item>
      <title>Re: Old connection with looping TTL</title>
      <link>https://community.checkpoint.com/t5/General-Topics/Old-connection-with-looping-TTL/m-p/87200#M17503</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;I'm sorry for my late answer. I was some days off.&lt;/P&gt;&lt;P&gt;First of all, thank you for your answer.&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;For this connection, we ended deleting it manually.&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;Regards.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 03 Jun 2020 16:30:38 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/Old-connection-with-looping-TTL/m-p/87200#M17503</guid>
      <dc:creator>itcs</dc:creator>
      <dc:date>2020-06-03T16:30:38Z</dc:date>
    </item>
  </channel>
</rss>

