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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 27 Aug 2016 16:55:38 -0500
From:   Quentin Barnes <>
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:

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?


Powered by blists - more mailing lists