From: Patrick McHardy <kaber@trash.net>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: akpm@osdl.org, netdev@vger.kernel.org,
netfilter-devel@lists.netfilter.org, webmaster@elnportal.it
Subject: Re: Fw: [Bugme-new] [Bug 5936] New: Openswan tunnels + netfilter problem
Date: Wed, 25 Jan 2006 10:25:27 +0100 [thread overview]
Message-ID: <43D74407.5040705@trash.net> (raw)
In-Reply-To: <E1F1IYh-0001I3-00@gondolin.me.apana.org.au>
Herbert Xu wrote:
> Patrick McHardy <kaber@trash.net> wrote:
>
>>Andrew Morton wrote:
>>
>>>http://bugzilla.kernel.org/show_bug.cgi?id=5936
>>
>>Please post your iptables rules and the full list of loaded modules.
>
>
> The problem is caused by SNAT on a dst that already has an xfrm set.
> When ip_route_me_harder processes the dst it will cause the dst to
> lose its xfrm since it has IPSKB_XFRM_TRANSFORMED set.
>
> Since xfrm4_output_finish does not expect dst's to lose their xfrm's
> after POST_ROUTING, it crashes.
>
> Obviously we could add a check in xfrm4_output_finish to prevent this
> crash, however, I think we need to consider this a bit more since it
> breaks a fairly common setup where people just stick a rule into the
> NAT table that says
>
> iptables -t nat -I POSTROUTING -i eth1 -j MASQUERADE
>
> where eth1 is the outbound interface. If this rule catches any IPsec
> VPN traffic then it'll SNAT them even though the intention is obviously
> to let them through without SNAT.
>
> Perhaps it's best to have SNAT not touch packets with dst->xfrm set.
> Unfortunately that leads to problems as well (albeit rarer) since you
> may have catch-all IPsec policies that every packet matches, but you
> want certain packets to be SNATed so that they match more specific
> policies.
I don't like adding this special behaviour for NAT, people need
to adjust their rulesets for filtering etc. anyway. We could stop
rerouting packets in between transforms (when both dst->xfrm and
IPSKB_XFRM_TRANSFORMED are set), but this is inconsistent with what
happens on input, when a packet is DNATed in PRE_ROUTING it does
affect the SA lookup. So I think I'd prefer handling this case in
xfrm[46]_output_finish, but I need to think about it a bit more.
next prev parent reply other threads:[~2006-01-25 9:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20060122121301.033997ca.akpm@osdl.org>
2006-01-22 20:56 ` Fw: [Bugme-new] [Bug 5936] New: Openswan tunnels + netfilter problem Patrick McHardy
2006-01-24 7:25 ` Herbert Xu
2006-01-25 9:25 ` Patrick McHardy [this message]
2006-01-25 9:57 ` Herbert Xu
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=43D74407.5040705@trash.net \
--to=kaber@trash.net \
--cc=akpm@osdl.org \
--cc=herbert@gondor.apana.org.au \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@lists.netfilter.org \
--cc=webmaster@elnportal.it \
/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.