<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>