[strongSwan-dev] support for {left,right}allowany in charon?

[Mirko Parthey]

> [1] https://lists.strongswan.org/pipermail/dev/2011-November/000493.html

Hi Tobias,

with your MOBIKE fix applied, I tried again the first option you suggested.

This test is intended to simulate the change of a gateway's external IP
address, where the corresponding update of the name resolution is
not available to its peer immediately, but only after some delay.
The delay is made long enough that an IKE SA renegotiation can take
place in the meantime.

The DNS information for the other direction is assumed to be up-to-date.
Since both gateways are set up as potential initiators, it is hoped that
the IKE SA can be rebuilt quickly by the gateway which has the
up-to-date DNS information.

When the initiator of the original IKE SA changes its IP address and has
up-to-date DNS information of its peer, this works.
However, it breaks when the responder changes its IP address and is
expected to take over initiation of the new IKE SA.

My logs show the results for both cases,
with an update of name/IP resolution in-between.

typescript summary (for configs and detailed logs, see the attachment):
------------------------------------------------------------------------
ipsec statusall > status1
moon is initiator

change moon's IP
wait for IKE reauth -> tunnel stays up
ipsec statusall > status2

update IP address entry for moon in sun:/etc/hosts

change sun's IP (is still responder)
ipsec statusall > status3
wait for IKE reauth -> tunnel down
ipsec statusall > status4
------------------------------------------------------------------------

How could this be made to work?

Regards,
Mirko
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testreport.tar.bz2
Type: application/octet-stream
Size: 11391 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20120510/f9ba09db/attachment.obj>