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

richter at ecos.de richter at ecos.de
Mon Sep 19 12:40:16 CEST 2011


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
> 
> 
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xauth.patch
Type: application/octet-stream
Size: 1471 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20110919/2453db2c/attachment.obj>


More information about the Users mailing list