[strongSwan] Apple cisco connect issue

Hafeez Rehman hafeezr at hotmail.com
Thu Jun 9 20:36:44 CEST 2011




Date: Thu, 9 Jun 2011 14:23:36 -0400
From: lars at hjersted.com
To: users at lists.strongswan.org
Subject: Re: [strongSwan] Apple cisco connect issue

On Thu, 9 Jun 2011, Hafeez Rehman wrote:
 
> Hi,
> 
> I am using strongSwan on openwrt 10.03.1-rc4.
> 
> I am tryting to connect using using iphone and snow leopard using built in cisco client, but I get the same error.
> 
> iphone and osx is behind nat, but the router is connected directly to the internet.
> 
> I am able to connect using ipsec/l2tp on both the devices. I am also able to connect using cisco client using windows os.
> 
> I followed the direction on the following page which allowed me to connect using cisco client using windows.
> 
> http://wiki.strongswan.org/projects/strongswan/wiki/IOS_%28Apple%29
> 
> root at OpenWrt:~# ipsec version
> Linux strongSwan U4.3.7/K2.6.32.25
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil, Switzerland
> See 'ipsec --copyright' for copyright information.
> 
> 
> config setup
>         nat_traversal=yes
>         charonstart=no
>         plutostart=yes
> 
> conn L2TP
>         authby=psk
>         pfs=no
>         rekey=no
>         type=tunnel
>         esp=aes128-sha1
>         ike=aes128-sha-modp1024
>         left=%defaultroute
>         leftprotoport=17/1701
>         right=%any
>         rightprotoport=17/%any
>         rightsubnetwithin=0.0.0.0/0
>         auto=add
> 
> conn cisco
>         keyexchange=ikev1
>         authby=xauthrsasig
>         xauth=server
>         left=%defaultroute
>         leftsubnet=0.0.0.0/0
>         leftfirewall=yes
>         leftcert=serverCert.pem
>         right=%any
>         rightsubnet=192.168.168.0/24
>         rightsourceip=192.168.168.2
>         rightcert=clientCert.pem
>         pfs=no
>         auto=add
> 
> 
> 
> Jun  9 09:44:21 OpenWrt authpriv.warn pluto[1538]: packet from 208.54.35.143:6720: received Vendor ID payload [RFC 3947]
> Jun  9 09:44:21 OpenWrt authpriv.warn pluto[1538]: packet from 208.54.35.143:6720: ignoring Vendor ID payload [4df37928e9fc4fd1b3262170d515c662]
> Jun  9 09:44:21 OpenWrt authpriv.warn pluto[1538]: packet from 208.54.35.143:6720: ignoring Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
> Jun  9 09:44:21 OpenWrt authpriv.warn pluto[1538]: packet from 208.54.35.143:6720: ignoring Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
> Jun  9 09:44:21 OpenWrt authpriv.warn pluto[1538]: packet from 208.54.35.143:6720: ignoring Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
> Jun  9 09:44:21 OpenWrt authpriv.warn pluto[1538]: packet from 208.54.35.143:6720: ignoring Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
> Jun  9 09:44:21 OpenWrt authpriv.warn pluto[1538]: packet from 208.54.35.143:6720: ignoring Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
> Jun  9 09:44:21 OpenWrt authpriv.warn pluto[1538]: packet from 208.54.35.143:6720: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
> Jun  9 09:44:21 OpenWrt authpriv.warn pluto[1538]: packet from 208.54.35.143:6720: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
> Jun  9 09:44:21 OpenWrt authpriv.warn pluto[1538]: packet from 208.54.35.143:6720: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
> Jun  9 09:44:21 OpenWrt authpriv.warn pluto[1538]: packet from 208.54.35.143:6720: received Vendor ID payload [XAUTH]
> Jun  9 09:44:21 OpenWrt authpriv.warn pluto[1538]: "cisco"[2] 208.54.35.143:6720 #2: NAT-Traversal: Result using RFC 3947: peer is NATed
> Jun  9 09:44:25 OpenWrt authpriv.warn pluto[1538]: "cisco"[2] 208.54.35.143:6720 #2: ignoring informational payload, type IPSEC_INITIAL_CONTACT
> Jun  9 09:44:25 OpenWrt authpriv.warn pluto[1538]: "cisco"[2] 208.54.35.143:6720 #2: Peer ID is ID_DER_ASN1_DN: 'C=US, O=strongSwan, CN=client'
> Jun  9 09:44:25 OpenWrt authpriv.warn pluto[1538]: "cisco"[2] 208.54.35.143:6720 #2: crl not found
> Jun  9 09:44:25 OpenWrt authpriv.warn pluto[1538]: "cisco"[2] 208.54.35.143:6720 #2: certificate status unknown
> Jun  9 09:44:25 OpenWrt authpriv.warn pluto[1538]: "cisco"[2] 208.54.35.143:6720 #2: we have a cert and are sending it upon request
> Jun  9 09:44:26 OpenWrt authpriv.debug pluto[1538]: | NAT-T: new mapping 208.54.35.143:6720/32850)
> Jun  9 09:44:26 OpenWrt authpriv.warn pluto[1538]: "cisco"[2] 208.54.35.143:32850 #2: sent MR3, ISAKMP SA established
> Jun  9 09:44:26 OpenWrt authpriv.warn pluto[1538]: "cisco"[2] 208.54.35.143:32850 #2: sending XAUTH request
> Jun  9 09:44:26 OpenWrt authpriv.warn pluto[1538]: packet from 208.54.35.143:32850: Informational Exchange is for an unknown (expired?) SA
> 
> 
>
 
Hello,
 
I have this working between an iPad and strongSwan 4.5.2 running on 
OpenWrt trunk. I do not think this is a version related issue, but just 
FYI you can get strongSwan 4.5.1 with the OpenWrt 10.03.1-rc5 testing 
snapshots.
 
At the point where your logs show an error I see:
 
  | NAT-T: new mapping 192.168.0.1:500/4500)
"ipad"[1] 192.168.0.1:4500 #1: sent MR3, ISAKMP SA established
"ipad"[1] 192.168.0.1:4500 #1: sending XAUTH request
"ipad"[1] 192.168.0.1:4500 #1: parsing XAUTH reply
"ipad"[1] 192.168.0.1:4500 #1: extended authentication was successful
"ipad"[1] 192.168.0.1:4500 #1: sending XAUTH status
"ipad"[1] 192.168.0.1:4500 #1: parsing XAUTH ack
"ipad"[1] 192.168.0.1:4500 #1: received XAUTH ack, established
"ipad"[1] 192.168.0.1:4500 #1: parsing ModeCfg request
"ipad"[1] 192.168.0.1:4500 #1: unknown attribute type (28683)
"ipad"[1] 192.168.0.1:4500 #1: peer requested virtual IP %any
 
It seems that in your case strongSwan is proceeding fine and is expecting 
an XAUTH reply. Do you get any messages on the Apple client? Is the 
strongSwan log the same for the osx and iphone clients?
 
Is "rightsourceip=192.168.168.2" a typo?
 
-Lars

-----------------------------------------------------------------------------

Lars,

I get the same error for all apple cisco clients. Pure cisco client is connecting okay.
"rightsourceip=192.168.168.2" is the ip that will be assigned to the client from the virtual ip pool. It works fine for pure cisco client.

Hafeez

_______________________________________________
Users mailing list
Users at lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20110609/c837e236/attachment.html>


More information about the Users mailing list