NBMA GRE over IPsec behind NAT

NBMA GRE over IPsec behind NAT

[Timo Teräs]

Hi,

I sent a mail earlier about this subject, see:
http://marc.info/?l=linux-netdev&m=122232910618099&w=4

I've been thinking more about this and reading the code
trying to figure out how to fix this.

One idea for the fix would be:
1. Include the NAT Original Address in NDA_LLADDR (this way
   we don't have to modify struct neighbour)
2. Add new Neighbor Cache Entry Flag (NTF_NATOA?) to specify
   if the NAT-OA is present
3. Modify neighbor cache to cope with the new flag and address
4. Add NAT-OA field for ipv4 in struct flowi
5. ipv4/xfrm4_policy.c: __xfrm4_find_bundle() to compare NAT-OA
   if it is specified in struct flowi.
6. Possibly ipv4/xfrm4_policy.c: _decode_session4() would
   extract the NAT-OA to struct flowi from skb->dst->neighbour.

Does this sound something that might work? Would it be an
acceptable approach?

- Timo

NBMA GRE over IPsec behind NAT

[Timo Teräs]

I've been working on OpenNHRP (http://opennhrp.sf.net) to get Cisco DMVPN
support for Linux boxes. Basically it is NBMA GRE over IPsec. And the GRE
level private IP-public IP mapping is done via NHRP protocol. OpenNHRP does
this by talking to kernel neighbor cache.

I haven't still bumped into this problem (and probably won't for a while),
but it'd be good to solve it anyway. The problem is that, if I have multiple
IPsec nodes behind same NAT box, that is both have same public-ip, but
different NAT original address, the NHRP private ip to public ip mapping is
not enough. Since NHRP knows the NAT-OA it could indicate that back to kernel
to the neighbor cache. ip_gre could then pass that information to xfrm layer
which could using that decide the correct IPsec SA to use.

Now trying to figure out how this should be done. Maybe a new attribute to
neighbor cache message? Or give both IP addresses in the NDA_LLADDR
attribute? And how could ip_gre pass that info to xfrm? Or maybe IP gre
would not have to be touched, just make xfrm get the extra info from
neighbor cache?

Thanks,
  Timo