linux-kernel - ip_rt_bug weirdness

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>] [day] [month] [year] [list]

Date:	Wed, 12 Dec 2007 13:49:36 +0100
From:	Thomas Egerer <thomas.Egerer@...unet.com>
To:	linux-kernel@...r.kernel.org
Subject: ip_rt_bug weirdness

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Hello *,

maybe it's my bad. Most probably! Even in that case I'd need someone to
point out the mistake to me!
I'm currently (trying) to write a transparent proxy application, using
libipq to capture packets + iptables' redirect mechanism.
The basic idea works as follows:
+---+      +---+      +---+
| S |<---->| P |<---->| D |
+---+ (1)  +---+  (2) +---+

(1) uses iptables' REDIRECT target; the received data is then forwarded,
    using another socket connection (2)
(2) uses libipq to do some kind of SNAT and change the local source
    address to S's address and vice versa for the incoming packets
    from D

So far the theory. The application works fine, as long, as I do not
remap the source port (destination port, respectively) from P to D. Once
I enable the port remapping I get syslog messages like the following:
[ 7742.939471] ip_rt_bug: [S' IP] -> [P's IP at (2)], ?
and a reset from P towards D, using exactly all the correct TCP
settings, except for the destination port, that is 1, sometimes 2, or 3.
I couldn't figure out, why.
By the way, the three-way-handshake works fine, the RSTs are generated
for the first packet to contain a TCP-payload. Also netstat tells me,
there is an established connection between P and D, but somehow (I
assume that this might be the trouble) looking for the corresponding
socket connection on P fails.
I'm totally puzzled why that happens. libipq reinjects the packets with
properly changed checksums and whatnot, yet the RSTs are generated.
I've also tried NF_REPEAT, instead of the NF_ACCEPT verdict. The
behavior remains identically.

Any ideas, anyone?

Thanks in advance

Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHX9jgUGqFG0l5Kr0RAyKTAJ9qempDK//O0TrCwXgXzpdjBhW+QwCeJnUQ
udz08rqnHoFvkFF6q7a2C2s=
=DZhp
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/