xfrm transport mode policy and forward packets

xfrm transport mode policy and forward packets

[Timo Teräs]

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

Re: xfrm transport mode policy and forward packets

[Herbert Xu]

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.

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

Alexey and others may have better ideas on this.

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: xfrm transport mode policy and forward packets

[Timo Teräs]

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