[Swan] Routes dropping

Nick Howitt nick at howitts.co.uk
Fri Jun 30 19:51:44 UTC 2017


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



More information about the Swan mailing list