<div dir="ltr">In case anyone is interested this issue was effectively resolved by changing one end point.<div><br></div><div>So in effect the other site I was connecting to had the option of connecting to an ASA in place of the SPA module.</div>
<div><br></div><div>Effectively the exact same config on both sides but for one IP address (the ASAs) and the connection was made first attempt.</div><div><br></div><div>I guess that should highlight where the issue is........</div>
<div><br></div><div>Thanks to Leto for all his help as well!</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 12 November 2013 13:37, Paul Young <span dir="ltr"><<a href="mailto:paul@arkig.com" target="_blank">paul@arkig.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Leto,<div><br></div><div>Thanks for the reply - very much appreciated. It certainly behaves like an config mismatch. I have been told by my counterpart on the Cisco side that they can't see an issue with the config though.</div>
<div><br></div><div>So in this case:</div><div><br></div><div><div>Current config:</div><div><br></div><div>conn conn</div><div> authby=secret</div><div> left=<my outside address></div><div> leftid=@conn</div>
<div> leftnexthop=%defaultroute</div><div> leftsubnet=192.168.xxx.0/29</div><div> leftsourceip=192.168.xxx.1</div><div> right=<their outside address></div><div> rightsubnet= 10.xxx.xxx.0/28</div>
<div> type=tunnel</div><div> auto=start</div><div> pfs=no</div><div> #ike=3des-sha1;modp1024</div><div> #phase2alg=3des-md5</div><div> ikelifetime=86400s</div><div> salifetime=28800s</div>
<div><br></div><div>Current result:</div><div><br></div><div># ipsec auto --up conn</div><div>104 "conn" #372806: STATE_MAIN_I1: initiate</div><div>003 "conn" #372806: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] method set to=108</div>
<div>106 "conn" #372806: STATE_MAIN_I2: sent MI2, expecting MR2</div><div>003 "conn" #372806: received Vendor ID payload [Cisco-Unity]</div><div>003 "conn" #372806: received Vendor ID payload [Dead Peer Detection]</div>
<div>003 "conn" #372806: ignoring unknown Vendor ID payload [a0002ee0901e0eaa9b35a5f6c42c55f9]</div><div>003 "conn" #372806: received Vendor ID payload [XAUTH]</div><div>003 "conn" #372806: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: no NAT detected</div>
<div>108 "conn" #372806: STATE_MAIN_I3: sent MI3, expecting MR3</div><div>004 "conn" #372806: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1024}</div>
<div>117 "conn" #372807: STATE_QUICK_I1: initiate</div><div>010 "conn" #372807: STATE_QUICK_I1: retransmission; will wait 20s for response</div><div>010 "conn" #372807: STATE_QUICK_I1: retransmission; will wait 40s for response</div>
<div>031 "conn" #372807: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal</div><div>000 "conn" #372807: starting keying attempt 2 of an unlimited number, but releasing whack</div>
</div><div><br></div><div>As you can see I have also tried a few combinations of setting ike and phase2alg settings based upon what my Cisco side was informing me of.</div><div><br></div><div>Thanks</div><div><div class="h5">
<div class="gmail_extra">
<br><br><div class="gmail_quote">On 12 November 2013 02:05, Leto <span dir="ltr"><<a href="mailto:letoams@gmail.com" target="_blank">letoams@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto"><div>it might still be a config difference. what does the log say?<div>
<br><br>sent from a tiny device </div>
</div><div><div><div><br>On 2013-11-10, at 16:50, Paul Young <<a href="mailto:paul@arkig.com" target="_blank">paul@arkig.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Config has been checked and compared with a working setup where the other end is a cisco ASA</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On 11 November 2013 00:12, Leto <span dir="ltr"><<a href="mailto:letoams@gmail.com" target="_blank">letoams@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto"><div>usually that happens on configuration mismatch. double check your configs on both end?<br>
<br>sent from a tiny device </div>
<div><div><div><br>On 2013-11-10, at 0:54, Paul Young <<a href="mailto:paul@arkig.com" target="_blank">paul@arkig.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Hi Gents,<div><br>
</div><div>Has anyone heard of issues with OpenSwan\ipsec connecting to Cisco VPN SPA module devices?</div><div><br></div><div>We have openswan connected just happily to Cisco ASA and other concentrators. But it really does not like phase 1 communication.</div>
<div><br></div><div>Here's the clean hands shown by Cisco TAC:</div><div><br></div><div>"<span style="font-family:arial,sans-serif;font-size:13px"> </span><span style="font-family:arial,sans-serif;font-size:13px">I see from the debugs that right after phase 1 completed on vpn-spa end, linux machine sends some unencrypted packets which is not recognizable by the spa. Therefore we try to retransmit the last packet and then tear down the tunnel, so the whole phase 1 starts from the beginning.</span></div>
<p style="font-family:arial,sans-serif;font-size:13px">As I said VPN-SPA is End of Life:<u></u><u></u></p><p style="font-family:arial,sans-serif;font-size:13px"><a href="http://www.cisco.com/en/US/prod/collateral/modules/ps6267/end_of_life_c51-583910.html" target="_blank"><span style="color:windowtext;text-decoration:none">http://www.cisco.com/en/US/prod/collateral/modules/ps6267/end_of_life_c51-583910.html</span></a><u></u><u></u></p>
<p style="font-family:arial,sans-serif;font-size:13px">This means engineering support finished already at 2012, so we have no chance anymore to ask development team about this issue.</p><p style="font-family:arial,sans-serif;font-size:13px">
Please try to troubleshoot the linux and may be different distribution or version of openswan."</p><p style="font-family:arial,sans-serif;font-size:13px">I am running - openswan-2.6.32-21.el6_4.x86_64 - of OpenSwan</p>
<p style="font-family:arial,sans-serif;font-size:13px">Thoughts?</p><p style="font-family:arial,sans-serif;font-size:13px"><br></p></div>
</div></blockquote></div></div><blockquote type="cite"><div><span>_______________________________________________</span><br><span><a href="mailto:Users@lists.openswan.org" target="_blank">Users@lists.openswan.org</a></span><br>
<span><a href="https://lists.openswan.org/mailman/listinfo/users" target="_blank">https://lists.openswan.org/mailman/listinfo/users</a></span><br><span>Micropayments: <a href="https://flattr.com/thing/38387/IPsec-for-Linux-made-easy" target="_blank">https://flattr.com/thing/38387/IPsec-for-Linux-made-easy</a></span><br>
<span>Building and Integrating Virtual Private Networks with Openswan:</span><br><span><a href="http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155" target="_blank">http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155</a></span><br>
</div></blockquote></div></blockquote></div><br></div>
</div></blockquote></div></div></div></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>