2

The diagram below depicts a network that involves the aggregation of three slow channel throughputs over a WAN. Each router attempts to reassemble the fragmented IP packets which leads to data loss because the fragments take random paths through the three routers and often one router cannot collect all of the packet fragments for successful reassembly.

The IP traffic from the fast host arrives fragmented and randomized at the three routers (but always from 54.239.98.8). I have no control over this fragmentation (corporate politics, go figure) - I suspect the fragmentation is done on purpose by the fast host.

I have modified the kernel module nf_defrag_ipv4 to disable the offending defragmentation in the PREROUTING hook as follows:

static const struct nf_hook_ops ipv4_defrag_ops[] = {
    {
        .hook       = ipv4_conntrack_defrag, /* I changed this to point to: return NF_ACCEPT; */
        .pf         = NFPROTO_IPV4,
        .hooknum    = NF_INET_PRE_ROUTING,
        .priority   = NF_IP_PRI_CONNTRACK_DEFRAG,
    },
    {
        .hook       = ipv4_conntrack_defrag,
        .pf         = NFPROTO_IPV4,
        .hooknum    = NF_INET_LOCAL_OUT,
        .priority   = NF_IP_PRI_CONNTRACK_DEFRAG,
    },
};

The complete source code of this module can be viewed here.

Is there a better solution? Especially a way to selectively disable IP defragmentation only for packets coming from the fast host on the WAN @ ip.src == 54.239.98.8.

A fast host on a WAN (@ 54.239.98.8) is communicating with a host on a LAN (@ 192.168.0.100) which is connected via three slow channels to the WAN through three routers running Linux v4.14.151 and netfilter/iptables firewalls:

enter image description here

jww
  • 97,681
  • 90
  • 411
  • 885
George Robinson
  • 1,500
  • 9
  • 21
  • Interesting problem. Asking out of curiosity - If you disable defrag like that won't you have also opened up a big hole in your firewall? e.g. DOS attacks can get through merely by sending fragmented packets. – kaylum Dec 02 '19 at 00:05
  • @kaylum: Yes, and that is why I'm looking for a better solution. On the bright side, the IP fragments still have valid `ip.src` so right now I drop everything that does not come from this source and use a 4th router (on a different IP) for the "normal trafic" from/to the WAN. – George Robinson Dec 02 '19 at 00:09
  • How do you know that ip.src is authentic? It's trivial for any sender to use an arbitrary ip.src. – kaylum Dec 02 '19 at 00:11
  • @kaylum: I don't. Yes, this means that the ip.src can be spoofed and this can lead to DoS, because these spoofed packets will be forwarded to the 192.168.0.100 host on the LAN. However this host will not confuse the spoofed packets with the authentic ones because they will have different `id` in the 5th and 6th byte of the IPv4 header. – George Robinson Dec 02 '19 at 00:18
  • I guess what I'm driving at is it seems you have made conntrack ineffective with this change. If you are willing to accept that then it would probably be simpler to configure IP tables just to accept all such flows. No kernel changes needed in that case. – kaylum Dec 02 '19 at 00:21
  • Actually `conntrack` still works for non-fragmented packets and it even associates the first fragment with the remaining fragments using their IP addresses and their `id` fields. Ideally, I would like to configure iptables to " just to accept all such flows" but the defragmentation still should be selectively disabled for this one specific `ip.src`. – George Robinson Dec 02 '19 at 00:25
  • I'm guessing the experts in this area are available at [Network Engineering Stack Exchange](https://networkengineering.stackexchange.com/). Why would you ask about a routing problem on Stack Overflow, which is for programming and development questions? – jww Dec 02 '19 at 01:12
  • @jww: Because the attempted and working solution already involved kernel programming and a better solution - most likely will, too. – George Robinson Dec 02 '19 at 01:38

0 Answers0