netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Timo Teräs" <timo.teras@iki.fi>
To: netdev@vger.kernel.org, Herbert Xu <herbert@gondor.apana.org.au>
Subject: xfrm transport mode policy and forward packets
Date: Thu, 22 Oct 2009 15:07:28 +0300	[thread overview]
Message-ID: <4AE04B00.8090207@iki.fi> (raw)

Hi,

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

I originally had the 'fwd' policy too, but removing it did not help as-is.
I needed to add destination specific 'out' policies with higher priority.

Apparently, the forward path does two xfrm lookups: first one with from 'fwd'
policies to check if the received packet is not against policy, and a second
'out' lookup to see if it needs to get transformed.

My initial thought was if transport mode policies ought to be ignored, but
if the forwarded packet is NATted we might actually want to xfrm it in
transport mode.

There is 'ifindex' field in xfrm_selector, but that seems to be the output
interface. So it would not solve my problem: both local and forwarded gre
packets are output on the same interface.

I'm now slightly curious why 'in' was sort of split to 'in' and 'fwd', but
'out' was not split similarly, so we'd have more control over policies
depending if the traffic is local or forwarded?

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?

Thanks,
  Timo

             reply	other threads:[~2009-10-22 12:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-22 12:07 Timo Teräs [this message]
2009-10-22 13:21 ` xfrm transport mode policy and forward packets Herbert Xu
2009-10-22 13:31   ` Timo Teräs

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=4AE04B00.8090207@iki.fi \
    --to=timo.teras@iki.fi \
    --cc=herbert@gondor.apana.org.au \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).