[strongSwan] StrongSwan Android App
tobias at strongswan.org
Mon Aug 11 18:29:55 CEST 2014
> I just noticed, that the strongSwan app still displays the tunnel as
> active, although a CHILD rekey event failed, because of a DH
> group/algorithm mismatch.
As long as the original CHILD_SA is still established the connection is
not broken, so displaying the connection as active is not incorrect.
When the SA later gets closed due to hard timeout the client tries to
recreate it and the state switches to "Connecting..." - but it will
probably fail again and will never recover from this state (unless
reauthentication is enabled on the server, which would force the client
to reestablish the IKE_SA after a while).
We can listen for ALERT_KEEP_ON_CHILD_SA_FAILURE to catch the rekeying
problem. There are then two options to handle it:
1. Simply report this as error state to the GUI. I've implemented
that with .
2. Teardown the IKE_SA and reestablish in the hope that establishing
the CHILD_SA with it will work (it did before since it's the
rekeying that failed). Implemented in .
I guess the latter results in a better user experience, although the
user might think the server configuration is actually used (e.g. if it
lists DH groups), which will not be the case. But that might not be
that much of an issue as reestablishing the IKE_SA also provides PFS.
The client currently does not propose DH groups in the ESP proposal,
which has several reasons:
1. ESP proposals are static because we currently have no API to query
kernel interfaces for their supported algorithms. It would be
great to either add that, or at least have the option to define
a proposal, to which all supported DH groups are added
automatically. The latter isn't that hard to implement but adding
all supported DH groups to each proposal increases the size of
CREATE_CHILD_SA exchanges quite a bit, especially because of the
next issue. Another problem is that we might want the algorithms
in a certain order, which isn't handled well in the automatic
2. Proper support for NONE in the ESP DH proposals is missing (some
support was added with 5.1.3, see ). This would allow us to add
NONE to the proposed DH groups, which would leave the decision
to use PFS or not up to the responder. Otherwise, if the user
can't control the responder's config we'd have to either add a
setting to enable/disable PFS, or propose all proposals once with
and once without DH groups. This increases the message size, also
during the IKE_AUTH exchange as duplicate proposals are currently
not filtered, fixed with /.
3. I honestly expected the VPN connections with the app to be rather
short lived, so rekeying wasn't really in my focus (lifetime on
the client is 3 hours). But that might be a wrong assumption on
Anyway, with  I added DH groups in the ESP proposals of the app. But
the proposals are also added without DH groups so it's up to the
responder to choose a proposal with PFS (at the cost of larger messages).
All patches can be found in the android-child-rekey-failure branch and
will probably be included in the next release of the app.
More information about the Users