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.
Maintainer: @pprindeville @Thermi
Environment: OpenWrt master r24041-74e7f8ebbd on WRT32x
Description:
The
/var/swanctl/swanctl.conffile 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
remoteblock in your/etc/config/ipsecfile):..then running
/etc/init.d/swanctl restartwith the above in place, will cause the following warning:ERROR: Can't have prfsha512 with aes256gcm16- this leads to an invalidswanctl.conffile being generated in/var/swanctlThe contents of the generated file look like:
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:
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_algorithmfor thecrypto_proposalfor theconfig remoteblock).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.confand set the outer IKE (non-children ESP) proposal to the desired:aes256gcm16-prfsha512-ecp384and manually re-runswanctl --load-all.. you will instead get swanctl to load correctly: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:
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.