netdev - Re: iptables, conntrack, and the raw table vs. L3DSR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAKjHkpCJr4_mmZqdjSvcTp+mq2cV3WUvsA==Boc8dK+JXrL69A@mail.gmail.com>
Date:   Sat, 10 Sep 2016 18:49:05 -0500
From:   Quentin Barnes <qbarnes@...il.com>
To:     netdev@...r.kernel.org
Subject: Re: iptables, conntrack, and the raw table vs. L3DSR

Being unsuccessful at getting help so far, can anyone think of who or
where else I could ask for help on this issue?

On Sat, Aug 27, 2016 at 4:55 PM, Quentin Barnes <qbarnes@...il.com> wrote:
> Several years ago, I wrote an iptables module that rewrites packets'
> destination addresses based on the value in the DSCP field to
> implement Layer 3 Direct Server Return (L3DSR).  The main code of
> the iptables target module you can find here:
> https://github.com/yahoo/l3dsr/blob/master/linux/kmod-xt/xt_DADDR.c
>
> The iptable-daddr module has been in production since I wrote it
> with some limitations.  One of those limitations is it doesn't
> work well with conntrack modules.  I believe that's from the daddr
> rewriting confuses conntrack since changing a packet's daddr changes
> its 4-tuple not allowing conntrack to track a connection.
>
> Someone recently suggested I change the module from the "mangle"
> table to "raw", so it can be put in the prerouting chain ahead of
> conntrack.  That would let conntrack see the packet after its daddr
> update.  This approach seems to work fine in a test case letting
> L3DSR and conntrack apparently work in concert, but has me concerned
> that there might be unforeseen negative side-effects from using the
> raw table for doing mangling work.
>
> Can anyone think of any issues with having a mangle target module be
> invoked from the raw table?
>
> Or as an alternative if necessary, is there a possible/rational way
> to leave the module in the mangle table and then inform conntrack
> about the packet's daddr alteration?
>
> Quentin