GitLab

Scan configuration file for all supported Libreswan properties.

https://bugzilla.redhat.com/show_bug.cgi?id=1633174

Put default esp and ike values for aggressive mode IKEv1 connections in
a shared define to be used throughout the code.
To the same also for ikelifetime and salifetime for IKEv1 connections.

During recent reworks to extend the configuration options to allow IKEv2
we used a dedicated boolean to track if XAUTH was enabled or not: the
plan was to extend support to IKEv1 connections without XAUTH.
This however never happened: moreover, IKEv1 is old and we will probably
want to focus on improving IKEv2 scenarios support more than IKEv1 ones
(XAUTH is a IKEv1 thing).

So, remove the XAUTH bool var and just assume that it is always enabled
on IKEv1 connections as we already do in all the other part of the code.

In the recent refactoring of the "Advanced" dialog the labelee relations
have been lost. Moreover, they have not been added to the brand new options.

Fixes: 792b7867

https://bugzilla.redhat.com/show_bug.cgi?id=1401860

!9

Jochen Jägers authored Sep 15, 2018 and Francesco Giudici committed Sep 17, 2018

Configuration of remoteid can also be necessary for connections
using IKEv1. remoteid_label and remoteid_entry are permanent visible now and
value is written to connection on "update_connection"

Make the advanced section a separate dialog, as we do with the other
VPN plugins. Add also all the supported options that were still missing
from the GUI.

allow to properly manage also GtkCheckButton widgets and GtkComboBox
ones that allow three-valued logic values ("yes", "no" and an optional
third one value, dependent on the property).
This will allow a more convenient way to init new widgets (we are going
to leverage this in the next commit).

refactor the code a bit, should not change behavior

When passing the left/right identifier to libreswan, always
prepend the id the '@' char but when:
- the id is an IP address
- the id already starts with '@'
- the id starts with '%'

#4
!6

https://bugzilla.redhat.com/show_bug.cgi?id=1557035
!5

Not all the single options will be available (yet), just expose a simple
certificate-based IKEv2 template on the UI.

When writing Libreswan configuration, add the nm-configured paramter to
let Libreswan know that NetworkManager is taking care of the connection.

Till now the value "%defaultroute" was always enforced. Let it be the
default but allow also to specify a different one if needed.

Introduce support to the 'leftrsasigkey', 'rightrsasigkey' and
'leftcert' libreswan options.
The certificate or the RSA private key referenced in the options should
be already installed in the NSS database in order to allow the plugin to
connect successfully.

When the esp and ike options were not specified, we forced
ike=aes-sha1 and esp=aes-sha1;modp1024
These ciphers today are quite a low security standard. In particular the
DH group 2 (modp1024) has been downgraded to "SHOULD NOT" in RFC 8247 and
will be completely removed from libreswan 3.26.
So, we need to update the default crypto, also if it will affect existing
connections.

Let the default crypto be unspecified: this will allow libreswan to use
as default many sets of crypto proposals, to be negotiated with the remote
peer. Do this for IKEv2 and IKEv1 in main mode.
An exception should be made for IKEv1 connections in aggressive mode:
there the DH group in the crypto phase1 proposal must be just one; moreover
a total of 4 proposal only may be specified.
So, when IKEv1 aggressive mode is configured, use "ike=aes256-sha1;modp1536"
and "esp=aes256-sha1", that should be accepted by all obsolete VPN SW/HW
acting as a remote access VPN server and is supported in the forthcoming
version of libreswan.