Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Thomas Egerer <thomas.Egerer@secunet.com>
To: netfilter@vger.kernel.org
Subject: libipq NAT causes RSTs
Date: Thu, 13 Dec 2007 16:23:44 +0100	[thread overview]
Message-ID: <47614E80.9050504@secunet.com> (raw)

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

Hello *,

first of all, I _know_ I should use netfilter_queue. I don't because libipq
actually has a quite nice documentation, being a set of man-pages. Unable to
find something comparable for netfilter_queue I to stick to using libipq (even
though having more than one queue sounds darn interesting to me)

But for the problem, maybe it's my bad. Most probably! Even in that case I'd be
glad if someone to pointed that out 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 (2). Once
I enable the port remapping I get
a) syslog messages like the following:
   [ 7742.939471] ip_rt_bug: [S' IP] -> [P's IP at (2)], ?
b) RST packets from P towards D, using exactly all the correct TCP
   settings, except for the destination port, (being 1, sometimes 2, or 3,
   I couldn't figure out, why)

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

iD8DBQFHYU6AUGqFG0l5Kr0RA3DMAJ91LfFI2rkjx5Q80XG1paLg49PRAQCgvPQ3
eAu14RJDYpgiLS03lpSthDU=
=gGsR
-----END PGP SIGNATURE-----

             reply	other threads:[~2007-12-13 15:23 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-13 15:23 Thomas Egerer [this message]
2007-12-13 17:26 ` libipq NAT causes RSTs Patrick McHardy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47614E80.9050504@secunet.com \
    --to=thomas.egerer@secunet.com \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox