From: "Timo Teräs" <timo.teras@iki.fi>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: netdev@vger.kernel.org, Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Subject: Re: xfrm transport mode policy and forward packets
Date: Thu, 22 Oct 2009 16:31:20 +0300 [thread overview]
Message-ID: <4AE05EA8.5070700@iki.fi> (raw)
In-Reply-To: <20091022132126.GB28893@gondor.apana.org.au>
Herbert Xu wrote:
> On Thu, Oct 22, 2009 at 03:07:28PM +0300, Timo Teräs wrote:
>> I'm using on my dmvpn environment security policies like:
>>
>> src 0.0.0.0/0 dst 0.0.0.0/0 proto gre dir in priority 2147483648 ptype
>> main tmpl src 0.0.0.0 dst 0.0.0.0
>> proto esp reqid 0 mode transport
>>
>> src 0.0.0.0/0 dst 0.0.0.0/0 proto gre dir out priority 2147483648 ptype
>> main tmpl src 0.0.0.0 dst 0.0.0.0
>> proto esp reqid 0 mode transport
>>
>> To make sure the locally generated/received GRE traffic is IPsec protected.
>> Now when some other non-local gre traffic is being forwarded by this router,
>> that seems to match these SPs too. Basically no one behind this router box
>> can use GRE (or PPTP).
>
> This is expected since forwarded GRE packets match the selector
> given.
Yes. I forgot to explicitly mention, that I thought just removing the
'fwd' policy would fix this. It's slightly confusing that that input path
is split to two separate policy db's, while output is not.
>> My ideas so far have been:
>> a) rename 'fwd' to 'infwd' and split 'out' to 'out' and 'outfwd' ?
>> (sounds kinda intrusive)
>> b) iptables target that would be able to disable xfrm
>>
>> Any other ideas?
>> What would be the proper fix for this problem?
>
> We could add the fwmark as a key.
Ah, sounds even better.
> Alexey and others may have better ideas on this.
Thanks!
Timo
prev parent reply other threads:[~2009-10-22 13:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-22 12:07 xfrm transport mode policy and forward packets Timo Teräs
2009-10-22 13:21 ` Herbert Xu
2009-10-22 13:31 ` Timo Teräs [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=4AE05EA8.5070700@iki.fi \
--to=timo.teras@iki.fi \
--cc=herbert@gondor.apana.org.au \
--cc=kuznet@ms2.inr.ac.ru \
--cc=netdev@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.