ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-users: [Wireshark-users] Identification of Fragmented UDP Packets

From: Eddie <stunnel@xxxxxxxxxxxxx>
Date: Thu, 21 Jan 2010 09:30:49 -0800
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.