[Openswan dev] openswan patches

[Paul Wouters]

On Tue, 4 Oct 2011, Avesh Agarwal wrote:

> 1. Multiple IKEv2 connections are established erroneously
> when the connections are similar but have different
> ports associated. IKev2 code can not find the specific
> connection definitions leading to incorrect SA
> establishments when more than one connections exist
> between same end points.

Applied.

> 2. ip6tables does not have nat tables so the patch fixes barf.in by removing 
> ip6tables commands with nat tables.

Applied previously

> 3. In scenarios where openswan acts as a client and
> inter-operates with cisco vpn gateway, connection
> information such as ip address (provided by cisco vpn
> gateway) is not being cleared after connection is made
> down or reestablishment during rekey. This is
> problematic because everytime cisco vpn gateway sends a
> new set of information (ip address, dns addresses,
> banner info) to openswan client. This commit overwrites
> the old information with the newly received
> information, so that newly establish connection can
> work properly.

The problem is the use of delete_sr() instead of delete_connection(). Can you explain
a bit better why this is needed? Do you get multiple subnet ranges? Should we instantiate
the connection insteead?

> 4. Updated header files in program/pluto/linux26/{netlink.h, rtnetlink.h, 
> xfrm.h} as per the recent kernel changes.

Applied

> 5. Misc changes related to unused code, error logging, typo.
>
> Please review the patches and let me know your feedback regarding any 
> modifications that may be needed or if something needs more discussion.

Applied, except for the SAref removal. Why was that code removed? You know that the kernel
can set the SAref? That code is in openswan.git/patches/kernel/2.6.38/ and we're still
hoping it will make it into the kernel to support overlapping IP ranges. This is common
in two scenarios:

- IKEv1 L2TP clients behind NAT using the same stock config (eg linksys on 192.168.1.100)
- Cloud deployments where all customers come in from same/overlapping RFC1918 space

KLIPS does a lookup on the SPI and marks the packet with the SAref (a specially marked MARK)
and conntrack can then track it and when it receives a reply for 192.168.1.100, the SAref
tells it for which 192.168.1.100 tunnel it is. Using the second SAref patch, you can open a
new connection to a (192.168.1.100, SAref) tupple using a setsockt option.

Paul