Hi, > 1.) Use the normal config files and invoke the ipsec script (no way of > getting indications?).
This is one option, but probably the worst. The protocol between ipsec and the daemon is designed for command line invocation, not to write an API. Parsing the status output is pain, and it probably will break with every release. I won't recommend this approach, unless you want support for IKEv1 setups via pluto. > 2.) Write a Charon plugin (like the NM plugin, I quite like this approach). Thats the clean solution and very flexible. You can provide the mechanisms exactly as you need them. While we have different plugins you can have a look at, this will require some time to get in touch with daemon internals and APIs. > 3.) Use DBUS and the NM plugin (I have no idea about DBUS). The NM DBUS API is far from ideal, as it is designed for NM, and not for strongSwan. It is very limited to the specific needs of NM initiated connections. We have more generic plugins, such as the SMP plugin. SMP is an XML based plugin for control and configuration functions via a Unix socket. It is not feature-complete and we haven't put much work in it during the last years. It is usable, but probably would require some daemon-side work. Configuration-wise, we also have sql based plugins. These are very generic and render the schemas relatively complex. But it might be a good (if not too complicated) example how to integrate your own configuration backend. > 4.) Re-use the Stroke API (probably not a good idea). No, stroke has been designed to work with ipsec.conf configurations, and not with IKEv2 specific concepts. Further, all you get back via this interface is ASCII, exactly as in 1.). Assuming you go for 2.): > 1.) Programatically configure StrongSwan (Charon). You would have to instanciate connection objects, ike_cfg_t, peer_cfg_t, child_cfg_t. To provide connections as responder, serve these configs via backend_t. To initiate connections, pass them to the controller_t. > 2.) Be able to up/down connections. The simplest way to control the daemon is through the controller_t helper class. > 3.) Get indications when connections go down (e.g. through DPD). Implement the listener_t interface (or some methods of it) and register it to the bus_t. > What are the GPL implications of writing a plugin, I assume it would > also become GPL? Yes, if you distribute binaries, you'll have to provide your plugin code, too. Contact Andreas if you're interested in alternative licensing schemes. Regards Martin _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
