<div dir="ltr"><div><div><div><div><div>Thank you for the reply Paul,<br></div>Yes, I understand that I have not placed logs for you.<br></div>I am also looking for some space, to provide you a public access.<br></div>Please hold on.<br><br></div>Thanks<br></div>Rajeev<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 25, 2016 at 1: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"><span class="">On Fri, 22 Jan 2016, Rajeev Gaur wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[As advised by Paul removed log attachments]<br>
</blockquote>
<br></span>
Although you did not provide a link to the logs for me to look at.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have received a problem scenario from my company regarding IPSec VPN.<br>
<br>
Important Points:<br>
1) The problem involves Openswan 2.6.31 or Libreswan 3.12.<br>
2) Problem is intermittent, does not have a specific interval for occurence.<br>
3) This is a hub and spoke problem. Having hub and 3 spokes.<br>
4) NAT is not involved. All the connections are through public IPs.<br>
5) All connections involve PRESHARED KEYS ONLY.<br>
6) This all is phase 1 - packet 5 or 6.<br>
<br>
<br>
Problem:<br>
Intermittently, out of the three spokes two spokes just restart ipsec daemon.<br>
</blockquote>
<br></span>
You mean a operator induced restart, or a crash+restart? If there is a<br>
crash, there should be log messages about what caused it.<span class=""><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>
</blockquote>
<br></span>
That could be because the other end still has state which the restarted<br>
end does not have.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
process_packet_tail() -> in_struct() -> [%s of %s has an unknown value = next payload type of ISAKMP Hash Payload has an unknown value: 201]<br>
</blockquote>
<br></span>
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><span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Our problem is at 4) point.<br>
<br>
Yesterday, I went to <a href="https://libreswan.org/" rel="noreferrer" target="_blank">https://libreswan.org/</a> and saw the following text mentioned in red:<br>
<br>
August 24st, 2015: CVE-2015-3240: Receiving a bad DH gx causes IKE daemon restart<br>
Libreswan up to 3.14 is vulnerable to unauthenticated packets with a malicious DH gx payload causing the daemon to hit a passert() and restart. See our CVE-2015-3240 page for details. No<br>
remote code execution is possible. Please upgrade libreswan to version 3.15 or later.<br>
<br>
Also looked into:<br>
<a href="https://libreswan.org/security/CVE-2015-3240/CVE-2015-3240.txt" rel="noreferrer" target="_blank">https://libreswan.org/security/CVE-2015-3240/CVE-2015-3240.txt</a><br>
<br>
So, do you feel in this case also the problem is above vulnerability (the bad DH issue).<br>
</blockquote>
<br></span>
No that has nothing to do with it.<span class="HOEnZb"><font color="#888888"><br>
<br>
Paul<br>
</font></span></blockquote></div><br></div>