[strongSwan] [PATCH] iPhone ike rekeying fails because of XAUTH request
Andreas Steffen
andreas.steffen at strongswan.org
Mon Sep 19 14:10:40 CEST 2011
Hello Gerald,
with IKEv1 a Main Mode or Phase 1 rekeying always involves a
reauthentication, so that also the Cisco-proprietary "Phase 1.5"
XAUTH client authentication must be repeated. Only the new IKEv2
protocol allows an IKE_SA rekeying without renewed authentication.
Regards
Andreas
On 19.09.2011 12:40, richter at ecos.de wrote:
> Hi,
>
> to be able to get iPhone XAUTH working with rekeying I made a patch, that carries over the XAUTH data from the last state. Otherwise a new XAUTH request would be send everytime a rekeying takes places, which then fails, at least for connections from iPhone (I would expect that over XAUTH clients behave the same).
>
> This solves the problem I have described in the mail below
>
> Gerald
>
>
>> -----Original Message-----
>> From: richter at ecos.de [mailto:users-
>> bounces+richter=ecos.de at lists.strongswan.org] On Behalf Of Gerald Richter
>> - ECOS
>> Sent: Sunday, June 26, 2011 4:59 PM
>> To: users at lists.strongswan.org
>> Subject: [strongSwan] iPhone ike rekeying fails because of XAUTH request
>>
>> Hi,
>>
>> I have setup a ipsec connection from my iPhone to a strongswan server using
>> IKEv1 and XAUTH for user authentication and ip/dns configuration.
>>
>> It works pretty well until the iPhone tries to do an ike rekeying (ipsec sa
>> rekeying works without problem).
>>
>> The point is, that after a successfully ike rekeying strongswan sends an
>> XAUTH request, which gets never answered by the iPhone. This causes the
>> ipsec connection to go down.
>>
>> Also I don't know which is the correct behavior, from my point of view it
>> doesn't make sense to do the XAUTH request after a rekeying, because
>> neither the user on the other end will change, nor do the ip configuration,
>> but maybe I am wrong...
>>
>> Any help what needs to be done to get this working would be great!
>>
>> Here is my ipsec.conf (note left is the remote side!) and below the log of the
>> reqkeying.
>>
>> Gerald
>>
>> conn v_IPSec_Server_f__r_XAUTH__richter
>> keyexchange=ikev1
>> right="10.12.12.3"
>> rightprotoport="0/0"
>> leftprotoport="0/0"
>> leftid="dc=de,dc=demo,ou=Benutzer,ou=Ecos,cn=richter"
>> rightcert="/var/syscfg/certs/server-
>> d3b540175f7d1884a124be93204ba263/9e81d383069d80b7954f7e0b189150f5.c
>> rt"
>> rightrsasigkey=%cert
>> leftrsasigkey=%cert
>> rightupdown="/usr/libexec/ipsec/_updown"
>> authby="xauthrsasig"
>> auto="add"
>> compress="no"
>> dpdaction="clear"
>> dpddelay="10"
>> dpdtimeout="30"
>> esp="3des-sha1, 3des-md5, aes256-sha1"
>> ike="3des-sha, 3des-md5, aes256-sha"
>> ikelifetime="1h"
>> keyingtries="3"
>> keylife="1h"
>> left="%any"
>> leftsourceip="172.16.5.0/24"
>> pfs="no"
>> rekey="yes"
>> rekeymargin="1m"
>> rightsubnet="0.0.0.0/0"
>> type="tunnel"
>> xauth="server"
>>
>>
>> Jun 26 14:30:03 demo-master pluto[21962]: packet from 80.153.148.144:4500:
>> received Vendor ID payload [RFC 3947] Jun 26 14:30:03 demo-master
>> pluto[21962]: packet from 80.153.148.144:4500: ignoring Vendor ID payload
>> [4df37928e9fc4fd1b3262170d515c662]
>> Jun 26 14:30:03 demo-master pluto[21962]: packet from 80.153.148.144:4500:
>> ignoring Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
>> Jun 26 14:30:03 demo-master pluto[21962]: packet from 80.153.148.144:4500:
>> ignoring Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
>> Jun 26 14:30:03 demo-master pluto[21962]: packet from 80.153.148.144:4500:
>> ignoring Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
>> Jun 26 14:30:03 demo-master pluto[21962]: packet from 80.153.148.144:4500:
>> ignoring Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
>> Jun 26 14:30:03 demo-master pluto[21962]: packet from 80.153.148.144:4500:
>> ignoring Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
>> Jun 26 14:30:03 demo-master pluto[21962]: packet from 80.153.148.144:4500:
>> ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] Jun 26 14:30:03
>> demo-master pluto[21962]: packet from 80.153.148.144:4500: ignoring
>> Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] Jun 26 14:30:03 demo-
>> master pluto[21962]: packet from 80.153.148.144:4500: ignoring Vendor ID
>> payload [draft-ietf-ipsec-nat-t-ike-02_n] Jun 26 14:30:03 demo-master
>> pluto[21962]: packet from 80.153.148.144:4500: received Vendor ID payload
>> [XAUTH] Jun 26 14:30:03 demo-master pluto[21962]: packet from
>> 80.153.148.144:4500: ignoring Vendor ID payload [Cisco-Unity] Jun 26 14:30:03
>> demo-master pluto[21962]: packet from 80.153.148.144:4500: received
>> Vendor ID payload [Dead Peer Detection] Jun 26 14:30:03 demo-master
>> pluto[21962]: "v_IPSec_Server_f__r_XAUTH__richter"[1]
>> 80.153.148.144:4500 #624: responding to Main Mode from unknown peer
>> 80.153.148.144:4500 Jun 26 14:30:03 demo-master pluto[21962]:
>> "v_IPSec_Server_f__r_XAUTH__richter"[1] 80.153.148.144:4500 #624: NAT-
>> Traversal: Result using RFC 3947: both are NATed Jun 26 14:30:04 demo-
>> master pluto[21962]: "v_IPSec_Server_f__r_XAUTH__richter"[1]
>> 80.153.148.144:4500 #624: Peer ID is ID_DER_ASN1_DN: 'DC=de, DC=demo,
>> OU=Benutzer, OU=Ecos, CN=richter'
>> Jun 26 14:30:04 demo-master pluto[21962]:
>> "v_IPSec_Server_f__r_XAUTH__richter"[1] 80.153.148.144:4500 #624: crl not
>> found Jun 26 14:30:04 demo-master pluto[21962]:
>> "v_IPSec_Server_f__r_XAUTH__richter"[1] 80.153.148.144:4500 #624:
>> certificate status unknown Jun 26 14:30:04 demo-master pluto[21962]:
>> "v_IPSec_Server_f__r_XAUTH__richter"[1] 80.153.148.144:4500 #624: we
>> have a cert and are sending it upon request Jun 26 14:30:04 demo-master
>> pluto[21962]: "v_IPSec_Server_f__r_XAUTH__richter"[1]
>> 80.153.148.144:4500 #624: sent MR3, ISAKMP SA established Jun 26 14:30:04
>> demo-master pluto[21962]: "v_IPSec_Server_f__r_XAUTH__richter"[1]
>> 80.153.148.144:4500 #624: sending XAUTH request
>>
>> There is no answer to this XAUTH request, while it work for the initial XAUTH
>> request
>
======================================================================
Andreas Steffen andreas.steffen at strongswan.org
strongSwan - the Linux VPN Solution! www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==
More information about the Users
mailing list