[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:42:18 UTC 2016


>
> [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.

[RG] No, as I understand it is crash and restart. Please do see the logs.

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

[RG]:
As I found further the problem is at following place in
programs/pluto/ikev1.c:

    if (!in_struct(&pd->payload, sd, &md->message_pbs,
                       &pd->pbs)) {
                loglog(RC_LOG_SERIOUS,
                       "%smalformed payload in packet",
                       excuse);
                status_update(STATE_PROBABLE_AUTH_FAILURE,
ip_str(&md->sender), md->sender_port);
                SEND_NOTIFICATION(PAYLOAD_MALFORMED);
                return;
            }

What does the status_update as STATE_PROBABLE_AUTH_FAILURE mean here?
Also, I have checked and rechecked PSK and config, I did not found any
issue?
Please suggest something here.

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.

On Tue, Jan 26, 2016 at 12:54 AM, Rajeev Gaur <rajeev.gaur at niyuj.com> wrote:

> 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/7e9ba0df/attachment.html>


More information about the Swan-dev mailing list