<div dir="ltr">Hi Paul,<div><br></div><div>Do you have any idea how we can prevent this from happening in future?</div><div><br></div><div>Thanks,</div><div>Xinwei</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 15, 2018 at 10:37 PM, Xinwei Hong <span dir="ltr"><<a href="mailto:xhong@skytap.com" target="_blank">xhong@skytap.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div dir="ltr"><span style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Thank you Paul!</span><div style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial">I think the attached log file contains all info we got during the whole period, from good state, then first network blip, (vpns continue to be working), and finally dead after the second blip. Do you mean you want the negotiation phase log for the initial good state? I can try to find it if that's true. It could be months ago.</div><div style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial">Thanks,</div><div style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial">Xinwei</div><br></div></span><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Sat, Jul 14, 2018 at 5:21 PM, Paul Wouters <span dir="ltr"><<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a>></span> wrote:<br></span><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Fri, 13 Jul 2018, Xinwei Hong wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have attached the log we can collect. There were two network blip, both time was detected by DPD. After the first blip at about Jul 11 22:03:21, the renegotiation take<br>
effect and every thing looks fine. During the second blip (Jul 12 06:16:54), things went into bad state. A main mode renegotiation was started at Jul 12 05:47:48 before<br>
the DPD error at (Jul 12 06:16:54)<br>
<br>
</blockquote>
<br>
</span><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and also many<br>
<br>
Jul 12 06:21:56 vvr-10-9-255-36 pluto[31586]: vpn-711360: initiate_ondemand_body() failed to install negotiation_shunt,<br>
Jul 12 06:21:56 vvr-10-9-255-36 pluto[31586]: vpn-711360: initiate on demand from <a href="http://10.1.153.84:22" rel="noreferrer" target="_blank">10.1.153.84:22</a> to <a href="http://10.1.1.155:54187" rel="noreferrer" target="_blank">10.1.1.155:54187</a> proto=6 because: acquire<br>
Jul 12 06:21:58 vvr-10-9-255-36 pluto[31586]: vpn-711360: assign_holdpass() delete_bare_shunt() failed<br>
</blockquote>
<br></span>
This indicates a problem on a packet triggered tunnel policy.<br>
I guess there is confusion about an ongoing tunnel and a new<br>
packet triggering that tunnel. It seems to have caused you to<br>
be in a state where we partially think the tunnel should be up<br>
and partially think we should be done.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
after some time main mode passed. The VPN then tries to do quick mode renegotiation every 50 minutes or so as normal. However the VPN was not working during this time.<br>
When we noticed the issue and check “ip xfrm policy”, we only see<br>
<br>
:/proc/net# ip xfrm policy<br>
<br>
src <a href="http://0.0.0.0/0" rel="noreferrer" target="_blank">0.0.0.0/0</a> dst <a href="http://0.0.0.0/0" rel="noreferrer" target="_blank">0.0.0.0/0</a><br>
dir out priority 3136<br>
mark 0x5/0xffffffff<br>
tmpl src 199.204.218.76 dst 66.193.98.67<br>
proto esp reqid 16389 mode tunnel<br>
the in and fwd policy is missing. <br>
</blockquote>
<br></span>
Hmm, clearly that should never happen.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Can you help check what’s wrong here? What can we do to avoid this in future?<br>
</blockquote>
<br></span>
It would be helpful to get all the logs of the events from good to bad<br>
state.<span class="m_-6202308698822511627HOEnZb"><font color="#888888"><br>
<br>
Paul<br>
</font></span></blockquote></div></div></div><br></div>
</blockquote></div><br></div>