[Swan] Routes dropping

[Nick Howitt]

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
>> Swan at lists.libreswan.org
>> https://lists.libreswan.org/mailman/listinfo/swan
>