<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">3.15 is really old. Please upgrade and let us know if the problem is still there.<div><br></div><div>You can find RHEL/centos 6 binaries of newer versions at <a href="http://download.libreswan.org/binaries/rhel/6/">download.libreswan.org/binaries/rhel/6/</a><br><div><br></div><div>Paul<br><br><div id="AppleMailSignature" dir="ltr">Sent from mobile device</div><div dir="ltr"><br>On Dec 5, 2018, at 14:01, Matthew Johnson <<a href="mailto:matthew.f.j@gmail.com">matthew.f.j@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">
<div>Hi,</div><div><br></div><div>I'm running Linux Libreswan 3.15 (netkey) on 2.6.32-754.2.1.el6.x86_64</div>
<div><br></div><div>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:<br></div><div><br></div><div><a href="http://10.1.190.96/32:47060">10.1.190.96/32:47060</a> -17-> <a href="http://10.1.190.201/32:1025">10.1.190.201/32:1025</a> => %hold 0 no routed template covers this pair</div><div><br></div><div>West:<br></div><div>conn conman-client<br> right=10.1.190.84<br> rightsubnet=<a href="http://10.1.190.201/32">10.1.190.201/32</a><br> also=tunneled-client_default<br> auto=route</div><div><br></div><div>conn tunneled-client_default<br> type=tunnel<br> authby=null<br> left=%defaultroute<br> negotiationshunt=hold<br> failureshunt=drop<br> ikev2=insist<br> dpddelay=2<br> dpdtimeout=8<br> #dpdactions=(hold|clear|restart)<br> dpdaction=clear<br> rekey=yes<br> keyingtries=4<br> retransmit-timeout=5<br> forceencaps=yes<br> leftmodecfgclient=yes<br> rightmodecfgserver=yes<br> modecfgpull=yes</div><div><br></div><div>East:<br></div><div>conn conman-server_120<br> right=10.1.190.120<br> also=conman-server_default<br> auto=add<br></div><div><br></div><div>conn conman-server_default<br> type=tunnel<br> authby=null <br> leftid=10.1.190.84<br> left=%defaultroute<br> leftsubnet=<a href="http://10.1.190.201/32">10.1.190.201/32</a><br> leftsourceip=10.1.190.201<br> rightaddresspool=10.1.190.244-10.1.190.254<br> negotiationshunt=hold <br> failureshunt=drop <br> ikev2=insist <br> dpddelay=2<br> dpdtimeout=8<br> #dpdactions=(hold|clear|restart) <br> dpdaction=clear<br> rekey=yes<br> keyingtries=4<br> retransmit-timeout=5<br> narrowing=yes <br> forceencaps=yes<br> leftmodecfgserver=yes<br> rightmodecfgclient=yes<br> modecfgpull=yes<br><br></div><div><br></div><div>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?</div><div><br></div><div>Best regards,</div><div><br></div><div>Matt<br></div></div></div></div></div></div></div>
</div></blockquote><blockquote type="cite"><div dir="ltr"><span>_______________________________________________</span><br><span>Swan mailing list</span><br><span><a href="mailto:Swan@lists.libreswan.org">Swan@lists.libreswan.org</a></span><br><span><a href="https://lists.libreswan.org/mailman/listinfo/swan">https://lists.libreswan.org/mailman/listinfo/swan</a></span><br></div></blockquote></div></div></body></html>