Hi Nick, Thanks for the debug log. I think this is a bug. The connection PaulIn has rekey=no and dpdaction=clear. IKE SA hit rekey its rekey timer, and EXPIRE itself. Leaving the IPsec SA around. Then IPsec SA got a DPD timer. When the next DPD send happens it notice that the IKE/Parent SA vanished, without checking rekey or dpd action, and this event restart the connection.
Jun 26 18:18:31: "PaulIn"[2] 79.71.154.43 #77: DPD: could not find newest phase 1 state - initiating a new one I guess the fix is easy. -antony On Fri, Jun 30, 2017 at 05:07:07PM +0100, Nick Howitt wrote: > Hi Paul, > > I sent you a message directly a few days ago but I guess it did not go > through. > > The issue happened again with a listening only conn switching to initiating. > I have a full pluto debug log at > http://www.howitts.co.uk/clearos/libreswan.txt. Please copy and paste the > link as you can't navigate to it. The file is about 15MB. If you let me know > when you've got a copy I'll take the file down for bandwidth reasons. > > It again appears to have been triggered close to a change in remote IP and > the first I1 message happens at Jun 26 18:19:35. > > The conn is: > conn PaulIn > type=tunnel > authby=secret > dpdtimeout=120 > dpddelay=30 > auto=add > left=%defaultroute > leftsourceip=172.17.2.1 > leftsubnet=172.17.2.0/24 > leftid=@Nick > right=%any > rightsubnet=192.168.30.0/24 > salifetime=24h > dpdaction=clear > ikelifetime=24h > ike=aes256-sha1;modp2048 > phase2alg=aes256-sha1 > rekey=no > > and: > > # The config file changed quite a bit from 1.x. > # See > http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/upgrading.html > > version 2.0 > > # Default policy > #--------------- > > config setup > interfaces=%defaultroute > klipsdebug=none > protostack=netkey # 2.6.x only > plutodebug=all > plutostderrlog=/var/log/libreswan > plutostderrlogtime=yes > virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!172.17.2.0/24 > > > conn %default > type=tunnel > authby=secret > > # Tunnels defined in separate files > #---------------------------------- > > include /etc/ipsec.d/ipsec.*.conf > > > > > HTH, > > Nick > > On 23/06/2017 17:53, Nick Howitt wrote: > > Hi Paul, > > > > I've had another look at the logs I sent directly to you yesterday, and > > it looks like the change of the remote IP successfully renegotiated the > > conn initiated by the other end (Draytek). It is just our end which > > keeps initiating the conn with the old IP address. You can see the > > correct conn rekeying every 50min or so, but libreswan also initiates to > > the old IP address every 1min 4s. It does not happen all the time as the > > remote IP address changed again last night without any issues. > > > > I've restarted ipsec with plutodebug=all. > > > > Regards, > > > > Nick > > > > On 22/06/2017 21:24, Nick Howitt wrote: > > > > > > > > > On 22/06/2017 21:07, Paul Wouters wrote: > > > > > > > > On Thu, 22 Jun 2017, Nick Howitt wrote: > > > > > > > > > Originally the "roadwarrior" set up was that one end would > > > > > never initiate or rekey. This was done with auto=add and > > > > > rekey=no, and possibly also setting DPD to clear (and > > > > > implicitly wait for the other end to re-initiate). Somehow a > > > > > way must be found again to stop the listening end initiating > > > > > even if it means adding a further parameter. I > > > > > think that the changes have introduced a significant interop > > > > > problem and makes my conn unreliable. I hardly use it but it > > > > > has been rekeying for days and I only noticed > > > > > it because of the size of the log file. In my case you can > > > > > even argue it is rekeying to the wrong IP as right is > > > > > defined as %any so should not rekey to a specific IP > > > > > address. I am pretty certain changing the behaviour is wrong > > > > > as it can potentially break working setups (like mine). To > > > > > change the behaviour, really another parameter > > > > > should be introduced which defaults to allow the original behaviour. > > > > > > > > A conn with auto=add and rekey=no, not manually changed used the ipsec > > > > command, should never initiate. If you can gather more detailed logs > > > > of that event, that would be useful. Is this a 3.21rcX version? > > > No, it is a vanilla libreswan-3.20-1.el7.x86_64.rpm from your repo. > > > Ipsec was restarted last week with a "service ipsec restart" (I know > > > I should use systemctl but it is more typing) as well for this issue > > > and I don't use manual ipsec commands. I can gather more info if you > > > tell me what you want. I have the standard logs, but I guess you > > > want more. > > > > > > Nick > > > > > > > > > _______________________________________________ > > > Swan mailing list > > > [email protected] > > > https://lists.libreswan.org/mailman/listinfo/swan > > > > _______________________________________________ > Swan mailing list > [email protected] > https://lists.libreswan.org/mailman/listinfo/swan _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
