Identification of Fragmented UDP Packets

[Eddie]

Hi,

I'm investigating an issue, where I am unable to connect to a remote
VPN, where the request is passing through pfSense, which is a FreeBSB
based firewall/NAT appliance. In order to see what's going on, I ran a
sniffer on it's LAN and WAN interfaces.

For the packets, in question, I noticed that WireShark interpreted them
differently, on each interface, and so was wondering on what basis is
that interpretation made, as if WireShark has truly misinterpreted the
packets, then it's possible the remote VPN also has. Here's what I see:

On the LAN side, a UDP request of 2220 bytes was sent, which was spread
over two packets. The first, was identified by WireShark as an IP
packet, and contained 1280 bytes of data. The "More fragments" bit is
set. The second packet, was identified as UDP/ISAKMP, containing 940
bytes of data, with no fragmentation bits set. WireShark also shows the
completely reassembled data.

Now, within pfSense, the "scrub" option attempts to reassemble the packets.

Again, on the WAN side I also see two packets, as the total length is
greater than the MTU. However, on this interface it's the 1st one that
is identified as UDP/ISAKMP, with 1480 bytes of data, and the "More
fragments" bit set. The 2nd packet is only identified as IP, with 740
bytes of data, and no fragmentation bits set. WireShark does *not* show
any reassembled data.

I've looked through the headers, and cannot see anything different
between the headers on the LAN and the WAN packets that might cause this
difference in interpretation. So, what might cause this.

Cheers.
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe

[Guy Harris]

Post by Eddie
On the LAN side, a UDP request of 2220 bytes was sent, which was spread
over two packets. The first, was identified by WireShark as an IP
packet, and contained 1280 bytes of data. The "More fragments" bit is
set. The second packet, was identified as UDP/ISAKMP, containing 940
bytes of data, with no fragmentation bits set. WireShark also shows the
completely reassembled data.

Yes. Wireshark's IP reassembly code reassembled the packets, and dissected the reassembled contents when the reassembly was complete; the reassembly is done in order, so that was done with the second packets.

The "More fragments" bit is, not surprisingly, not set on the last fragment.

Post by Eddie
Again, on the WAN side I also see two packets, as the total length is
greater than the MTU. However, on this interface it's the 1st one that
is identified as UDP/ISAKMP, with 1480 bytes of data, and the "More
fragments" bit set. The 2nd packet is only identified as IP, with 740
bytes of data, and no fragmentation bits set. WireShark does *not* show
any reassembled data.

Apparently, Wireshark *isn't* reassembling the fragments in that case.

Do the fragments have the same IP identification field?

Does Wireshark have the "Reassemble fragmented IP datagrams" flag set in both cases?

Post by Eddie
I've looked through the headers, and cannot see anything different
between the headers on the LAN and the WAN packets that might cause this
difference in interpretation.

What differences are there between the IP headers?
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe

[Eddie]

Post by Guy Harris
Yes. Wireshark's IP reassembly code reassembled the packets, and dissected the reassembled contents when the reassembly was complete; the reassembly is done in order, so that was done with the second packets.
The "More fragments" bit is, not surprisingly, not set on the last fragment.

Also, as I would have expected.

Post by Guy Harris
Apparently, Wireshark *isn't* reassembling the fragments in that case.

Yep, it 'aint doing so.

Post by Guy Harris
Do the fragments have the same IP identification field?

Yes.

Post by Guy Harris
Does Wireshark have the "Reassemble fragmented IP datagrams" flag set in both cases?

I haven't touched any of the settings since installing. But, still
checked, and yes, it's set.

Post by Guy Harris
What differences are there between the IP headers?

Like I said, none that I can see, that would make a difference:

LAN IP headers:

0000 45 00 05 14 05 d7 20 00 80 11 f3 f9 c0 a8 00 1e E..... .........
0010 ab a1 af a0 ....

0000 45 00 03 c0 05 d7 00 a0 80 11 14 ae c0 a8 00 1e E...............
0010 ab a1 af a0 ....

WAN IP headers

0000 45 00 05 dc 36 98 20 00 7f 11 a7 46 62 94 7a 5c E...6. ....Fb.z\
0010 ab a1 af a0 ....

0000 45 00 02 f8 36 98 00 b9 7f 11 c9 71 62 94 7a 5c E...6......qb.z\
0010 ab a1 af a0 ....

Is there a way to grab the interpreted version of these.

Cheers.
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe

[Guy Harris]

Post by Eddie
45

Version/IHL - version 4, 20 bytes.

Post by Eddie
00

Type of Service

Post by Eddie
05 14

Total length - 1300 bytes (1280 bytes of IP payload)

Post by Eddie
05 d7

Identification - 0x05d7

Post by Eddie
20 00

Flags and Fragment Offset: More Fragments, fragment offset = 0

Post by Eddie
80

Time to Live

Post by Eddie
11

Protocol - 17=UDP

Post by Eddie
f3 f9

Header Checksum

Post by Eddie
c0 a8 00 1e

Source Address

Post by Eddie
0010 ab a1 af a0

Destination Address

Post by Eddie
0000 45

Version/IHL

Post by Eddie
00

Type of Service

Post by Eddie
03 c0

Total length - 960 bytes (940 bytes of IP payload)

Post by Eddie
05 d7

Identification - 0x05d7, same as the previous fragment (which is as it should be)

Post by Eddie
00 a0

Flags and Fragment Offset: fragment offset=160=160*8 bytes=1280 bytes (which is as it should be, as that's the length of the previous fragment's payload)

Post by Eddie
80

Time to Live

Post by Eddie
11

Protocol - 17=UDP

Post by Eddie
14 ae

Header Checksum

Post by Eddie
c0 a8 00 1e

Source Address - same as the previous fragment (which is as it should be)

Post by Eddie
0010 ab a1 af a0

Destination Address - same as the previous fragment (which is as it should be)

Post by Eddie
WAN IP headers
45

Version/IHL

Post by Eddie
00

Type of Service

Post by Eddie
05 dc

Total length - 1500 bytes (1480 bytes of IP payload)

Post by Eddie
36 98

Identification - 0x3698

Post by Eddie
20 00

Flags and Fragment Offset: More Fragments, fragment offset = 0

Post by Eddie
7f

Time to Live

Post by Eddie
11

Protocol - 17=UDP

Post by Eddie
a7 46

Header Checksum

Post by Eddie
62 94 7a 5c

Source Address

Post by Eddie
ab a1 af a0

Destination Address

Post by Eddie
45

Version/IHL

Post by Eddie
00

Type of Service

Post by Eddie
02 f8

Total length - 760 bytes (740 bytes of IP payload)

Post by Eddie
36 98

Identification - 0x3698, same as the previous fragment (which is as it should be)

Post by Eddie
00 b9

Flags and Fragment Offset: fragment offset = 185=185*8 bytes=1480 bytes (which is as it should be, as that's the length of the previous fragment's payload)

Post by Eddie
7f

Time to Live

Post by Eddie
11

Protocol - 17=UDP

Post by Eddie
c9 71

Header Checksum

Post by Eddie
62 94 7a 5c

Source Address - same as the previous fragment (which is as it should be)

Post by Eddie
ab a1 af a0

Destination Address - same as the previous fragment (which is as it should be)

There isn't anything obvious that should cause Wireshark not to attempt reassembly, but I didn't check the IP header checksum - is Wireshark reporting IP checksum errors on any of the WAN packets?

Can you save just the two offending fragments from the WAN capture to a file? If so, when you read the file in, does it reassemble the fragments? If not, could you send us that capture, along with the version information from Wireshark?

Post by Eddie
Is there a way to grab the interpreted version of these.

Not with copy/paste, unfortunately. You could use File->Export to export the dissected version of the packets as text.
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe

[Eddie]

Post by Guy Harris
There isn't anything obvious that should cause Wireshark not to attempt reassembly, but I didn't check the IP header checksum - is Wireshark reporting IP checksum errors on any of the WAN packets?

Nope:
Header checksum: 0xa746 [correct]
Header checksum: 0xc971 [correct]

Post by Guy Harris
Can you save just the two offending fragments from the WAN capture to a file? If so, when you read the file in, does it reassemble the fragments? If not, could you send us that capture, along with the version information from Wireshark?

Not sure what you mean by this. Can you explain a little more please.

I've also uploaded a couple of screen shots, which hopefully reinforce
my descriptions of what I'm seeing. On the LAN, it's packets 16 and
17. The WAN is 17 and 18.

Loading Image...
Loading Image...

I'm running WireShark: Version 1.2.5 (SVN Rev 31296)

Cheers.
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe

[Guy Harris]

Post by Eddie

Post by Guy Harris
Can you save just the two offending fragments from the WAN capture to a file? If so, when you read the file in, does it reassemble the fragments? If not, could you send us that capture, along with the version information from Wireshark?

Not sure what you mean by this. Can you explain a little more please.

In Wireshark, the File -> Save As... menu item will let you save to a file a subset of the packets in the capture you currently have open.

Select "Save As..." from the "File" menu, and in the "Packet Range" stuff below the list of files, select "Specify a packet range:" and type in, for example...

Post by Eddie
I've also uploaded a couple of screen shots, which hopefully reinforce
my descriptions of what I'm seeing. On the LAN, it's packets 16 and
17. The WAN is 17 and 18.

..."16-17" for the LAN capture and "17-18" for the WAN capture.

Then enter a file name and click "Save"; that should save a file with only the two packets in question in it.

Then browse to a directory into which you can save the file,

Post by Eddie
http://www.BogoLinux.net/LANFragments.png
http://www.BogoLinux.net/WANFragments.png

OK, the header checksums are all valid (all four packets). However, the packets in the WAN capture *might* have been cut short by a snapshot length. If you can't save the offending packets and send them to us, can you indicate what's in the "Frame" portion of the packet detail pane for packet 17 in the WAN capture? In particular, what are the "Frame Length" and "Capture Length" values?
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe

[Eddie]

Post by Guy Harris
..."16-17" for the LAN capture and "17-18" for the WAN capture.
Then enter a file name and click "Save"; that should save a file with only the two packets in question in it.
Then browse to a directory into which you can save the file,

http://www.BogoLinux.net/LANFragment.cap
http://www.BogoLinux.net/WANFragment.cap

Post by Guy Harris
OK, the header checksums are all valid (all four packets). However, the packets in the WAN capture *might* have been cut short by a snapshot length. If you can't save the offending packets and send them to us, can you indicate what's in the "Frame" portion of the packet detail pane for packet 17 in the WAN capture? In particular, what are the "Frame Length" and "Capture Length" values?

I foolishly followed the WireShark manual, and followed it's
instructions, for tcpdump, to capture the complete packets. Except it
doesn't. LOL

Frame Length: 1514
Capture Length: 1500

Maybe the doc needs updating. :)

Cheers.
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe

[Guy Harris]

Post by Eddie
I foolishly followed the WireShark manual, and followed it's
instructions, for tcpdump, to capture the complete packets. Except it
doesn't. LOL
Frame Length: 1514
Capture Length: 1500

That'll prevent reassembly. It couldn't reassemble the packet - there was data missing at the end of the first fragment, so there'd be a hole in the middle of the reassembled packet.

Post by Eddie
Maybe the doc needs updating. :)

The doc probably needs *fixing*; it was probably *never* wrong. Even *before* "-s 0" was supported by tcpdump, "-s 65535" worked (and Wireshark/TShark/dumpcap without "-s", and "tcpdump -s 0", do the exact same thing at the libpcap/WinPcap layer that "tcpdump -s 65535" do). "Use the MTU with -s" is not only too much work (picking a value that's too big should be just fine, except perhaps with really old versions of libpcap on some OSes), it's also misleading, as you don't want the "MTU" in the sense of the biggest *payload*, you want the maximum *link-layer* packet size.

Where is that in the Wireshark manual? I'll look at fixing it.
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe

[Eddie]

Post by Guy Harris
That'll prevent reassembly. It couldn't reassemble the packet - there was data missing at the end of the first fragment, so there'd be a hole in the middle of the reassembled packet.

I guess then, this doesn't really help with why I started doing the
investigation, as this seems to be WireShark specific, not something in
the "data".

Post by Guy Harris
The doc probably needs *fixing*; it was probably *never* wrong. Even *before* "-s 0" was supported by tcpdump, "-s 65535" worked (and Wireshark/TShark/dumpcap without "-s", and "tcpdump -s 0", do the exact same thing at the libpcap/WinPcap layer that "tcpdump -s 65535" do). "Use the MTU with -s" is not only too much work (picking a value that's too big should be just fine, except perhaps with really old versions of libpcap on some OSes), it's also misleading, as you don't want the "MTU" in the sense of the biggest *payload*, you want the maximum *link-layer* packet size.
Where is that in the Wireshark manual? I'll look at fixing it.

The section I was looking at, was Appendix D:3.

Cheers, and Thanks.
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe

[Guy Harris]

Post by Eddie
I guess then, this doesn't really help with why I started doing the
investigation, as this seems to be WireShark specific, not something in
the "data".

Yup. Any issues caused by a snapshot length less than the maximum packet size will be seen only by Wireshark (or whatever program is looking at the packets), not by any other hardware or software.

Post by Eddie
The section I was looking at, was Appendix D:3.

OK, I've checked in a fix, and tagged it for inclusion in the source for the next 1.2.x and 1.0.x releases.
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe