Hi Anthony,
Thanks for looking. I think it is just a recent bug as I never noticed
it until a few weeks ago although I updated to 3.20 three months ago. It
is not totally consistent with changing IP's in that it only sometimes
happens. I think it has happened once more since the log I posted but
the remote IP has changed a number of times.
I'll leave the log there over the weekend if it does not get many hits
and then remove it from my server.
Regards,
Nick
On 30/06/2017 20:28, Antony Antony wrote:
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
