> > [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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 >>> >> >> >
_______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
