IPsec - Connections: Prospoal sorting/generation

[mimugmail]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.

I'm very sorry that I didn't find the time to take a closer look to the new implementation but now I'm getting more and more attention to it, due to the labeling of "Tunnel settings" to "legacy" :)
Today I was asked about how to choose DH14 in the P1 proposal list and after a couple of tries I needed to take a look at Tunnel Settings to look for, which DH group (or PFS group) is the modp equivalent. Whenever I discuss tunnel settings with extneral parties there is a xls sheet with exchanging parameters (usually all looks same) and I never saw a modp value there, it's always DH or PFS group. The new implementation is quite smart the way IPsecProsposalFiled Type is defined, but for an engineer or general user really hard to understand.

Describe the solution you like

Actually, I'm not experienced enough to add a DH description to this code, but I'm foreseeing way more user reports and confusions about this. Any idea how to make the UX a bit easier?

Describe alternatives you considered

Tunnel Settings :)

Additional context

May be can use this as a starting point for general discussion and in some way related to #6279

[AdSchellevis]

Unfortunately these settings are complicated, the basis for this all is more or less https://docs.strongswan.org/docs/5.9/config/IKEv2CipherSuites.html

The legacy pages will be around for quite some time, so there's no rush, but looking at the number of options available, we either need to classify options in a way people can map it more easily or offer a list in the documentation which common options are which ciphers in reality. Personally, I do prefer the Strongswan documentation in most cases, which is also the reason why we are following the upstream structure.

One of the big advantages of following the upstream standards is that any example provided (https://docs.strongswan.org/docs/5.9/index.html) can easily be adopted on our end as well.

[mimugmail]

I'll take a look at CDATA formatted help text and adjusted defaults

[mimugmail]

As discussed via IRC you try to add it in brackets: https://github.com/mimugmail/core/blob/patch-11/src/opnsense/mvc/app/controllers/OPNsense/IPsec/forms/dialogConnection.xml#L19-L58

[mimugmail]

This is my proposal for default sets:

// AES256, SHA256, DH14, it's most widely used and was standard in Tunnel Settings, then go for SHA512 and SHA1  
            self::$internalCacheOptionList['aes256-sha256-modp2048'] = 'aes256-sha256-modp2048';
            self::$internalCacheOptionList['aes256-sha512-modp2048'] = 'aes256-sha512-modp2048';
            self::$internalCacheOptionList['aes256-sha1-modp2048'] = 'aes256-sha1-modp2048';
// Same as above with AES128            
            self::$internalCacheOptionList['aes128-sha256-modp2048'] = 'aes128-sha256-modp2048';
            self::$internalCacheOptionList['aes128-sha512-modp2048'] = 'aes128-sha512-modp2048';
            self::$internalCacheOptionList['aes128-sha1-modp2048'] = 'aes128-sha1-modp2048';
// AES256GCM with widely used DH
            self::$internalCacheOptionList['aes256gcm16-modp2048'] = 'aes256gcm16-modp2048';
            self::$internalCacheOptionList['aes256gcm16-ecp521'] = 'aes256gcm16-ecp521';
            self::$internalCacheOptionList['aes256gcm16-curve25519'] = 'aes256gcm16-curve25519';
            self::$internalCacheOptionList['aes256gcm16-curve448'] = 'aes256gcm16-curve448';
// Same for AES128
            self::$internalCacheOptionList['aes128gcm16-modp2048'] = 'aes128gcm16-modp2048';
            self::$internalCacheOptionList['aes128gcm16-ecp521'] = 'aes128gcm16-ecp521';
            self::$internalCacheOptionList['aes128gcm16-curve25519'] = 'aes128gcm16-curve25519';
            self::$internalCacheOptionList['aes128gcm16-curve448'] = 'aes128gcm16-curve448';  
// Same as first AES256, SHA and DH16            
            self::$internalCacheOptionList['aes256-sha256-modp4096'] = 'aes256-sha256-modp4096';
            self::$internalCacheOptionList['aes256-sha512-modp4096'] = 'aes256-sha512-modp4096';
            self::$internalCacheOptionList['aes256-sha1-modp4096'] = 'aes256-sha1-modp4096';
// Same as above AES256, SHA and DH21            
            self::$internalCacheOptionList['aes256-sha256-ecp521'] = 'aes256-sha256-ecp521';
            self::$internalCacheOptionList['aes256-sha512-ecp521'] = 'aes256-sha512-ecp521';
            self::$internalCacheOptionList['aes256-sha1-ecp521'] = 'aes256-sha1-ecp521';

The default was AES256, SHA256, DH14 .. ist supported on most devices in the world and quite secure, then going to SHA512 for security and going down to SHA1 for compatibility. same to AES128 (noone uses 192), then we go for AES256GCM with most widely used DH, going down to AES128GCM for devices with lower power and then back to AES256 with known SHA's and DH16 and 21.

This is IMHO the most widely used algs .. used, not best or most secure

[mimugmail]

https://github.com/mimugmail/core/blob/patch-11/src/opnsense/mvc/app/models/OPNsense/IPsec/FieldTypes/IPsecProposalField.php#L71-L72

Here we need another for loop to lower the table because GCM already includes hashing like sha etc., it's not used nor used in GCM

[AdSchellevis]

@mimugmail if we could think of some sensible grouping, the following would be possible as well:

[AdSchellevis]

I think this 5ee2bef should cover most concerns, we can discuss grouping and texts, but the basic principles are there now. The Diffie Hellman Groups are in the description, which should also make it easier to find them.

We'll add groups to gather different options (common, insecure, ..), when not pushed in a group, the cipher choice ends up in Miscellaneous. By marking insecure options explicit, we'll at least inform people it's not recommended to use those, in which case I'll personally find it less problematic to offer them (when really deprecated upstream, it's out of our hands).

[OliHall]

Hi,

My issue is related to proposal selection, so I am adding it here. I am happy to move this to a new issue if you feel it should not be part of this one.

Referring to the new guide: IPsec - Roadwarriors IKEv2 EAP-MSCHAPv2

The default proposals recommended are:
IKE: aes256-sha256-modp2048
ESP: aes256-sha256-modp2048

These work for the native Windows 10 Pro (22H2) VPN client* and the native iOS (iPhone) client. However, When using the Windows 10 VPN client the tunnel becomes unresponsive after one hour due to failed ESP re-key.

*The Windows VPN client must have modp-2048 enabled by either changing a registry setting or by powershell in order to use the IKE proposal suggested above. See Here

To allow Windows 10 Pro (22H2) VPN client to re-key, there needs to be no PFS group in the ESP proposal:
i.e. The ESP proposal that works for re-key is: aes256-sha256.

In the old (Tunnel Settings) interface, the PFS group was separately selectable from the Encryption and Hash algorithms. In the new (Connections) interface, there appears to be no way to sepately select a proposal without a PFS group unless it is in the list of pre-defined proposals, which all contain a minimum of DH14 (modp-2048) PFS group.

Possible solutions:

1. Add to the list of selectable proposals - ESP proposal: aes256-sha256 (no pfs group)
2. Add a different method (e.g. a checkbox) to disable PFS from the selected ESP proposal

Additionally, I have noticed in the forum version of the guide linked above, the following setting was included: "Send certificate: Always". However, this setting was omitted from the web version of the guide which causes the iOS client not to connect. Adding "Send certificate: Always" allows the iOS VPN client to connect.

Many thanks,
Oli.

[AdSchellevis]

@OliHall 286ed62 adds the aes256-sha256 option, which should conclude this ticket.