[strongSwan] Strongswan on android gingerbread

[Federico.Mancini at ffi.no]

Hi,

At the moment I have only succesfully integrated strongswan with
gingerbread, and patched the VPN frontend, I have not actually used it,
but I will shortly, so I will let you know whether I can generate valid
certificates or not as soon as I try it.

 

Federico

 

Fra: Richard Pickett [mailto:richard.pickett at csrtechnologies.com] 
Sendt: 7. oktober 2011 21:32
Til: Mancini, Federico
Emne: Re: [strongSwan] Strongswan on android gingerbread

 

Federico,

 

I've had problems generating certs that android will take, sometimes it
takes them, sometimes from the same ca and settings it won't take them.

 

Do you mind sharing how you're generating your certs for your android
setup?


On Fri, Oct 7, 2011 at 1:54 AM, <Federico.Mancini at ffi.no> wrote:

Thanks,
the problem was indeed the file strings.xml.origin. Once that was
removed, everything went fine!
So I can confirm that the patches work smoothly also with gingerbread
(there was no .rej file and no -b option was used, it was enough to
cancel the .origin file).

Federico

-----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
_______________________________________________
Users mailing list
Users at lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20111010/40d773e0/attachment.html>