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 _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
