<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>You should not have that many instances of the same connection. It also seems these are both initiating and responding and all of these hang in quick mode, so phase 2 negotiation (rekeying)</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Possibly your problems start when timing causes the end points to switch roles from initiating to responding. One common cause is pfs= mismatch where one end is tolerant for a mismatch. But perhaps in your case there is a bad selection of PSK when switching between initiating or responding. You can try setting rekey=no with ikelifetime= and salifetime= set to 24h and hope hst the Cisco will initiate to you for rekey. Or try the reverse and set the lifetimes to 45m to ensure libreswan always initiates before Cisco.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">It looks like a Cisco bug</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Paul<br><br>Sent from my iPhone</div><div><br>On Jan 29, 2016, at 11:17, Rajeev Gaur <<a href="mailto:rajeev.gaur@niyuj.com">rajeev.gaur@niyuj.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div><div><div>Hi Paul<br><br></div>I have attached "ipsec status" output, do you feel the AUTH algos used here could be an issue?<br><br></div>Thanks<br></div>Rajeev<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 27, 2016 at 3:57 PM, Rajeev Gaur <span dir="ltr"><<a href="mailto:rajeev.gaur@niyuj.com" target="_blank">rajeev.gaur@niyuj.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>Hi Paul<br><br></div>One request here, did you had chance to look at 24 and 96 site logs?<br></div>Do you find this same behavior being depicted by the logs?<br></div>If yes, in that case, let me see and check "ipsec status".<br></div>But, if you find it different, please do suggest what difference you found.<br></div><div>Then, I will dig that matter.<br></div><div><br></div>Thanks<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888">Rajeev<br></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 27, 2016 at 3:07 AM, Paul Wouters <span dir="ltr"><<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 26 Jan 2016, Rajeev Gaur wrote:<br>
<br>
Hi Rajeev,<span><br>
<br>
I wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
PAYLOAD_MALFORMED message is received quite sometimes.<br>
<br>
That could be because the other end still has state which the restarted<br>
end does not have.<br>
<br>
process_packet_tail() -> in_struct() -> [%s of %s has an unknown value = next payload type of ISAKMP Hash Payload has<br>
an unknown value: 201]<br>
<br>
<br>
It usually signifies an error in PSK/crypto, so the entire message is<br>
garbage. (you can tell too because 201 is not defined, although it<br>
is in the space of "private use" numbers as listed at<br>
<br>
<a href="http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ipsec-registry-21" rel="noreferrer" target="_blank">http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ipsec-registry-21</a><br>
<br>
[RG]:<br>
As I found further the problem is at following place in programs/pluto/ikev1.c:<br>
<br>
if (!in_struct(&pd->payload, sd, &md->message_pbs,<br>
&pd->pbs)) {<br>
loglog(RC_LOG_SERIOUS,<br>
"%smalformed payload in packet",<br>
excuse);<br>
status_update(STATE_PROBABLE_AUTH_FAILURE, ip_str(&md->sender), md->sender_port);<br>
SEND_NOTIFICATION(PAYLOAD_MALFORMED);<br>
return;<br>
}<br>
<br>
What does the status_update as STATE_PROBABLE_AUTH_FAILURE mean here?<br>
Also, I have checked and rechecked PSK and config, I did not found any issue?<br>
Please suggest something here.<br>
</blockquote>
<br></span>
As I said, a mismatching AUTH can use this when using PSK, because the<br>
packet will just become something encrypted to the wrong PSK. So it is<br>
decrypted but then becomes nonsense, and we can only try to interpret<br>
it, which then fails on the first or second payload.<span><font color="#888888"><br>
<br>
Paul<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><sites_ipsec_status.txt></div></blockquote></body></html>