[strongSwan] OS X/iOS clients with XAUTH
Michael Durket
durket at highwire.stanford.edu
Tue Feb 19 17:48:54 CET 2013
Thanks for the information. What this probably means for me is that I can't use strongSwan for iOS devices, because I need to be able to assign IPs dynamically out of a range (I'm using rightsubnet=192.168.5.0/24 for example) and so can't use a statically assigned IP in order to make this work (based on your information on modeconfig on rekeying). I have no problem with giving each device a separate X509 certificate but the xauth problems and statically assigned IPs is a real dealbreaker.
On Feb 17, 2013, at 9:03 PM, Brian Mastenbrook wrote:
> On 2/17/2013 12:49 PM, Michael Durket wrote:
>> I'm a little puzzled here. Apple's own website has a document "VPN Server for iOS Devices: IPSec settings" (at help.apple.com/iosdeployment-vpn/mac/1.2/#app36c95bff) that states it does not support Re-keying of phase 1 and recommends rekeying times on the server of 1 hour. But in an earlier section of the document, it states that it supports "Client and server certificates for IPSec authentication, with optional user authentication via xauth.".
>>
>> If this is so, and a user of a real Cisco VPN server sets it up to communicate this way, do their iPad/iPhone users regularly complain about being dropped every 45 minutes or so or not? If not, what is a real Cisco VPN doing to overcome this problem with xauth that strongSwan is not? Or do Cisco VPN owners configure their VPNs for iOS devices to use some other authentication mechanisms and avoid xauth entirely because of this issue (and if so, what do they use)?
>
> What Apple means by this is that iOS does not support server-initiated rekeying. iOS and OS X will rekey the tunnel every 45 minutes, no matter what the server proposes for lifetime.
>
> As best I can work out, Cisco's implementation returns an XAUTH OK status immediately when it detects rekeying (based on the tunnel ID). This could lead to the session being intercepted if two tunnels share the same private key, and I could imagine it would cause failures if two users with the same private key are connected behind the same NAT device.
>
> There's a branch in git called "xauth-noauth" that adds an xauth plugin that makes strongswan return an immediate xauth OK response for the applicable tunnel. This means you can use private keys for authentication and return the xauth response OS X/iOS needs, even if you don't really need xauth. I've been testing this out and have found it to work reliably with iOS 6.1 and OS X 10.8. In order to make it work, I created one key/certificate per client, and assigned an IP statically to each client. The client config looks something like this:
>
> conn foo
> rightauth2=xauth-noauth
> rightsourceip=192.168.22.33
> rightsubnet=192.168.22.33/32
> rightcert=foo.cert.pem
>
>
> The rightsubnet clause is there because OS X or iOS don't seem to do modeconfig on rekeying either, which means strongswan needs to know the rightsubnet of the SA statically.
>
> In "conn %default", I have rightauth=pubkey and have set ikelifetime and keylife to 24h. iOS and OS X will always rekey before this threshold, so I've kept rekey=yes for other clients.
>
> Hope this helps,
>
> Brian
> --
> Brian Mastenbrook
> brian at mastenbrook.net
> http://brian.mastenbrook.net/
>
More information about the Users
mailing list