[strongSwan-dev] Best way to add a custom option per connection

[Emeric POUPON]

Hello,

Thanks for your answer, we will choose this solution.

Regards,

Emeric

----- Original Message -----
> From: "Tobias Brunner" <tobias at strongswan.org>
> To: "Emeric POUPON" <emeric.poupon at stormshield.eu>, dev at lists.strongswan.org
> Sent: Tuesday, 23 May, 2017 17:19:15
> Subject: Re: [strongSwan-dev] Best way to add a custom option per connection

> Hi Emeric,
> 
>> As it seems quite complicated and very intusive to add custom options to the
>> ipsec.conf file, we were thinking about something like that:
> 
> You should forget about ipsec.conf and start using VICI/swanctl.conf.
> You still need a patch to add new options but it is way easier.
> 
>> strongswan.conf:
>> 
>> charon {
>>     ...
>>     plugins {
>>         custom-validation-plugin {
>>             **connection_1_name** {
>>                 option_name = value;
>>             }
>>             **connection_2_name** {
>>                 option_name = value;
>>             }
>>             ....
>>          }
>>     }
>> }
>> 
>> In the validation plugin, we would get the name of the connection using the
>> peer_cfg_t of the current ike sa attached to the bus.
>> The option would be got thanks to
>> lib->settings->get_str("%s.plugins.custom-validation-plugin.%s", def, lib->ns,
>> conn_name);
> 
> I've used something similar for the p-cscf plugin.  For boolean options
> an alternative is to do something like the forecast plugin, whose
> reinject option takes a list of connection names for which packets
> should be reinjected (requires more code as you'd have to parse that list).
> 
>> There seems to be some restrictions though (dot cannot be used within a
>> connection name, ... ?)
> 
> No, it's not a problem if %s is replaced with a string containing dots
> (manually entering such a name in a get_str() call wouldn't work,
> though, as the dots would then be used to navigate to subsections).
> 
>> Sounds like a hack, maybe there is something better to handle this?
> 
> Yeah, it's not ideal but until we have something better it's the only
> way to avoid code changes outside the plugin.
> 
> Regards,
> Tobias