Recently a good friend of mine asked about some interesting traffic he observed in a packet capture. The capture was obtained on a SonicWall firewall and he mentioned that it looked like a bunch of Fibre Channel packets. My friend informed me that Fibre Channel was not present in the environment where the capture was performed. Let’s have a look.
The first 2 non-zero bytes are 0x45. From having analyzed IP packets before this struck me as possibly being IPv4 (0x40) with a 20 byte header (0x05) which is very common. I also noticed (as did Wireshark) that there were just enough 0x00 bytes preceding this signature to fit an Ethernet header. There are 14 bytes (6 DST MAC, 6 SRC MAC, 2 EtherType) before the IP signature that are zeroed out.
Thus I hypothesized that this frame wireshark was showing as Fibre Channel was actually an Ethernet frame carrying IP, with the Ethernet header zeroed out. To prove this theory, I had wireshark decode it as such.
- Select the entire IP payload (click on “MDS Header” in the center pane).
- Right click on the highlighted payload and select ‘Decode As’.
- Select IPv4 from the list of protocols and click Apply.
The resulting view shows that this is an IP packet carrying Encapsulating Security Payload (ESP, IP protocol 50). This seems likely as ESP is used to carry traffic for VPN tunnels, which firewalls are often an endpoint of.
The IP checksum and packet length matched up, thus it’s pretty clear this is the correct interpretation (You can enable IP checksum verification under Edit -> Preferences -> Protocols -> IPv4 -> Validate the IPv4 Checksum if possible).
My friend confirmed that the IP addresses in the newly interpreted packet were correct VPN endpoints, thus I am confident we have a good explanation of the mystery Fibre Channel packets in a non Fibre Channel network.