Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

strongswan: swanctl init script incorrectly rejects IKE proposal combination w/ hash algo - fails to load connections #22245

Open
aleks-mariusz opened this issue Sep 29, 2023 · 4 comments

Comments

@aleks-mariusz
Copy link

aleks-mariusz commented Sep 29, 2023

Maintainer: @pprindeville @Thermi
Environment: OpenWrt master r24041-74e7f8ebbd on WRT32x

Description:

The /var/swanctl/swanctl.conf file that the init script generates, thinks that if you specify an Authenticated Encryption (AEAD) Algorithms (in my case, aes256gcm16) then you canNOT also specify a hash_algorithm as well. This seems to not be true for IKE proposals, since the connection block then gets skipped being loaded by swanctl:

From my understanding, the /etc/config/ipsec "remote" block this proposal is referenced from is the one that defines the overall IKE parameters served by charon in user-space.

So for example, the following crypto_proposal excerpt (referenced in the remote block in your /etc/config/ipsec file):

config 'crypto_proposal' 'ike_proposal'
        option 'encryption_algorithm' 'aes256gcm16'
        option 'hash_algorithm' 'prfsha512' # <-- init script thinks this shouldn't be here for IKE proposal
        option 'dh_group' 'ecp384'

..then running /etc/init.d/swanctl restart with the above in place, will cause the following warning: ERROR: Can't have prfsha512 with aes256gcm16 - this leads to an invalid swanctl.conf file being generated in /var/swanctl

The contents of the generated file look like:

# generated by /etc/init.d/swanctl
# config for all_remote_ikev2
connections {
  remote_block_name {
[...snip...]
    version = 2
    proposals = aes256gcm16-ecp384
    dpd_delay = 300s
[...snip...]
} 
[...snipping out other authorities/pools blocks, as irrelevant...]   

What is seen above is the proposal that are relevant for the IKE first-phase (not the inner children{} block which deals with the ESP proposal).

And as a result, this keeps swanctl from loading the connections-block properly:

loaded authority 'all_remote_ikev2'
successfully loaded 1 authorities, 0 unloaded
loaded pool 'ipv4pool'
loaded pool 'ipv6pool'
successfully loaded 2 pools, 0 unloaded
loading connection 'all_remote_ikev2' failed: invalid value for: proposals, config discarded
loaded 0 of 1 connections, 1 failed to load, 0 unloaded

Note: The earlier init-script "ERROR" seems is more like a warning, as it's merely removing the hash_algorithm (not-so silently) but continues to still proceed generating a config (similarly you could just remove/comment out the hash_algorithm for the crypto_proposal for the config remote block).

However swanctl, while still having been started, is running in a useless-state as it hadn't loaded the offending parent block (the connection object).

When a client attempts to connect, it will fail with this error on the server side:

Thu Sep 28 19:18:06 2023 daemon.info ipsec: 14[IKE] no IKE config found for 10.1.2.3...192.168.4.5, sending NO_PROPOSAL_CHOSEN

(as no connection blocks have been loaded, it doesn't know what to do with any connecting client).

If you instead manually edit /var/swanctl/swanctl.conf and set the outer IKE (non-children ESP) proposal to the desired: aes256gcm16-prfsha512-ecp384 and manually re-run swanctl --load-all.. you will instead get swanctl to load correctly:

loaded authority 'all_remote_ikev2'
successfully loaded 1 authorities, 0 unloaded
loaded pool 'ipv4pool'
loaded pool 'ipv6pool'
successfully loaded 2 pools, 0 unloaded
loaded connection 'all_remote_ikev2'
successfully loaded 1 connections, 0 unloaded

I believe the fix is as simple as getting rid of these few lines (in the config_ike_proposal() function). I can open a PR tmrw if it's as simple as that, but wanted to get some feedback first and run it by you way-smarter folks.

btw, I also see the following syslog messages:

Fri Sep 29 01:53:48 2023 daemon.info ipsec: 10[CFG] a PRF algorithm is mandatory in IKE proposals

however my brain is a bit too fried now (2am here) having spent hours on this to figure out if this is related (and if it's even a confirmation of all the above) or not.

@aleks-mariusz aleks-mariusz changed the title strongswan: swanctl init script incorrectly rejects esp proposal combination w/ hash_algo, and doesn't load connections strongswan: swanctl init script incorrectly rejects ike proposal combination w/ hash_algo, and doesn't load connections Sep 29, 2023
@aleks-mariusz aleks-mariusz changed the title strongswan: swanctl init script incorrectly rejects ike proposal combination w/ hash_algo, and doesn't load connections strongswan: swanctl init script incorrectly rejects IKE proposal combination w/ hash algo - fails to load connections Sep 29, 2023
@aleks-mariusz
Copy link
Author

BTW i have some other ideas for enhancements to expand the settings swanctl.conf supports, that the swanctl init script currently does not know how to handle.. should i open separate issues or add them to this issue since it's about swanctl init script anyway?

I've more details listed in this forum post.

@pprindeville
Copy link
Member

I'll look at any PR's submitted, but I ask that they be broken up logically so that each one addresses a single individual issue.

kevinoid added a commit to kevinoid/packages that referenced this issue Dec 1, 2024
Support configuring the [Pseudo-Random Function] in addition to the
encryption, integrity/hash, and DH group.  This is particularly useful
with AEAD ciphers, which don't have an integrity/hash algorithm from
which the PRF can be derived, which can result in errors such as

> a PRF algorithm is mandatory in IKE proposals

The PRF algorithm can also be used with an integrity/hash algorithm to
override the default mapping.

[Pseudo-Random Function]: https://docs.strongswan.org/docs/latest/config/IKEv2CipherSuites.html#_pseudo_random_functions

Fixes: openwrt#22245
Signed-off-by: Kevin Locke <[email protected]>
@kevinoid
Copy link

kevinoid commented Dec 1, 2024

I started working on a fix for this, before realizing that it is already supported: The PRF algorithm must be configured using prf_algorithm rather than hash_algorithm. Configuring

config 'crypto_proposal' 'ike_proposal'
        option 'encryption_algorithm' 'aes256gcm16'
        option 'prf_algorithm' 'prfsha512'
        option 'dh_group' 'ecp384'

Generates the expected proposals = aes256gcm16-prfsha512-ecp384 in /var/swanctl/swanctl.conf for me.

@aleks-mariusz
Copy link
Author

hi kevinoid, thanks so much for PR'ifying these! I had a look and they look much better than what i think would have came up with!

@pprindeville can you please also have a look and approve when you have a chance?

#25474
#25473
#25472

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants