libreswan: uci configuration support

[jempatel]

Maintainer: @lucize @feckert
Run tested: x86-64, aarch64, virtual box, marvell_armada-3720-db

Description:
Add libreswan UCI configuration and hotplug support

packaged uci config (/etc/config/libreswan) file provides examples/details with commented sections.

UCI sections:

globals

init script would read globals UCI section and generate ipsec.conf.

config libreswan 'globals'
	option debug '0' # set debug mode none/all
	list virtual_private '10.0.0.0/8'
	list virtual_private '192.168.0.0/16'
	list virtual_private '172.16.0.0/12'
	list virtual_private '25.0.0.0/8'
	list virtual_private '100.64.0.0/10'
	list virtual_private '!100.64.0.0/24'  # the address ranges that may live behind a NAT router through which a client connects
	option listen '192.168.2.100' # listening address if set listen_interface would not be used
	option listen_interface 'wan' # listening interface
	option uniqueids 'yes' # yes/no

tunnel

init script would read all tunnel sections and it would generate each connection config in /var/run/ipsec/conf.d/<conn_name>.conf

config tunnel 'vti2_1_5'
	option left '%wan'  # left can be the interface or IP address
	option leftid '@left' # string
	option right '192.168.2.201' # remote endpoint public ip
	option rightid '@62dd3e3f82339b002405245b' # rightid
	option auto 'start' # what  operation, should be done automatically at IPsec startup
	option authby 'secret' # how  the  two security gateways should authenticate each other
	option psk 'AyG9RlTtQJIUxgxG' # preshare key
	option ikev2 '1' # ike version
	option ikelifetime '10800'
	option rekey '1'
	option rekeymargin '540'
	option dpdaction 'restart'
	option dpddelay '30'
	option dpdtimeout '150'
	option vti_interface 'vti2_1_5' 
	option leftvti '172.16.31.2/30'
	option mark '0x5'
	list leftsubnets '0.0.0.0/0'
	list rightsubnets '0.0.0.0/0'

crypto_proposal

policies of each tunnel section would be referenced from crypto_proposal sections.

config crypto_proposal 'p1'
	option encryption_algorithm '3des'
	option hash_algorithm 'md5'
	list dh_group 'modp1536'	

[lucize]

wouldn't be best to also have a template file ?

[jempatel]

wouldn't be best to also have a template file ?

yes, @lucize Added a config and example commented sections in the config file with details

[lucize]

I'll try to give it a spin in this weekend

[jempatel]

I'll try to give it a spin in this weekend

Thanks, I have noticed in testing that the libreswan site-to-site tunnel config does not work with IKEv2 but works with IKEv1.

I reverted to libreswan version 4.2 and it works fine on that version.

LuCI app for the same is also ready PR for the same is opened.
openwrt/luci#5932

[lucize]

the handle of vti, I'm not so sure, usually I define the vti interfaces via /etc/config/network, but I see that you use
[ -d /proc/sys/net/ipv4/conf/${VTI_IFACE} ] && ip tun del ${VTI_IFACE} anyhow, I'm building the image now and hopefully I can test it tomorrow

[jempatel]

the handle of vti, I'm not so sure, usually I define the vti interfaces via /etc/config/network, but I see that you use [ -d /proc/sys/net/ipv4/conf/${VTI_IFACE} ] && ip tun del ${VTI_IFACE} anyhow, I'm building the image now and hopefully I can test it tomorrow

@lucize , Screenshots for the LuCI app are updated. Yes VTI handling is added here because, in testing, I found, that it can only handle 1 wildcard tunnel, and If the interface already exists it does not manage it correctly. To avoid changes in the existing updown script, and handle that, added a hotplug hook, which would create VTI interface with PLUTO_PEER.

[feckert]

OpenWrt now uses firewall4 which is based on nftables.
It would therefore be good if we support both the old firewall3 (iptables) and the new firewall4 (nftables).
Also, "only" IPv4 is set. Don't we also need this for IPv6?

This should also be stored as a separate hotplug script and not be called via ipsec.user.

[jempatel]

Done in #19233

[feckert]

I would prefer that we do not copy the data generically, but that we specify each file.
That way we can work with INSTALL_DATA or INSTALL_BIN.
This makes it clearer what is installed where and how.
Otherwise we have to maintain the execution flags in git.

[jempatel]

Done in #19233

[feckert]

Shouldn't we use a separate hotplug directory here, libreswan? Because if someone also installs strongswan we will have a problem here.

[jempatel]

Done in #19233

[feckert]

I think better would be here
/sbin/hotplug-call libreswan

[jempatel]

Done in #19233

[feckert]

I don't think the creation of configurations is so good thing here!
I wouldn't expect that as a user.
You have to think about on a firmware upgrade here.
Can we not solve this differently

[jempatel]

Done in #19233