Hi Mirko, > 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.
An interesting bit is that during reauthentication, after the responder changed its IP address, the DELETE is sent to the new address, but the following IKE_SA_INIT is sent to the old address, even though the previous addresses are copied to the new IKE_SA created during reauthentication. The problem is that the hosts were re-resolved unconditionally in 4.6.3 and before so here you get the old address again (as the DNS info is not up-to-date yet). In the master branch this is already fixed - for existing releases you can apply the corresponding patch [1]. Now, why does the responder not initiate a new IKE_SA? Well, it has simply no reason to do so. The initiator properly deleted the existing IKE_SA and there is no closeaction=restart to tell the responder to reestablish the SA upon a proper DELETE. As you can imagine closeaction=restart is not fully compatible with reauthentication, as the proper delete before the reinitiation would trigger an additional IKE_SA - which would then be closed due to uniqueness checks - triggering yet another IKE_SA and so on (so uniqueids=no would be necessary for this to work at least partly). The question is, do you actually require reauthentication or would regular IKE_SA rekeys do too, if so, you can configure reauth=no to avoid reauthentication altogether. Regards, Tobias [1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=a994050e _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
