[strongSwan] [PATCH] iPhone ike rekeying fails because of XAUTH request

[richter at ecos.de]

Hi Andreas,

but since I cannot fix the (maybe broken) iPhone implementation, I cannot only fix (or should I better say break) strongswan...

So I understand if you do not include this patch in strongswan, but maybe it is usefull in case somebody else runs into the same problem.

Gerald


> -----Original Message-----
> From: Andreas Steffen [mailto:andreas.steffen at strongswan.org]
> Sent: Monday, September 19, 2011 2:11 PM
> To: Gerald Richter - ECOS
> Cc: users at lists.strongswan.org
> Subject: Re: [strongSwan] [PATCH] iPhone ike rekeying fails because of
> XAUTH request
> 
> 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
> >> bounces+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]==