<div dir="ltr"><div><div><div><div>Hi,<br><br></div>I&#39;m using openswan 2.6.37 (looking to move to .38 sometime this year) with klips and linux kernel 2.6.32.60, and noticed a very strange set of log messages the other day.<br>
<br></div>I&#39;ve got a dozen or so remote sites connecting into the main office, each with 3 different tunnels. For various reasons, all the remote sites are NAT&#39;d. At one point the vpn server saw one tunnel supposedly receive packets from 6 vary different IP addresses.<br>
<br></div><div>Each tunnel uses PSKs, and the remote end uses %any for the remote sites IP. All tunnels use symbolic names to identify endpoints. <br><br>At the time of these logs the main office vpn server was under significant load. The server was restarted and the problem went away before I was able to access it to try other commands. <br>
<br>(IPs have been masked.)<br><br> 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[3] 1.1.1.1 #13: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): peer is NATed    <br> 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[3] 1.1.1.1 #13: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2    <br>
 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[3] 1.1.1.1 #13: STATE_MAIN_R2: sent MR2, expecting MI3    <br> 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[1] 2.2.2.2 #11: next payload type of ISAKMP Identification Payload has an unknown value: 127    <br>
 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[1] 2.2.2.2 #11: probable authentication failure (mismatch of preshared secrets?): malformed payload in packet    <br> 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[1] 2.2.2.2 #11: sending notification PAYLOAD_MALFORMED to <a href="http://2.2.2.2:500">2.2.2.2:500</a>    <br>
 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[5] 3.3.3.3 #15: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1    <br> 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[5] 3.3.3.3 #15: STATE_MAIN_R1: sent MR1, expecting MI2    <br>
 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[2] 4.4.4.4 #12: next payload type of ISAKMP Identification Payload has an unknown value: 125    <br> 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[2] 4.4.4.4 #12: probable authentication failure (mismatch of preshared secrets?): malformed payload in packet    <br>
 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[4] 5.5.5.5 #14: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): peer is NATed    <br> 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[4] 5.5.5.5 #14: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2    <br>
 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[4] 5.5.5.5 #14: STATE_MAIN_R2: sent MR2, expecting MI3    <br> 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[3] 1.1.1.1 #13: Main mode peer ID is ID_FQDN: &#39;@tunnel100.left&#39;    <br>
 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[3] 1.1.1.1 #13: no suitable connection for peer &#39;@tunnel100.left&#39;    <br> 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[3] 1.1.1.1 #13: sending encrypted notification INVALID_ID_INFORMATION to <a href="http://1.1.1.1:500">1.1.1.1:500</a>    <br>
 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[4] 5.5.5.5 #16: responding to Main Mode from unknown peer 5.5.5.5    <br> 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[4] 5.5.5.5 #16: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1    <br>
 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[4] 5.5.5.5 #16: STATE_MAIN_R1: sent MR1, expecting MI2    <br> 2013-07-01 14:22:39      pluto            packet from <a href="http://6.6.6.6:500">6.6.6.6:500</a>: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]    <br>
 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[6] 6.6.6.6 #17: responding to Main Mode from unknown peer 6.6.6.6    <br> 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[6] 6.6.6.6 #17: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1    <br>
 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[6] 6.6.6.6 #17: STATE_MAIN_R1: sent MR1, expecting MI2    <br> 2013-07-01 14:22:39      pluto            packet from <a href="http://1.1.1.1:500">1.1.1.1:500</a>: ignoring unknown Vendor ID payload [4f45755c645c6a795c5c6170]    <br>
 2013-07-01 14:22:39      pluto            packet from <a href="http://1.1.1.1:500">1.1.1.1:500</a>: received Vendor ID payload [Dead Peer Detection]    <br> 2013-07-01 14:22:39      pluto            packet from <a href="http://1.1.1.1:500">1.1.1.1:500</a>: received Vendor ID payload [RFC 3947] method set to=109    <br>
 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[3] 1.1.1.1 #18: responding to Main Mode from unknown peer 1.1.1.1    <br> 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[3] 1.1.1.1 #18: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1    <br>
 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[3] 1.1.1.1 #18: STATE_MAIN_R1: sent MR1, expecting MI2    <br> 2013-07-01 14:22:39      pluto            packet from <a href="http://1.1.1.1:500">1.1.1.1:500</a>: phase 1 message is part of an unknown exchange    <br>
 2013-07-01 14:22:39      pluto            packet from <a href="http://6.6.6.6:500">6.6.6.6:500</a>: ignoring unknown Vendor ID payload [4f45755c645c6a795c5c6170]    <br> 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[6] 6.6.6.6 #19: responding to Main Mode from unknown peer 6.6.6.6    <br>
 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[6] 6.6.6.6 #19: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1    <br> 2013-07-01 14:22:39      pluto            &quot;tunnel100&quot;[6] 6.6.6.6 #19: STATE_MAIN_R1: sent MR1, expecting MI2<br>
</div><div><br></div><div>Does anyone know what could have caused this / have seen this before?<br></div><div><br></div>Kind Regards,<br><br></div>Mike<br></div>