[Openswan Users] OpenSWAN and iPhone IPSec only VPN

[Eric Shubert]

On 05/05/2012 07:59 PM, John A. Sullivan III wrote:
>
> We then tried to disable XAUTH since the iOS docs state that IPSec
> without XAUTH is supported when using certificates so we restarted
> OpenSWAN, deleted the iPhone and Android connections, removed the user
> and password from the iPhone VPN connection definition and tried again.
> We assumed that not entering a name and password and not having the
> server advertise itself as an XAUTH server was the way to disable XAUTH
> and lots of Internet research yielded no firm instructions on how to do
> so.  We got:
>
> 3798]: packet from 192.168.223.208:500: received Vendor ID payload [RFC 3947] method set to=109
> 3798]: packet from 192.168.223.208:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike] method set to=110
> 3798]: packet from 192.168.223.208:500: ignoring unknown Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
> 3798]: packet from 192.168.223.208:500: ignoring unknown Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
> 3798]: packet from 192.168.223.208:500: ignoring unknown Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
> 3798]: packet from 192.168.223.208:500: ignoring unknown Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
> 3798]: packet from 192.168.223.208:500: ignoring unknown Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
> 3798]: packet from 192.168.223.208:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 110
> 3798]: packet from 192.168.223.208:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 110
> 3798]: packet from 192.168.223.208:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 110
> 3798]: packet from 192.168.223.208:500: received Vendor ID payload [XAUTH]
> 3798]: packet from 192.168.223.208:500: received Vendor ID payload [Cisco-Unity]
> 3798]: packet from 192.168.223.208:500: received Vendor ID payload [Dead Peer Detection]
> 3798]: "RWNAT"[1] 192.168.223.208 #4: responding to Main Mode from unknown peer 192.168.223.208
> 3798]: "RWNAT"[1] 192.168.223.208 #4: policy does not allow Extended Authentication (XAUTH) with RSA of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
> 3798]: "RWNAT"[1] 192.168.223.208 #4: policy does not allow Extended Authentication (XAUTH) with RSA of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
> 3798]: "RWNAT"[1] 192.168.223.208 #4: policy does not allow Extended Authentication (XAUTH) with RSA of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
> 3798]: "RWNAT"[1] 192.168.223.208 #4: policy does not allow Extended Authentication (XAUTH) with RSA of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
> 3798]: "RWNAT"[1] 192.168.223.208 #4: policy does not allow Extended Authentication (XAUTH) with RSA of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
> 3798]: "RWNAT"[1] 192.168.223.208 #4: policy does not allow Extended Authentication (XAUTH) with RSA of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
> 3798]: "RWNAT"[1] 192.168.223.208 #4: policy does not allow Extended Authentication (XAUTH) with RSA of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
> 3798]: "RWNAT"[1] 192.168.223.208 #4: policy does not allow Extended Authentication (XAUTH) with RSA of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
> 3798]: "RWNAT"[1] 192.168.223.208 #4: OAKLEY_DES_CBC is not supported.  Attribute OAKLEY_ENCRYPTION_ALGORITHM
> 3798]: "RWNAT"[1] 192.168.223.208 #4: OAKLEY_DES_CBC is not supported.  Attribute OAKLEY_ENCRYPTION_ALGORITHM
> 3798]: "RWNAT"[1] 192.168.223.208 #4: no acceptable Oakley Transform
> 3798]: "RWNAT"[1] 192.168.223.208 #4: sending notification NO_PROPOSAL_CHOSEN to 192.168.223.208:500
> 3798]: "RWNAT"[1] 192.168.223.208: deleting connection "RWNAT" instance with peer 192.168.223.208 {isakmp=#0/ipsec=#0}
>
> So it appears it is trying to use XAUTH anyway.  We commenting out the
> iPhone and Android sessions and then restarting OpenSWAN in case just
> having the connections defined loaded some XAUTH listener that remained
> listening even after the connections were deleted.
>
> So how do we get certs working with iPhone IPSec only and particularly,
> how do we do so with XAUTH disabled? Thanks.  My apologies for the
> length.  Hopefully the detail is helpful - John
>
> _______________________________________________

Hey John. I've recently been trying to do the same iPhone to IPSec 
server connection (with IPCop), and my experience is similar, although I 
did not try PSK or XAUTH.

Once I managed to get certs installed on the iPhone, I do get:
policy does not allow Extended Authentication ( XAUTH). Attribute 
OAKLEY_AUTHENTICATION_METHOD
but I'm hoping that this would simply be ignored.

I believe the crux of the problem here is:
OAKLEY_DES_CBC is not supported.
This algorithm is known to be insecure and is thus not supported by 
Openswan.

There is a way to build Openswan with a USE_WEAKSUFF? flag, but it's not 
clear whether that would work entirely, and would be insecure if it did. 
See http://article.gmane.org/gmane.network.openswan.user/17635/

So the BL to me here is that at least 2 of the 3 stock VPN 
implementations in the iPhone (PPTP, IPSec) are inherently insecure. I 
don't know for sure whether the 3rd (L2TP/IPSec) is really secure or 
not, but I have my doubts.

I'm beginning to believe that the best chance of having a secure VPN 
with iDevices is to use one of the handful of VPN apps along with the 
vendor's VPN Server device (costing hundreds of $). This is likely why 
many companies are choosing to use android devices in favor of iDevices.

-- 
-Eric 'shubes'