[Openswan Users] Anyone heard over interoperability issues with Cisco SPA modules

[Paul Young]

In case anyone is interested this issue was effectively resolved by
changing one end point.

So in effect the other site I was connecting to had the option of
connecting to an ASA in place of the SPA module.

Effectively the exact same config on both sides but for one IP address (the
ASAs) and the connection was made first attempt.

I guess that should highlight where the issue is........

Thanks to Leto for all his help as well!


On 12 November 2013 13:37, Paul Young <paul at arkig.com> wrote:

> Hi Leto,
>
> 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.
>
> So in this case:
>
> Current config:
>
> conn conn
>         authby=secret
>         left=<my outside address>
>         leftid=@conn
>         leftnexthop=%defaultroute
>         leftsubnet=192.168.xxx.0/29
>         leftsourceip=192.168.xxx.1
>         right=<their outside address>
>         rightsubnet= 10.xxx.xxx.0/28
>         type=tunnel
>         auto=start
>         pfs=no
>         #ike=3des-sha1;modp1024
>         #phase2alg=3des-md5
>         ikelifetime=86400s
>         salifetime=28800s
>
> Current result:
>
> # ipsec auto --up conn
> 104 "conn" #372806: STATE_MAIN_I1: initiate
> 003 "conn" #372806: received Vendor ID payload
> [draft-ietf-ipsec-nat-t-ike-03] method set to=108
> 106 "conn" #372806: STATE_MAIN_I2: sent MI2, expecting MR2
> 003 "conn" #372806: received Vendor ID payload [Cisco-Unity]
> 003 "conn" #372806: received Vendor ID payload [Dead Peer Detection]
> 003 "conn" #372806: ignoring unknown Vendor ID payload
> [a0002ee0901e0eaa9b35a5f6c42c55f9]
> 003 "conn" #372806: received Vendor ID payload [XAUTH]
> 003 "conn" #372806: NAT-Traversal: Result using
> draft-ietf-ipsec-nat-t-ike-02/03: no NAT detected
> 108 "conn" #372806: STATE_MAIN_I3: sent MI3, expecting MR3
> 004 "conn" #372806: STATE_MAIN_I4: ISAKMP SA established
> {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_md5
> group=modp1024}
> 117 "conn" #372807: STATE_QUICK_I1: initiate
> 010 "conn" #372807: STATE_QUICK_I1: retransmission; will wait 20s for
> response
> 010 "conn" #372807: STATE_QUICK_I1: retransmission; will wait 40s for
> response
> 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
> 000 "conn" #372807: starting keying attempt 2 of an unlimited number, but
> releasing whack
>
> 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.
>
> Thanks
>
>
> On 12 November 2013 02:05, Leto <letoams at gmail.com> wrote:
>
>> it might still be a config difference. what does the log say?
>>
>>
>> sent from a tiny device
>>
>> On 2013-11-10, at 16:50, Paul Young <paul at arkig.com> wrote:
>>
>> Config has been checked and compared with a working setup where the other
>> end is a cisco ASA
>>
>>
>> On 11 November 2013 00:12, Leto <letoams at gmail.com> wrote:
>>
>>> usually that happens on configuration mismatch. double check your
>>> configs on both end?
>>>
>>> sent from a tiny device
>>>
>>> On 2013-11-10, at 0:54, Paul Young <paul at arkig.com> wrote:
>>>
>>> Hi Gents,
>>>
>>> Has anyone heard of issues with OpenSwan\ipsec connecting to Cisco VPN
>>> SPA module devices?
>>>
>>> We have openswan connected just happily to Cisco ASA and other
>>> concentrators. But it really does not like phase 1 communication.
>>>
>>> Here's the clean hands shown by Cisco TAC:
>>>
>>> " 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.
>>>
>>> As I said VPN-SPA is End of Life:
>>>
>>>
>>> http://www.cisco.com/en/US/prod/collateral/modules/ps6267/end_of_life_c51-583910.html
>>>
>>> This means engineering support finished already at 2012, so we have no
>>> chance anymore to ask development team about this issue.
>>>
>>> Please try to troubleshoot the linux and may be different distribution
>>> or version of openswan."
>>>
>>> I am running  - openswan-2.6.32-21.el6_4.x86_64 - of OpenSwan
>>>
>>> Thoughts?
>>>
>>>
>>> _______________________________________________
>>> Users at lists.openswan.org
>>> https://lists.openswan.org/mailman/listinfo/users
>>> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
>>> Building and Integrating Virtual Private Networks with Openswan:
>>> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20131119/83f7d46b/attachment-0001.html>