> [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
testreport.tar.bz2
Description: Binary data
_______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
