Re: Fw: [Bugme-new] [Bug 5936] New: Openswan tunnels + netfilter problem

Re: Fw: [Bugme-new] [Bug 5936] New: Openswan tunnels + netfilter problem

[Patrick McHardy]

Andrew Morton wrote:
> 
> Begin forwarded message:
> 
> Date: Sun, 22 Jan 2006 12:02:22 -0800
> From: bugme-daemon@bugzilla.kernel.org
> To: bugme-new@lists.osdl.org
> Subject: [Bugme-new] [Bug 5936] New: Openswan tunnels + netfilter problem
> 
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=5936
> 
>            Summary: Openswan tunnels + netfilter problem
>     Kernel Version: 2.6.16-rc1
>             Status: NEW
>           Severity: high
>              Owner: laforge@gnumonks.org
>          Submitter: webmaster@elnportal.it
> 
> 
> Jan 22 20:23:17 router kernel: Unable to handle kernel NULL pointer 
> dereference at 000000000000009c RIP:
> Jan 22 20:23:17 router kernel: <ffffffff80345195>{xfrm4_output_finish+293}
> Jan 22 20:23:17 router kernel: PGD 35377067 PUD 0
> Jan 22 20:23:17 router kernel: Oops: 0000 [6]
> Jan 22 20:23:17 router kernel: CPU 0
> Jan 22 20:23:17 router kernel: Modules linked in: af_key deflate 
> zlib_deflate twofish serpent blowfish sha256 crypto_null ae$

Please post your iptables rules and the full list of loaded modules.

Re: Fw: [Bugme-new] [Bug 5936] New: Openswan tunnels + netfilter problem

[Herbert Xu]

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.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Fw: [Bugme-new] [Bug 5936] New: Openswan tunnels + netfilter problem

[Patrick McHardy]

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.

Re: Fw: [Bugme-new] [Bug 5936] New: Openswan tunnels + netfilter problem

[Herbert Xu]

On Wed, Jan 25, 2006 at 10:25:27AM +0100, Patrick McHardy wrote:
> 
> 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

Actually we can never achieve perfect symmetry because the two cases
are fundamentally different.  On outbound we start with a template
which guides us all the way to the end.  On inbound we (currently)
don't determine the policy until the very end.

> 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.

Having said that I'm certainly not averse to such a solution.  The
only thing I would like to see is for it to be flexible enough so
that you always get at least one chance to SNAT before the xfrm_policy
is completely pinned down.  This should leave the user with enough
flexibility to do whatever they wish.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt