<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
I posted something similar a few weeks ago. I am getting a lot of
sequences like:<br>
<br>
<tt><small>Jun 23 20:11:30 server pluto[3610]: packet from
24.8.121.24:500: next payload type of ISAKMP Message has an
unknown value: 133<br>
Jun 23 20:11:30 server pluto[3610]: | payload malformed after IV<br>
Jun 23 20:11:30 server pluto[3610]: | <br>
Jun 23 20:11:30 server pluto[3610]: packet from 24.8.121.24:500:
sending notification PAYLOAD_MALFORMED to 24.8.121.24:500<br>
Jun 23 20:11:33 server pluto[3610]: packet from 24.8.121.24:500:
next payload type of ISAKMP Message has an unknown value: 133<br>
Jun 23 20:11:33 server pluto[3610]: | payload malformed after IV<br>
Jun 23 20:11:33 server pluto[3610]: | <br>
Jun 23 20:11:33 server pluto[3610]: packet from 24.8.121.24:500:
sending notification PAYLOAD_MALFORMED to 24.8.121.24:500<br>
Jun 23 20:11:33 server pluto[3610]: packet from 24.8.121.24:500:
ignoring Vendor ID payload [MS-MamieExists]<br>
Jun 23 20:11:33 server pluto[3610]: packet from 24.8.121.24:500:
ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008]<br>
Jun 23 20:11:33 server pluto[3610]: packet from 24.8.121.24:500:
received Vendor ID payload [RFC 3947] meth=109, but port
floating is off<br>
Jun 23 20:11:33 server pluto[3610]: packet from 24.8.121.24:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
meth=106, but port floating is off<br>
Jun 23 20:11:33 server pluto[3610]: packet from 24.8.121.24:500:
ignoring Vendor ID payload [FRAGMENTATION]<br>
Jun 23 20:11:33 server pluto[3610]: packet from 24.8.121.24:500:
ignoring Vendor ID payload [MS-Negotiation Discovery Capable]<br>
Jun 23 20:11:33 server pluto[3610]: packet from 24.8.121.24:500:
ignoring Vendor ID payload [Vid-Initial-Contact]<br>
Jun 23 20:11:33 server pluto[3610]: packet from 24.8.121.24:500:
ignoring Vendor ID payload [IKE CGA version 1]<br>
Jun 23 20:11:33 server pluto[3610]: packet from 24.8.121.24:500:
af+type of ISAKMP Oakley attribute has an unknown value: 16384<br>
Jun 24 03:35:13 server pluto[3610]: "Mark"[2] 24.19.234.111
#180: responding to Main Mode from unknown peer 24.19.234.111<br>
Jun 24 03:35:13 server pluto[3610]: "Mark"[2] 24.19.234.111
#180: policy does not allow Extended Authentication (XAUTH) of
initiator (we are responder). Attribute
OAKLEY_AUTHENTICATION_METHOD<br>
Jun 24 03:35:13 server pluto[3610]: "Mark"[2] 24.19.234.111
#180: policy does not allow Extended Authentication (XAUTH) of
initiator (we are responder). Attribute
OAKLEY_AUTHENTICATION_METHOD<br>
Jun 24 03:35:13 server pluto[3610]: "Mark"[2] 24.19.234.111
#180: OAKLEY_DES_CBC is not supported. Attribute
OAKLEY_ENCRYPTION_ALGORITHM<br>
Jun 24 03:35:13 server pluto[3610]: "Mark"[2] 24.19.234.111
#180: policy does not allow OAKLEY_RSA_SIG authentication.
Attribute OAKLEY_AUTHENTICATION_METHOD<br>
Jun 24 03:35:13 server pluto[3610]: "Mark"[2] 24.19.234.111
#180: policy does not allow OAKLEY_RSA_SIG authentication.
Attribute OAKLEY_AUTHENTICATION_METHOD<br>
Jun 24 03:35:13 server pluto[3610]: "Mark"[2] 24.19.234.111
#180: OAKLEY_DES_CBC is not supported. Attribute
OAKLEY_ENCRYPTION_ALGORITHM<br>
Jun 24 03:35:13 server pluto[3610]: "Mark"[2] 24.19.234.111
#180: no acceptable Oakley Transform<br>
Jun 24 03:35:13 server pluto[3610]: "Mark"[2] 24.19.234.111
#180: sending notification NO_PROPOSAL_CHOSEN to
24.19.234.111:500<br>
Jun 24 03:35:13 server pluto[3610]: "Mark"[2] 24.19.234.111:
deleting connection "Mark" instance with peer 24.19.234.111
{isakmp=#0/ipsec=#0}<br>
<br>
</small></tt><br>
I've ended up blacklisting a lot of IP's (and huge blocks of
Comcast). Sometimes I get shorter sequences which are largely
subsets of the above.<br>
<br>
My far endpoints are on dynamic IP's. It would be nice if DPD
actions could force the re-reading of ipsec.secrets because then it
would become viable to use FQDN's in the ipsec.secrets file. The
only downside of this approach is that the re-establishment of the
tunnel is dependant on how fast the Dynamic DNS update to the new IP
addresses.<br>
<br>
Regards,<br>
<br>
Nick<br>
<br>
On 25/06/2010 15:06, Paul Wouters wrote:
<blockquote
cite="mid:alpine.LFD.1.10.1006251004560.7114@newtla.xelerance.com"
type="cite">
<pre wrap="">On Fri, 25 Jun 2010, <a class="moz-txt-link-abbreviated" href="mailto:sertys@estates.bg">sertys@estates.bg</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I've been receiving isakmp handshakes from different hosts on a vpn
machine of mine. I'm starting to worry.. What are they looking for? What
are they trying to own? It can't be misrouted traffic, not can that be a
dos/ddos, cuz it's not a production machine. Is there any openswan exploit
i haven't heard of in the wild?
</pre>
</blockquote>
<pre wrap="">
Not that we know about. I've seen some "isakmp probing" myself, but I don't
know whether its malicious or just misconfigurations/software bugs.
Paul
_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Users@openswan.org">Users@openswan.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openswan.org/mailman/listinfo/users">http://lists.openswan.org/mailman/listinfo/users</a>
Building and Integrating Virtual Private Networks with Openswan:
<a class="moz-txt-link-freetext" href="http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155">http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155</a>
</pre>
</blockquote>
</body>
</html>