[Openswan Users] Connecting to Cisco VPN, getting INVALID_ID_INFORMATION followed by "perhaps peer likes no proposal"

[Tim McCune]

Thanks Simon.  This seems like a reasonable guess based on other stuff I've
found while searching online.  However, I have to confess that I just don't
understand how to translate from what I've pasted from the Cisco
configuration into an openswan config.  Here is the network topology that
we are trying to accomplish:


    ---->[Customer Server B]
[My Server A (running openswan)] <-------> [Customer Cisco VPN appliance]
-----|

    ---->[Customer Server C]

Where all 4 of the servers in that diagram have public IP addresses.  What
would the rightsubnet and leftsubnet settings on the openswan side need to
be in a case like that?  I'm confused because we are not trying to reach a
private network.  We just want to tell our server "when communicating with
server B and server C, use the ipsec tunnel."


On Wed, Mar 19, 2014 at 11:44 AM, simon charles <charlessimon at hotmail.com>wrote:

> Tim ,
>     I did not see the rightsubnet and leftsubnet listed in your ipsec
> configuration. It is possible that you have a mismatch between what you
> have for your leftsubnet/rightsubnet and what Cisco side has for its
> access-list 127 ( which is  a translation of {local subnet} { remote subnet
> } )
>
>
>
>
> - Simon Charles -
>
>
> ------------------------------
> Date: Wed, 19 Mar 2014 09:52:12 -0700
> From: tim at mccune.name
> To: users at lists.openswan.org
> Subject: [Openswan Users] Connecting to Cisco VPN, getting
> INVALID_ID_INFORMATION followed by "perhaps peer likes no proposal"
>
>
> Hi there.  I was wondering if anyone could help me out with this problem
> I'm having trying to connect from openswan 2.6.38 on Ubuntu Lucid to a
> Cisco VPN appliance.  I don't seem to be able to establish a connection.
> Here is the output I get in pluto.log:
>
> "mine" #1: initiating Main Mode
> "mine" #1: ignoring Vendor ID payload [Cisco IKE Fragmentation]
> "mine" #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
> "mine" #1: STATE_MAIN_I2: sent MI2, expecting MR2
> "mine" #1: received Vendor ID payload [Cisco-Unity]
> "mine" #1: received Vendor ID payload [XAUTH]
> "mine" #1: ignoring unknown Vendor ID payload
> [716e44df1a91b4edaffa5ff96dd22125]
> "mine" #1: ignoring Vendor ID payload [Cisco VPN 3000 Series]
> "mine" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
> "mine" #1: STATE_MAIN_I3: sent MI3, expecting MR3
> "mine" #1: received Vendor ID payload [Dead Peer Detection]
> "mine" #1: Main mode peer ID is ID_IPV4_ADDR: 'XX.XX.XX.XX'
> "mine" #1: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
> "mine" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY
> cipher=aes_128 prf=oakley_sha group=modp1024}
> "mine" #2: initiating Quick Mode
> PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+SAREFTRACK {using isakmp#1
> msgid:c359ad28 proposal=AES(12)_128-SHA1(2)_160
> pfsgroup=OAKLEY_GROUP_MODP1024}
> "mine" #1: ignoring informational payload, type INVALID_ID_INFORMATION
> msgid=00000000
> "mine" #1: received and ignored informational message
> "mine" #1: received Delete SA payload: deleting ISAKMP State #1
> packet from 80.87.94.106:500: received and ignored informational message
> "mine" #2: max number of retransmissions (2) reached STATE_QUICK_I1.  No
> acceptable response to our first Quick Mode message: perhaps peer likes no
> proposal
> "mine" #2: starting keying attempt 2 of an unlimited number
>
> and this output just repeats over and over.  As far as I can tell, we are
> sending all of the correct parameters in our proposal, based on the
> configuration information we have been given by the organization that
> maintains the Cisco appliance.  Here is what they provided us with:
>
> Phase 1:
> Encryption scheme: IKE
> Authentication Method: Pre-Shared Key
> Diffie-Hellman Group: Group 2
> Encryption Algorithm: AES128
> Hashing Algorithm: SHA-1
> Main or Aggressive Mode: Main Mode
> Lifetime (for renegotiation): 28800 seconds
>
> Phase 2:
> Encapsulation mode: tunnel
> Encryption algorithm ESP: AES128
> Authentication Algorithm: SHA-1
> Perfect Forward Secrecy: Group 2
> Lifetime (for renegotiation): 3600 seconds
>
> Here is the configuration on our end in ipsec.conf:
>
> conn mine
>   left=XX.XX.XX.XX
>   right=XX.XX.XX.XX
>   authby=secret
>   auto=start
>   ike=aes128-sha1;modp1024
>   phase2=esp
>   phase2alg=aes128-sha1;modp1024
>   pfs=yes
>   aggrmode=no
>   salifetime=28800s
>
>
> And here is the configuration on their end on the Cisco appliance:
>
> crypto ipsec transform-set MyOrg esp-aes esp-sha-hmac
> crypto map gtvpn-rules 127 match address 127
> crypto map gtvpn-rules 127 set pfs group2
>
> crypto map gtvpn-rules 127 set peer XX.XX.XX.XX
> crypto map gtvpn-rules 127 set transform-set MyOrg
> crypto map gtvpn-rules 127 set security-association lifetime seconds 3600
>
> tunnel-group XX.XX.XX.XX type ipsec-l2l
> tunnel-group XX.XX.XX.XX ipsec-attributes
> pre-shared-key xxxxxxxx
>
> access-list 127 extended permit ip host YY.YY.YY.YY host XX.XX.XX.XX
> access-list 127 extended permit ip host ZZ.ZZ.ZZ.ZZ host XX.XX.XX.XX
>
> Any guidance would be appreciated.
>
> Thank you!!
>
> _______________________________________________ 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/20140319/e391bd02/attachment.html>