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

Rajeev Gaur rajeev.gaur at niyuj.com
Wed Jan 27 10:27:44 UTC 2016

Hi Paul

One request here, did you had chance to look at 24 and 96 site logs?
Do you find this same behavior being depicted by the logs?
If yes, in that case, let me see and check "ipsec status".
But, if you find it different, please do suggest what difference you found.
Then, I will dig that matter.


On Wed, Jan 27, 2016 at 3:07 AM, Paul Wouters <paul at nohats.ca> wrote:

> On Tue, 26 Jan 2016, Rajeev Gaur wrote:
> Hi Rajeev,
> I wrote:
>       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);
>>                 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.
> As I said, a mismatching AUTH can use this when using PSK, because the
> packet will just become something encrypted to the wrong PSK. So it is
> decrypted but then becomes nonsense, and we can only try to interpret
> it, which then fails on the first or second payload.
> Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20160127/4d40e06f/attachment.html>

More information about the Swan-dev mailing list