[strongSwan] Strongswan on android gingerbread

[Federico.Mancini at ffi.no]

Hi again,
Now that I fixed the first part about installation, before I continue I would like to ask you a couple of questions that might save me a lot of time.
We are planning to use IPsec on a IPv6 network. Does the StrongSwan IKEv2 port for android fully support IPv6, or only IPv4?
Also, by using the IKEv2 protocol I will not need to use the l2tp/ppp tunneling anymore, right? Since IKEv2 can be used directly to establish the tunnel, unlike IKEv1.

Thanks a lot for the help!

Federico

P.S.: Sorry if the questions might sound unclear as they are probably very naïve, but I have just started working with these protocols and I am still in the learning phase.

-----Opprinnelig melding-----
Fra: Tobias Brunner [mailto:tobias at strongswan.org] 
Sendt: 6. oktober 2011 15:19
Til: Mancini, Federico
Kopi: users at lists.strongswan.org
Emne: Re: [strongSwan] Strongswan on android gingerbread

Hi Federico,

> The problem comes when I try to patch the VPN frontend as written here:
> http://wiki.strongswan.org/projects/strongswan/wiki/AndroidFrontend.

Did the patches apply cleanly?  Look for .rej files.

> The android source doesn’t compile anymore. I suspect it is because I am
> using Gingerbread instead of Froyo maybe?

Probably, the patch was initially created for 1.6 and then ported to 
Froyo which also needed some tweaking.  So it's reasonable to assume 
that there will be stuff that does not work properly on Gingerbread.

> I get the following errors that have to do with this strings.xml file
> (the actual list of errors is much longer, but they are all of the same
> type of these):
>
> frameworks/base/core/res/res/values/strings.xml:2458: Originally defined
> here.
>
> frameworks/base/core/res/res/values/strings.xml.orig:2461: error:

You get these errors because patch created a copy of the original 
unpatched file as strings.xml.orig.  Since both files define the same 
strings and the build system seems to include all files in res/values 
(not just *.xml) you get the observed errors.  Patch will do this if 
called with the -b option or if a patch did not apply cleanly.  In the 
latter case you should also see a strings.xml.rej file containing the 
failed hunk.  If so, you should be able to easily fix it as the patch 
for strings.xml contains just one added line (be sure to delete the 
files created by patch).

> Also, in practice, is the frontend patch only for usability? In other
> words, if there is no fix to my problem, is it actually possible to use
> strongswan without the frontend patch? And if so, how?

That depends on what you intend to do.  Currently only charon (the IKEv2 
daemon) and the newer libraries are built with the provided Android.mk 
files, so there is no pluto (IKEv1 daemon) or starter.  Without starter 
you won't be able to use ipsec.conf to configure the daemon.  Also, the 
ipsec script and stroke are not built so interaction with the daemon is 
not directly possible (the frontend uses charon's android plugin for 
this).  What you could do is build your own plugin with your own config 
backend (e.g. using an sqlite database, although the sql plugin could 
probably also be used for that) and your own frontend to control the 
daemon.  You could also try to build the stroke plugin and then use the 
stroke socket to control the daemon.  We also know that there are 
currently some people working on getting starter and pluto running on 
Android, but they are not yet there.

Anyway, the frontend patch should be considered as a proof of concept. 
It simply adds an additional type of VPN to the default Android VPN 
applet, which allows to easily setup IKEv2 connections but is fairly 
limited at that.  For instance, the only authentication methods 
currently supported are EAP methods with username/password 
authentication (e.g. eap-mschapv2 or eap-md5).  Also, there are 
basically only two configuration options, the IP/hostname of the gateway 
and the CA certificate (read from the Android KeyStore).  Other options 
are predefined for usage in road-warrrior scenarios (e.g. a virtual IP 
is requested from the gateway and the the proposed traffic selector is 
simply <VirtualIP>/32 === 0.0.0.0/0).

Regards,
Tobias