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
