[Swan-dev] IPSec restarts intermittently and crashes sometimes, PAYLOAD_MALFORMED issue observed: resend without logs

Rajeev Gaur rajeev.gaur at niyuj.com
Mon Jan 25 19:24:56 UTC 2016


Hi Paul

Please find below the links for logs for the two sites:

ftp://40.140.44.12/pub/docs/TAC/site24_logs.txt
ftp://40.140.44.12/pub/docs/TAC/site96_logs.txt

For other points, I am answering inline, please see the last message.

Thanks
Rajeev

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.
>
> Thanks
> Rajeev
>
> 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
>>> occurence.
>>> 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.
>>>
>>>
>>> Problem:
>>> Intermittently, out of the three spokes two spokes just restart ipsec
>>> daemon.
>>>
>>
>> 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
>>
>>
>> http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ipsec-registry-21
>>
>> 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:
>>> https://libreswan.org/security/CVE-2015-3240/CVE-2015-3240.txt
>>>
>>> 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.
>>
>> Paul
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20160126/398a9f20/attachment-0001.html>


More information about the Swan-dev mailing list