The packet matched before it was reassembled

Introduction to Fragmented Traffic

Definition and Causes

IP fragmentation occurs when an IP packet exceeds the link MTU. The originating host (or a router doing PMTUD) splits the datagram into fragments, each carrying:

• fragment offset
• more‑fragments flag
• identification field

Common causes:

• Encapsulation overhead (VPN, GRE, MPLS) that pushes the packet past the Ethernet MTU (1500 B).
• Large application payloads (NFS, DNS over TCP, DB replication) that exceed the MTU without TCP segmentation offload.
• Mis‑configured MTU on interfaces or tunnels, causing needless fragmentation.

Impact on Network Security

• Header splitting – Only the first fragment holds the transport header; later fragments lack ports/flags, thwarting Layer‑4 inspection unless re‑assembled.
• Evasion – Attackers split signatures across fragment boundaries to slip past stateless filters.
• Resource exhaustion – Re‑assembly consumes memory and timers; overflow can trigger drops (net.ipv4.ipfrag_high_thresh).
• Out‑of‑order delivery – Fragments may arrive via different paths, be lost, or arrive out of order, complicating re‑assembly.

Understanding where defragmentation occurs in the Linux packet path—and how tools like tcpdump and nftables observe packets—is key to writing correct rules for fragmented traffic.

TCPDump and Nftables Overview

TCPDump Capture Point

tcpdump uses libpcap and captures packets as they are delivered to a packet socket:

Most invocations (tcpdump -i eth0) use a raw socket, so they show the exact wire image, including any IP fragments before kernel re‑assembly.

Nftables Hooks and Defragmentation

nftables hooks into Netfilter at defined points:

IP defragmentation runs in ip_rcv_finish, which sits after NF_INET_PRE_ROUTING and before NF_INET_LOCAL_IN / NF_INET_FORWARD. Therefore:

• A rule in prerouting sees raw fragments.
• A rule in input or forward sees the re‑assembled packet (provided re‑assembly succeeded).

The explicit defrag statement can force early re‑assembly at any hook, overriding the default timing.

Comparing TCPDump and Nftables

Because tcpdump captures at the wire (pre‑defrag) while nftables input/forward hooks see post‑defrag packets, comparing the two reveals where defragmentation occurred. Inserting a defrag statement before or after a rule lets you shift the evaluation point and observe the effect in both packet counters (nft list chain …) and the capture file.

Competing Explanations for Rules that Never Match

Hypothesis 1: Evaluation Before Re‑assembly

The rule is evaluated before the kernel has re‑assembled the fragments, so Layer‑4 fields are missing in the packets that reach the hook.

• If the hook is prerouting (or any hook placed before defragmentation), only the first fragment carries the L4 header.
• A rule expecting the L4 header in every fragment will never match on the second and third fragments.
• If the rule’s action is terminal (e.g., drop), the first fragment may be handled incorrectly, allowing the rest to pass.

Hypothesis 2: Defragmentation Delays or Skips

The Linux IP re‑assembly algorithm may postpone or skip re‑assembly under certain conditions:

• Forwarding path – With net.ipv4.ip_no_frag_forward set (older kernels) the kernel may forward fragments without re‑assembly.
• Threshold exceeded – When the re‑assembly queue (ipfrag_high_thresh) is full, fragments are dropped.
• Lazy timer expiration – If the ipfrag_lazy_timeout expires before all fragments arrive, the partial packet is discarded.

In these cases the input/forward hooks never see a complete packet, so the rule never matches.

Hypothesis 3: Rule Ordering / Short‑circuit

A rule that inspects Layer‑4 data is placed after a rule that accepts, returns, or mutates the packet (e.g., changes the destination).

• Even after defragmentation, an earlier accept or return short‑circuits evaluation, so the Layer‑4 match is never reached.
• This is a classic ordering issue, made worse when a generic “fragment” rule appears early in the chain and captures the traffic before the specific L4 rule is evaluated.

Testing the Hypotheses

Experimental Setup

Methodology

1. Baseline – Send fragmented UDP traffic with a payload containing a distinctive byte pattern (e.g., 0xdeadbeef).
2. Capture – Run tcpdump on Host B to record the wire image.
3. nftables rules – Create three identical rules that match the UDP payload (payload 0xdeadbeef) and increment a counter:
   • One in prerouting
   • One in input
   • One in forward
     (Add a defrag statement before the rule in a separate test to force early re‑assembly.)
4. Collect counters – After a fixed interval, run nft list chain ip filter <chain> to see how many packets each rule counted.
5. Analyze pcap – Use tcpdump -nn -r capture.pcap to verify whether the fragmented packets arrived as expected and whether any were dropped.
6. Vary conditions – Repeat the test while:
   • Setting /proc/sys/net/ipv4/ip_no_frag_forward=1 (if available) to test Hypothesis 2.
   • Lowering net.ipv4.ipfrag_high_thresh to provoke queue drops.
   • Re‑ordering rules so a generic accept precedes the payload‑match rule (testing Hypothesis 3).

Expected Observations

Interpreting Results

• If only the first fragment matches in prerouting and adding defrag makes the later hooks match → Hypothesis 1 confirmed.
• If counters stay low regardless of hook position, but fragments are visible in the pcap and system logs show ipfrag drops or forwarding without re‑assembly → Hypothesis 2 confirmed.
• If counters are high when the payload‑match rule is placed first, but drop to zero when a preceding generic accept rule exists → Hypothesis 3 confirmed.

By systematically varying hook placement, using defrag, and manipulating kernel re‑assembly parameters, you can pinpoint which explanation (or combination thereof) accounts for why a Layer‑4 nftables rule fails to match fragmented traffic.