[strongSwan] OS X/iOS clients with XAUTH

[Brian Mastenbrook]

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/