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
