Hi,<br><br>This issue was related to compression.<br><br>I had the following in my conn definition on the Openswan side:<br><br>compress=yes<br><br>I set compress=no and the problem went away.<br><br>The original problem was seen on an Openswan device that was connected to a provider PIX version 6.3(3). They were not willing to run debugging on their PIX as there are other working customers connected to it. I set this up in my lab with a PIX running version 6.3(4). This version of PIX would not even come up with compression enabled and the debug messages were less than helpful. In the Openswan logs, it looked like phase 1 established fine but phase 2 was "no proposal chosen".<br>
<br>So anyway, if you're connected to a PIX, don't enable compression. ;-)<br><br>I'm so glad this is solved. I'm hoping it'll be a long time before I have to mess around with another PIX. What a PITA!<br>
<br>-Robyn<br><br><div class="gmail_quote">On Tue, Feb 3, 2009 at 11:45 AM, Robyn Orosz <span dir="ltr"><<a href="mailto:rorosz@gmail.com">rorosz@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br><br>I'm connected to a Cisco PIX device and am able to establish a tunnel but the tunnel appears to be constantly restarting and the following messages keep repeating in the logs:<br><br>Feb 3 19:40:41 host pluto[19854]: | payload malformed after IV<br>
Feb 3 19:40:41 host pluto[19854]: | <br>Feb 3 19:40:41 host pluto[19854]: packet from <a href="http://192.168.18.150:500" target="_blank">192.168.18.150:500</a>: sending notification PAYLOAD_MALFORMED to <a href="http://192.168.18.150:500" target="_blank">192.168.18.150:500</a><br>
Feb 3 19:40:46 host pluto[19854]: packet from <a href="http://192.168.18.150:500" target="_blank">192.168.18.150:500</a>: not enough room in input packet for ISAKMP Message (remain=0, sd->size=28)<br><br>I have searched and searched and have not found any possible solutions for this issue. The proposals appear to match on both sides as the tunnel does establish and pass traffic. It just keeps bouncing.<br>
<br>I can send debug level messages or provide more information if needed.<br><br>Here's the version / kernel info:<br><br>Linux Openswan U2.4.12/K2.6.24-1-486-vyatta (netkey)<br><br>Thank you,<br><font color="#888888"><br>
Robyn<br>
</font></blockquote></div><br>