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

[Emeric POUPON]

Hello,

For a custom validation plugin, we would like to add an option per connection.
What would be the best way to do this?

As it seems quite complicated and very intusive to add custom options to the ipsec.conf file, we were thinking about something like that:

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);

There seems to be some restrictions though (dot cannot be used within a connection name, ... ?)

Sounds like a hack, maybe there is something better to handle this?
What do you think?

Emeric

[Tobias Brunner]

Hi Emeric,
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.

Post by Emeric POUPON
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).

Post by Emeric POUPON
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).

Post by Emeric POUPON
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

[Emeric POUPON]

Hello,

Thanks for your answer, we will choose this solution.

Regards,

Emeric

----- Original Message -----

Sent: Tuesday, 23 May, 2017 17:19:15
Subject: Re: [strongSwan-dev] Best way to add a custom option per connection
Hi Emeric,

Post by Emeric POUPON
As it seems quite complicated and very intusive to add custom options to the

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.

Post by Emeric POUPON
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).

Post by Emeric POUPON
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).

Post by Emeric POUPON
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