From: Russell Senior <seniorr@aracnet.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] multiple uplinks/iptables -t nat -PREROUTING funny
Date: Sun, 20 Apr 2003 07:42:06 +0000 [thread overview]
Message-ID: <marc-lartc-105082467332232@msgid-missing> (raw)
In-Reply-To: <marc-lartc-105004797308651@msgid-missing>
>>>>> "Russell" = Russell Senior <seniorr@aracnet.com> writes:
>>>>> "Martin" = Martin A Brown <mabrown-lartc@securepipe.com> writes:
Russell> When I connect to the port forwarded address from the
Russell> outside, it looks like the returning packets are getting
Russell> routed _before_ the source IP is translated (and thus aren't
Russell> matching a special rule and thus get routed according to the
Russell> default rule). Everything else seems to be working fine.
Russell> Has anyone seen this? Is it a bug or am I just confused?
Martin> This is not a bug--this is a fact of packet flow through the
Martin> kernel. See the kernel packet traveling diagram (KPTD) [1]
Martin> for more details on the sequence of operations. So to answer
Martin> your question: you must be confused! :)
Russell> What that very nice diagram doesn't show is how the reply
Russell> packets to DNAT'd connections are handled. The prima facie
Russell> evidence seems to be that DNAT was in the PREROUTING iptable
Russell> and "consequently" the reverse translation should occur
Russell> before routing. That is the source of my confusion.
Martin> You should try adding just one more rule:
Martin> # ip rule add from 192.168.0.2 table T2
Russell> That would "work", but it is kind of messy. What if I have a
Russell> second DNAT from IF1 that also forwards to 192.168.0.2? It
Russell> would get complicated in a hurry.
Russell> All would be solved if the reverse translation just occurred
Russell> in PREROUTING as seems like it "should". I don't understand
Russell> yet why it doesn't. Perhaps there is a good reason that I
Russell> just don't see. Or, maybe there isn't a good reason, and it
Russell> should be "fixed". Too soon for me to say.
Just as a followup to this: a relatively clean solution is to mark the
reply packets:
iptables -t mangle -I PREROUTING -m conntrack --ctstate DNAT --ctorigdst eee.fff.ggg.11 -j MARK --set-mark 2
ip rule add fwmark 2 table T2
and make sure that rp_filter is appropriately off:
echo 0 > /proc/sys/net/ipv4/conf/<if>/rp_filter
--
Russell Senior ``I've seen every kind of critter God ever made,
seniorr@aracnet.com and I ain't never seen a meaner, lower, more
stinkin' yellow hypocrite than you!''
-- Burl Ives as Rufus Hennessy
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
prev parent reply other threads:[~2003-04-20 7:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-11 7:57 [LARTC] multiple uplinks/iptables -t nat -PREROUTING funny Russell Senior
2003-04-12 19:08 ` Martin A. Brown
2003-04-12 20:04 ` Russell Senior
2003-04-20 7:42 ` Russell Senior [this message]
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=marc-lartc-105082467332232@msgid-missing \
--to=seniorr@aracnet.com \
--cc=lartc@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.