[Swan-dev] IPSec restarts intermittently and crashes sometimes, PAYLOAD_MALFORMED issue observed: resend without logs
rajeev.gaur at niyuj.com
Mon Jan 25 19:24:56 UTC 2016
Please find below the links for logs for the two sites:
For other points, I am answering inline, please see the last message.
On Mon, Jan 25, 2016 at 11:50 AM, Rajeev Gaur <rajeev.gaur at niyuj.com> wrote:
> Thank you for the reply Paul,
> Yes, I understand that I have not placed logs for you.
> I am also looking for some space, to provide you a public access.
> Please hold on.
> On Mon, Jan 25, 2016 at 1:07 AM, Paul Wouters <paul at nohats.ca> wrote:
>> On Fri, 22 Jan 2016, Rajeev Gaur wrote:
>> [As advised by Paul removed log attachments]
>> Although you did not provide a link to the logs for me to look at.
>> I have received a problem scenario from my company regarding IPSec VPN.
>>> Important Points:
>>> 1) The problem involves Openswan 2.6.31 or Libreswan 3.12.
>>> 2) Problem is intermittent, does not have a specific interval for
>>> 3) This is a hub and spoke problem. Having hub and 3 spokes.
>>> 4) NAT is not involved. All the connections are through public IPs.
>>> 5) All connections involve PRESHARED KEYS ONLY.
>>> 6) This all is phase 1 - packet 5 or 6.
>>> Intermittently, out of the three spokes two spokes just restart ipsec
>> You mean a operator induced restart, or a crash+restart? If there is a
>> crash, there should be log messages about what caused it.
>> PAYLOAD_MALFORMED message is received quite sometimes.
>> That could be because the other end still has state which the restarted
>> end does not have.
>> process_packet_tail() -> in_struct() -> [%s of %s has an unknown value =
>>> next payload type of ISAKMP Hash Payload has an unknown value: 201]
>> It usually signifies an error in PSK/crypto, so the entire message is
>> garbage. (you can tell too because 201 is not defined, although it
>> is in the space of "private use" numbers as listed at
>> Our problem is at 4) point.
>>> Yesterday, I went to https://libreswan.org/ and saw the following text
>>> mentioned in red:
>>> August 24st, 2015: CVE-2015-3240: Receiving a bad DH gx causes IKE
>>> daemon restart
>>> 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
>>> remote code execution is possible. Please upgrade libreswan to version
>>> 3.15 or later.
>>> Also looked into:
>>> So, do you feel in this case also the problem is above vulnerability
>>> (the bad DH issue).
>> No that has nothing to do with it.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Swan-dev