[strongSwan-dev] IKE1 and "service" type of application

[Alexander Sbitnev]

   Thanks Martin!
I will put android client aside for a moment and try to experiment with 
NetworkManager first.
It must be much easier to debug. In case of incompatibility with IKEV1 I 
will try to locate and report it.

On 12.11.2014 12:41, Martin Willi wrote:
> Hi Alexander,
>
>> All of presented clients fixed on IKEV2 protocol SA from the
>> beginning. Does it means usage of IKEV1 is not possible in this scheme
>> of controlling service?
> IKEv1 connections can be handled exactly the same way with strongSwan
> 5.x, you identify the protocol version to use with the version parameter
> in ike_cfg_create().
>
>> My current problem with IKEV1 and android client concerning
>> distribution of auth rules over peer_cfg_t and ike_sa_t structures.
> You should never add any auth_cfgs or rules to the IKE_SA, the daemon
> does this for you. Configuration happens through the peer_cfg and
> associated objects, only.
>
> Each auth_cfg represents an authentication round done by the local or
> the remote peer. IKEv2 can do multiple rounds using the Multiple
> Authentication extension.
>
> IKEv1 can do a single round only for traditional authentication, and the
> local and remote rounds must use the same method (PSK or public key).
> With the XAuth extension, you can add another round for the client using
> the XAuth method; Hybrid authentication allows you to replace the first
> round with XAuth.
>
>> It is possible to fill ike_sa_t with all needed rules right from the
>> beginning (initiate() of android_service.c) but I don't think it is a
>> right way to solve this problem.
> You really should avoid that. You configure auth_cfgs on your peer_cfg,
> and initiate that connection. The daemon takes care of processing your
> rules, and merges them to the IKE_SA as needed.
>
> Regards
> Martin
>