[Swan] Routes dropping

Antony Antony antony at phenome.org
Fri Jun 30 19:28:35 UTC 2017


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