[Swan] OnDemand connection torn down by DPD results in "no routed template"

[Paul Wouters]

3.15 is really old. Please upgrade and let us know if the problem is still there.

You can find RHEL/centos 6 binaries of newer versions at download.libreswan.org/binaries/rhel/6/

Paul

Sent from mobile device

> On Dec 5, 2018, at 14:01, Matthew Johnson <matthew.f.j at gmail.com> wrote:
> 
> Hi,
> 
> I'm running Linux Libreswan 3.15 (netkey) on 2.6.32-754.2.1.el6.x86_64
> 
> In my test lab, I've noticed that when my OnDemand connections are torn down due to DPD, subsequent connection attempts (once the server is available again) result in " no routed template covers this pair ". For example:
> 
> 10.1.190.96/32:47060 -17-> 10.1.190.201/32:1025 => %hold 0    no routed template covers this pair
> 
> West:
> conn conman-client
>         right=10.1.190.84
>         rightsubnet=10.1.190.201/32
>         also=tunneled-client_default
>         auto=route
> 
> conn tunneled-client_default
>         type=tunnel
>         authby=null
>         left=%defaultroute
>         negotiationshunt=hold
>         failureshunt=drop
>         ikev2=insist
>         dpddelay=2
>         dpdtimeout=8
>         #dpdactions=(hold|clear|restart)
>         dpdaction=clear
>         rekey=yes
>         keyingtries=4
>         retransmit-timeout=5
>         forceencaps=yes
>         leftmodecfgclient=yes
>         rightmodecfgserver=yes
>         modecfgpull=yes
> 
> East:
> conn conman-server_120
>         right=10.1.190.120
>         also=conman-server_default
>         auto=add
> 
> conn conman-server_default
>         type=tunnel
>         authby=null 
>         leftid=10.1.190.84
>         left=%defaultroute
>         leftsubnet=10.1.190.201/32
>         leftsourceip=10.1.190.201
>         rightaddresspool=10.1.190.244-10.1.190.254
>         negotiationshunt=hold 
>         failureshunt=drop 
>         ikev2=insist 
>         dpddelay=2
>         dpdtimeout=8
>         #dpdactions=(hold|clear|restart) 
>         dpdaction=clear
>         rekey=yes
>         keyingtries=4
>         retransmit-timeout=5
>         narrowing=yes 
>         forceencaps=yes
>         leftmodecfgserver=yes
>         rightmodecfgclient=yes
>         modecfgpull=yes
> 
> 
> The only way to recover from this state that I've discovered is to restart IPSec. I suspect this is a bug related to the version I'm using. However, is there a more elegant way to recover? For example, I could perhaps add some directive to the updown script?
> 
> Best regards,
> 
> Matt
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20181205/9002f0e7/attachment.html>