From: Patrick McHardy <kaber@trash.net>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org,
Yair@arx.com, linux-kernel@vger.kernel.org
Subject: Re: Re-routing packets via netfilter (ip_rt_bug)
Date: Wed, 27 Apr 2005 02:56:48 +0200 [thread overview]
Message-ID: <426EE350.1070902@trash.net> (raw)
In-Reply-To: <20050426232857.GA18358@gondor.apana.org.au>
Herbert Xu wrote:
> Let's look at the bigger picture. There are three users of
> ip_route_me_harder: nat, mangle and queue. They're all done
> in LOCAL_OUT.
>
> For nat/mangle, the source address cannot change so it's
> guaranteed to be a local IP address. On the face of it,
> queue could be changing the source address. However, the
> more I think about it the more I reckon that it should
> be disallowed.
The ipt_REJECT target can send TCP RSTs with foreign source which
go through LOCAL_OUT. Restricting it to this case and adding proper
checks to ipt_REJECT would relieve us of having to handle the last
case you pointed out (foreign saddr, broadcast/multicast daddr), but
it shouldn't be hard to also handle this case.
> If the user is changing the source address in LOCAL_OUT/queue
> then he's doing SNAT in LOCAL_OUT. This violates some fundamental
> assumptions in netfilter. The user also isn't going to have
> an easy time setting up the reverse DNAT since the corresponding
> location on the reverse side does not have a ip_route_me_harder
> call.
These assumptions are only for stateful NAT, the mangle table seems
to try to deal with stateless NAT by rerouting in LOCAL_OUT when
saddr/daddr changed. But it could also just be some left-over
cut-n-pasted from ip_nat_standalone.c, I don't think anyone is doing
stateless NAT with netfilter.
Regards
Patrick
WARNING: multiple messages have this Message-ID (diff)
From: Patrick McHardy <kaber@trash.net>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Yair@arx.com, linux-kernel@vger.kernel.org,
netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com
Subject: Re: Re-routing packets via netfilter (ip_rt_bug)
Date: Wed, 27 Apr 2005 02:56:48 +0200 [thread overview]
Message-ID: <426EE350.1070902@trash.net> (raw)
In-Reply-To: <20050426232857.GA18358@gondor.apana.org.au>
Herbert Xu wrote:
> Let's look at the bigger picture. There are three users of
> ip_route_me_harder: nat, mangle and queue. They're all done
> in LOCAL_OUT.
>
> For nat/mangle, the source address cannot change so it's
> guaranteed to be a local IP address. On the face of it,
> queue could be changing the source address. However, the
> more I think about it the more I reckon that it should
> be disallowed.
The ipt_REJECT target can send TCP RSTs with foreign source which
go through LOCAL_OUT. Restricting it to this case and adding proper
checks to ipt_REJECT would relieve us of having to handle the last
case you pointed out (foreign saddr, broadcast/multicast daddr), but
it shouldn't be hard to also handle this case.
> If the user is changing the source address in LOCAL_OUT/queue
> then he's doing SNAT in LOCAL_OUT. This violates some fundamental
> assumptions in netfilter. The user also isn't going to have
> an easy time setting up the reverse DNAT since the corresponding
> location on the reverse side does not have a ip_route_me_harder
> call.
These assumptions are only for stateful NAT, the mangle table seems
to try to deal with stateless NAT by rerouting in LOCAL_OUT when
saddr/daddr changed. But it could also just be some left-over
cut-n-pasted from ip_nat_standalone.c, I don't think anyone is doing
stateless NAT with netfilter.
Regards
Patrick
next prev parent reply other threads:[~2005-04-27 0:56 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-25 9:49 Re-routing packets via netfilter (ip_rt_bug) Yair Itzhaki
2005-04-25 9:07 ` Patrick McHardy
2005-04-25 9:07 ` Patrick McHardy
2005-04-25 10:52 ` Herbert Xu
2005-04-25 10:52 ` Herbert Xu
2005-04-25 15:28 ` Patrick McHardy
2005-04-25 15:28 ` Patrick McHardy
2005-04-25 21:34 ` Herbert Xu
2005-04-25 21:34 ` Herbert Xu
2005-04-26 0:08 ` Patrick McHardy
2005-04-26 0:08 ` Patrick McHardy
2005-04-26 0:39 ` Herbert Xu
2005-04-26 0:39 ` Herbert Xu
2005-04-26 13:17 ` Patrick McHardy
2005-04-26 13:17 ` Patrick McHardy
2005-04-26 23:28 ` Herbert Xu
2005-04-26 23:28 ` Herbert Xu
2005-04-27 0:56 ` Patrick McHardy [this message]
2005-04-27 0:56 ` Patrick McHardy
2005-04-27 1:07 ` Herbert Xu
2005-04-27 1:07 ` Herbert Xu
2005-04-27 10:26 ` Patrick McHardy
2005-04-27 10:26 ` Patrick McHardy
2005-04-27 10:30 ` Herbert Xu
2005-04-27 10:30 ` Herbert Xu
2005-04-27 10:41 ` Jozsef Kadlecsik
2005-04-27 10:41 ` Jozsef Kadlecsik
2005-04-27 11:35 ` Herbert Xu
2005-04-27 11:35 ` Herbert Xu
2005-04-27 11:54 ` Herbert Xu
2005-04-27 11:54 ` Herbert Xu
2005-04-27 12:05 ` Patrick McHardy
2005-04-27 12:05 ` Patrick McHardy
2017-07-10 9:20 ` Helbing63
2020-07-23 7:25 ` technical support jollyzula
2020-07-23 7:25 ` Canon.com/ijsetup jollyzula
-- strict thread matches above, loose matches on Subject: below --
2005-04-25 16:51 Re-routing packets via netfilter (ip_rt_bug) Yair Itzhaki
2005-04-26 15:39 Yair Itzhaki
2005-05-02 17:17 Yair Itzhaki
2005-07-14 12:27 ` Ric Wheeler
2005-07-14 12:27 ` Ric Wheeler
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=426EE350.1070902@trash.net \
--to=kaber@trash.net \
--cc=Yair@arx.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@oss.sgi.com \
--cc=netfilter-devel@lists.netfilter.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.