<?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 Byte swapping needed on packet captures taken from tunnel interfaces in Next-Generation Firewall Discussions</title>
    <link>https://live.paloaltonetworks.com/t5/next-generation-firewall/byte-swapping-needed-on-packet-captures-taken-from-tunnel/m-p/1086729#M5415</link>
    <description>&lt;P&gt;I noticed something odd with packet captures taken involving traffic originating from a tunnel interface (used for GP VPN clients) where the Ethernet Type header was byte swapped. Meaning instead of 0x0800 it was 0x0008.&lt;/P&gt;
&lt;P&gt;The screen snips illustrate the raw exported packets from a NGFW running 11.1.4-h1. Wireshark 4.4.3 with no packet dissector/decode rules.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;But using Hxd to byte swap the length field then allows Wireshark to make full sense of the packet. Seems to me that PANOS is writing out that field as little-endian rather than the network-byte order of big endian.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Why does this happen? Not sure if I need to raise a support ticket or a defect/enhancement request ticket for this. Happens reproducibly across multiple packet captures.&lt;/P&gt;</description>
    <pubDate>Fri, 17 Jan 2025 02:02:28 GMT</pubDate>
    <dc:creator>Luke_Godwin</dc:creator>
    <dc:date>2025-01-17T02:02:28Z</dc:date>
    <item>
      <title>Byte swapping needed on packet captures taken from tunnel interfaces</title>
      <link>https://live.paloaltonetworks.com/t5/next-generation-firewall/byte-swapping-needed-on-packet-captures-taken-from-tunnel/m-p/1086729#M5415</link>
      <description>&lt;P&gt;I noticed something odd with packet captures taken involving traffic originating from a tunnel interface (used for GP VPN clients) where the Ethernet Type header was byte swapped. Meaning instead of 0x0800 it was 0x0008.&lt;/P&gt;
&lt;P&gt;The screen snips illustrate the raw exported packets from a NGFW running 11.1.4-h1. Wireshark 4.4.3 with no packet dissector/decode rules.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;But using Hxd to byte swap the length field then allows Wireshark to make full sense of the packet. Seems to me that PANOS is writing out that field as little-endian rather than the network-byte order of big endian.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Why does this happen? Not sure if I need to raise a support ticket or a defect/enhancement request ticket for this. Happens reproducibly across multiple packet captures.&lt;/P&gt;</description>
      <pubDate>Fri, 17 Jan 2025 02:02:28 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/next-generation-firewall/byte-swapping-needed-on-packet-captures-taken-from-tunnel/m-p/1086729#M5415</guid>
      <dc:creator>Luke_Godwin</dc:creator>
      <dc:date>2025-01-17T02:02:28Z</dc:date>
    </item>
  </channel>
</rss>

