[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