[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160827215538.GA36125@gmail.com>
Date: Sat, 27 Aug 2016 16:55:38 -0500
From: Quentin Barnes <qbarnes@...il.com>
To: netdev@...r.kernel.org
Subject: iptables, conntrack, and the raw table vs. L3DSR
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
Powered by blists - more mailing lists