iptables, conntrack, and the raw table vs. L3DSR

iptables, conntrack, and the raw table vs. L3DSR

[Quentin Barnes]

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

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

[Quentin Barnes]

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@gmail.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