ip xfrm policy semantics

ip xfrm policy semantics

[Timo Teräs]

Hi,

I'm trying to setup a vpnc gateway device that is a part of Cisco DMVPN and also
generic NAT gateway to Internet.

The DMVPN part is achieved by a gre tunnel, which is protected by IPsec xfrm
policy.

So I want to encrypt all GRE traffic that is to/from the local box, thus I have:
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

Which works perfect for the DMVPN part.

Now, I have a second device behind a subnet, that wants to talk to Internet
using PPTP (which ends up sending GRE packets). So what I want is that locally
generated / received packages should be protected by the ipsec policy. But
forwarded GRE packets (that are masqueraded) should not get any xfrm treatment.

It looks like that if xfrm out policy still affects the forwarded packets.
If I add an overriding policy for the PPTP server, things seem to work
better. But I'd rather not do that as it's a bit hacky.

I was not able to find any authoritative place how netfilter and xfrm policies
and routing interact. The only thing I found was [1], but that seems to be
inaccurate. Anyone care to shed light on this part?

Thanks,
  Timo

[1] http://www.strongswan.org/docs/netfilter.pdf

Re: ip xfrm policy semantics

[Timo Teräs]

Timo Teräs wrote:
> So what I want is that locally generated / received packages should
> be protected by the ipsec policy. But forwarded GRE packets (that are
> masqueraded) should not get any xfrm treatment.
> 
> It looks like that if xfrm out policy still affects the forwarded packets.
> If I add an overriding policy for the PPTP server, things seem to work
> better. But I'd rather not do that as it's a bit hacky.
> 
> I was not able to find any authoritative place how netfilter and xfrm policies
> and routing interact. The only thing I found was [1], but that seems to be
> inaccurate. Anyone care to shed light on this part?
> 
> [1] http://www.strongswan.org/docs/netfilter.pdf

Ok, I tried to find what the code does. Apparently the ip_forward() calls 
xfrm4_route_forward() which ends up doing __xfrm_route_forward() falling
back to xfrm_lookup() which is fixed to use XFRM_POLICY_OUT. So 'out'
policy is always used; even for packets that are being forwarded.

Ok, now I tried adding:
  policy in  src pptp-server
  policy out dst pptp-server
  policy out dst internal-pptp-client

all with high priority and policy 'none'. Now it looks like the packets
from pptp-client go out to internet properly. The connection tracking
entries are recorded, but the reply packets from pptp-server do not
get back to internal-pptp-client. Apparently the 'none' policy prevents
NAT to work.

And yes, when there is no XFRM policies at all, the PPTP connection
works great.

Any ideas what would the proper way to patch XFRM to distinguish if
forwarded packets should be touched or not?

There's several things that differ:
- gre inner protocol
- gre key
- input interface
- forwarded/local

I'm thinking the easiest way out is to make XFRM GRE aware and add
an upper layer match (like icmp code; we could have gre key). But
I'm out of good ideas how to properly tie the policy to be my
local gre interface specific.

- Timo

Re: ip xfrm policy semantics

[Timo Teräs]

Timo Teräs wrote:
> Ok, I tried to find what the code does. Apparently the ip_forward() calls 
> xfrm4_route_forward() which ends up doing __xfrm_route_forward() falling
> back to xfrm_lookup() which is fixed to use XFRM_POLICY_OUT. So 'out'
> policy is always used; even for packets that are being forwarded.
> 
> Ok, now I tried adding:
>   policy in  src pptp-server
>   policy out dst pptp-server
>   policy out dst internal-pptp-client
> 
> all with high priority and policy 'none'. Now it looks like the packets
> from pptp-client go out to internet properly. The connection tracking
> entries are recorded, but the reply packets from pptp-server do not
> get back to internal-pptp-client. Apparently the 'none' policy prevents
> NAT to work.

Forget the above. I had a typo in my policy config.

Having:
  policy out dst pptp-server
  policy out dst internal-pptp-client

set to high priority and no transforms works great too.

> Any ideas what would the proper way to patch XFRM to distinguish if
> forwarded packets should be touched or not?

So basically, I would like to have separate policy for 'out' and
'fwd_out'. But adding new policy type is kinda bad. I wonder why
in the first place 'in' and 'fwd' were split, but 'out' was left
all alone without any information about if it's forwarded or local
packet?

So, I'm back to thinking how to fix this without adding IP
addresses to my security policies.

The options I could think of are:
1. A way to test input interface on policy selector
2. GRE upper layer awareness. gre key being the likely key.
(3. Splitting 'out' policy to 'out' and 'outfwd')

Any comment on which would the preferred way to go?

- Timo