[Openswan Users] modecfg supplied IP address and multiple subnets

[Paul Wouters]

On Thu, 15 Mar 2012, Northfield Stuart wrote:

>> Is there a difference in behaviour in you use three cons with
>> rightsubnet= versus one conn with rightsubnets= ?
>
> I had already tried this and it appears to behave the same.

Ok, good to know.

>> It would be useful to get a plutodebug=all log if possible (without the
>> leftsubnet/leftsourceips specified.. you can send it to me off-list,
>> but try to do the least anonymising.
>
>
> Interestingly, if I remove both then no connection is established at all (not sure what's going on there). The log I am supplying had a leftsubnet defined, but no leftsourceip - will supply log privately, but here is my take on what is happening:

Note that many ike daemons keep phase1 states lingering around, so
sometimes if you do a configuration change without actually rebooting
an endpoint, it could be re-using a phase1 from the previous
configuration.

> When openswan starts, it instigates three phase 2 associations (metanate/0x1,metanate/0x2,metanate/0x3), one per subnet.
>
> All three phase 2 associations are placed in pending state, and metanate/0x3 is used to bring up the phase 1 association.
>
> During XAuth/modecfg, the client address and source IP address of metanate/0x3 are set to the modecfg supplied value.
>
> Having completed phase 1, the three phase 2 associations are kicked off.
>
> On completion, metanate/0x1 and metanate/0x2 are using the leftsubnet value from the configuration, but metanate/0x3 is using the modecfg supplied address.
>
> I took some time to study the code, and I think that when the unpend() function in programs/pluto/pending.c is called from programs/pluto/xauth.c at the end of phase 1, it needs to copy the client and source IP addresses from the connection it has been passed (i.e. the one which has been used to established phase 1) to all of the connections it is now 'unpending' (i.e. all of the phase 2 associations waiting on this phase 1 association). I attach a simple patch which I tried as an experiment and for my configuration this then works as expected (as long as there is no leftsourceip defined anyway).
>
> (NB this patch does the minumum required and I'm sure needs polish, and probably to take other flags into account, before being incorporated into the source base - but it is enough to prove the concept. At the very least it should probably detect when the source and destination connection pointers are the same.)
>
> Does this seem the right way to go?

I will have to take a closer look, but it sounds like you are on the
right track. It could be that when modecfg completes, the SA should
look up all its phase2 children and update them, or indeed as you have
it that the children need to check for an updated parent.

Thanks for your work!

Paul