[Swan] Routes dropping

[Nick Howitt]

Hi,

Whoever was coming in from 74.217.90.250 (Ashburn, VA?) to download the 
log file, please remove the trailing "." from the URL you are using and 
try again. I've unbanned your IP.

Regards,

Nick

On 30/06/2017 17:07, 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
>>> Swan at lists.libreswan.org
>>> https://lists.libreswan.org/mailman/listinfo/swan
>>
>