Hi Harald, > If I got you correctly, then dpdtimeout affects the lifetime > of the IKE_SA. Using "dpdaction = clear" the IKE_SA is dropped > 150s (by default) after the last notification package was > received. Is this correct?
Yes, if there hasn't been any inbound traffic (IKE or ESP) within the configured time frame the SA is closed. > Mar 11 07:27:24 srvl047 ipsec[11514]: 02[NET] received packet: from > 10.0.0.13[52555] to 10.0.0.17[4500] > ... > Mar 11 07:27:24 srvl047 charon: 02[NET] received packet: from > 10.0.0.13[52555] to 10.0.0.17[4500] Just as a side note, you might want to adjust your logger/syslog settings to avoid the duplicate log messages. > How comes that destroying the IKE_SA works, even though strongswan > on the left side has lost the IKE_SA (following your description)? The client deletes the new SA (id 65) that it failed to establish, not the old one. The log does only show the reconnection attempt so it's not clear whether the old SA was still there or not. You configured dpdtimeout=500s, so how long was the client away? And do you see the DPDs and the deletion of the previous SA in the log? One potential issue I hadn't considered so far is that while the client is asleep the mapping on the NAT router might time out (it probably does not send keepalives while asleep). So when it reconnects it will do so from different source ports from the server's point of view. Due to that the reauthentication detection will not recognize the new SA as reauthentication attempt and therefore not migrate the previous virtual IP. So you'd end up in the same situation as before (i.e. the traffic selectors don't match and the CHILD_SA can't be established). Try to compare the client's source ports to see if that's what happens here. Regards, Tobias _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
