<?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: id = 0 in fwmonitor in General Topics</title>
    <link>https://community.checkpoint.com/t5/General-Topics/id-0-in-fwmonitor/m-p/137308#M24517</link>
    <description>&lt;P&gt;While it is possible to have a capture point of &lt;STRONG&gt;id&lt;/STRONG&gt; (inbound before decrypt), the field you have circled in your screenshot is the IP Layer 3 header field "Identification", not the Layer 4 TCP sequence number.&amp;nbsp; The IP ID field is supposed to be unique for each individual packet associated with a single connection (srcip,sport,dstip,dport) in order to support fragmentation and reassembly.&amp;nbsp; All fragments of the same datagram will have an identical IP ID, and as such the reassembling system can put them back together.&amp;nbsp;&lt;/P&gt;
&lt;P&gt;However if the DF (Don't fragment) bit is set, fragmentation is not allowed and the IP ID is irrelevant.&amp;nbsp; The most common type of traffic that has DF set in my experience is ESP/IPSec.&amp;nbsp; I suspect that the DF bit is set in those packets you captured, and that is why the IP ID was left as 0 by the sending system because it simply doesn't matter.&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Here is a diagram from my Max Capture video series identifying the IP ID field, which by default is only shown from the CLI when using&amp;nbsp;&lt;STRONG&gt;fw monitor&lt;/STRONG&gt;.&amp;nbsp; I would speculate that the reason &lt;STRONG&gt;fw monitor&lt;/STRONG&gt; shows this field by default in CLI output is because the same packet is displayed many times at the various capture points, and the IP ID can be a handy visual reference to verify that several lines of output are actually the same packet, since the multiple lines for a single packet will all have the same IP ID.&amp;nbsp; Also possible that &lt;STRONG&gt;fw monitor&lt;/STRONG&gt; shows the IP ID because traffic displayed by &lt;STRONG&gt;fw monitor&lt;/STRONG&gt; has already been virtually reassembled if fragmentation is present, whereas &lt;STRONG&gt;tcpdump&lt;/STRONG&gt; and &lt;STRONG&gt;cppcap&lt;/STRONG&gt; will just show you the original fragments instead.&lt;/P&gt;
&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="tools.png" style="width: 999px;"&gt;&lt;img src="https://community.checkpoint.com/t5/image/serverpage/image-id/14724i8F047EDA320D8953/image-size/large?v=v2&amp;amp;px=999" role="button" title="tools.png" alt="tools.png" /&gt;&lt;/span&gt;&lt;/P&gt;</description>
    <pubDate>Tue, 28 Dec 2021 13:20:49 GMT</pubDate>
    <dc:creator>Timothy_Hall</dc:creator>
    <dc:date>2021-12-28T13:20:49Z</dc:date>
    <item>
      <title>id = 0 in fwmonitor</title>
      <link>https://community.checkpoint.com/t5/General-Topics/id-0-in-fwmonitor/m-p/137261#M24513</link>
      <description>&lt;P&gt;Hey guys,&lt;/P&gt;&lt;P&gt;I was using fwmonitor and I came across some information.&lt;/P&gt;&lt;P&gt;What does id = 0 mean in the fwmonitor utility?&lt;/P&gt;&lt;P&gt;I know it shows the packet's sequence number, but does the zero have any meaning?&lt;/P&gt;&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="WhatsApp Image 2021-12-27 at 10.59.54.jpeg" style="width: 400px;"&gt;&lt;img src="https://community.checkpoint.com/t5/image/serverpage/image-id/14709i05F1DE2ECC36D347/image-size/medium?v=v2&amp;amp;px=400" role="button" title="WhatsApp Image 2021-12-27 at 10.59.54.jpeg" alt="WhatsApp Image 2021-12-27 at 10.59.54.jpeg" /&gt;&lt;/span&gt;&lt;/P&gt;&lt;P&gt; &lt;/P&gt;</description>
      <pubDate>Mon, 27 Dec 2021 18:01:57 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/id-0-in-fwmonitor/m-p/137261#M24513</guid>
      <dc:creator>Marquevis</dc:creator>
      <dc:date>2021-12-27T18:01:57Z</dc:date>
    </item>
    <item>
      <title>Re: id = 0 in fwmonitor</title>
      <link>https://community.checkpoint.com/t5/General-Topics/id-0-in-fwmonitor/m-p/137266#M24514</link>
      <description>&lt;P&gt;Below might answer your question&lt;/P&gt;
&lt;P&gt;&lt;A href="https://community.checkpoint.com/t5/General-Topics/id-ID-and-OE-inspection-points-in-R80-20-GA/td-p/35176" target="_blank"&gt;https://community.checkpoint.com/t5/General-Topics/id-ID-and-OE-inspection-points-in-R80-20-GA/td-p/35176&lt;/A&gt;&lt;/P&gt;</description>
      <pubDate>Mon, 27 Dec 2021 18:31:31 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/id-0-in-fwmonitor/m-p/137266#M24514</guid>
      <dc:creator>the_rock</dc:creator>
      <dc:date>2021-12-27T18:31:31Z</dc:date>
    </item>
    <item>
      <title>Re: id = 0 in fwmonitor</title>
      <link>https://community.checkpoint.com/t5/General-Topics/id-0-in-fwmonitor/m-p/137308#M24517</link>
      <description>&lt;P&gt;While it is possible to have a capture point of &lt;STRONG&gt;id&lt;/STRONG&gt; (inbound before decrypt), the field you have circled in your screenshot is the IP Layer 3 header field "Identification", not the Layer 4 TCP sequence number.&amp;nbsp; The IP ID field is supposed to be unique for each individual packet associated with a single connection (srcip,sport,dstip,dport) in order to support fragmentation and reassembly.&amp;nbsp; All fragments of the same datagram will have an identical IP ID, and as such the reassembling system can put them back together.&amp;nbsp;&lt;/P&gt;
&lt;P&gt;However if the DF (Don't fragment) bit is set, fragmentation is not allowed and the IP ID is irrelevant.&amp;nbsp; The most common type of traffic that has DF set in my experience is ESP/IPSec.&amp;nbsp; I suspect that the DF bit is set in those packets you captured, and that is why the IP ID was left as 0 by the sending system because it simply doesn't matter.&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Here is a diagram from my Max Capture video series identifying the IP ID field, which by default is only shown from the CLI when using&amp;nbsp;&lt;STRONG&gt;fw monitor&lt;/STRONG&gt;.&amp;nbsp; I would speculate that the reason &lt;STRONG&gt;fw monitor&lt;/STRONG&gt; shows this field by default in CLI output is because the same packet is displayed many times at the various capture points, and the IP ID can be a handy visual reference to verify that several lines of output are actually the same packet, since the multiple lines for a single packet will all have the same IP ID.&amp;nbsp; Also possible that &lt;STRONG&gt;fw monitor&lt;/STRONG&gt; shows the IP ID because traffic displayed by &lt;STRONG&gt;fw monitor&lt;/STRONG&gt; has already been virtually reassembled if fragmentation is present, whereas &lt;STRONG&gt;tcpdump&lt;/STRONG&gt; and &lt;STRONG&gt;cppcap&lt;/STRONG&gt; will just show you the original fragments instead.&lt;/P&gt;
&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="tools.png" style="width: 999px;"&gt;&lt;img src="https://community.checkpoint.com/t5/image/serverpage/image-id/14724i8F047EDA320D8953/image-size/large?v=v2&amp;amp;px=999" role="button" title="tools.png" alt="tools.png" /&gt;&lt;/span&gt;&lt;/P&gt;</description>
      <pubDate>Tue, 28 Dec 2021 13:20:49 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/id-0-in-fwmonitor/m-p/137308#M24517</guid>
      <dc:creator>Timothy_Hall</dc:creator>
      <dc:date>2021-12-28T13:20:49Z</dc:date>
    </item>
  </channel>
</rss>

