strongSwan

Due to how the identities defined as selectors in ipsec.secrets are parsed a secret associated with maverick will only match an identity of type ID_FQDN (unless you explicitly configure keyid:maverick as selector).

Perfect thanks, this fixed the issue for me!

I assume you didn't use an EAP-Identity exchange above, so the IKE identities were used for the lookup, as only there is it even possible to define an identity type. That's because identities sent in EAP-Identity payloads (which is also what's sent to the RADIUS server) have no types associated with them (they are just binary blobs). So when receiving such an identity strongSwan first checks if it is ASN.1 encoded (if so, it is assumed to be a DN) and if not, uses the same identity parsing heuristic as above to create an identity object, so you'll most likely have a match when using an EAP-Identity exchange.

It didn't make a difference including eap_identity=%any, eap_identity=%identity (docs aren't clear on which is which) or not using it at all.

I assume you didn't use an EAP-Identity exchange above, so the IKE identities were used for the lookup, as only there is it even possible to define an identity type. That's because identities sent in EAP-Identity payloads (which is also what's sent to the RADIUS server) have no types associated with them (they are just binary blobs). So when receiving such an identity strongSwan first checks if it is ASN.1 encoded (if so, it is assumed to be a DN) and if not, uses the same identity parsing heuristic as above to create an identity object, so you'll most likely have a match when using an EAP-Identity exchange.

It didn't make a difference including eap_identity=%any, eap_identity=%identity (docs aren't clear on which is which) or not using it at all.

Both are the same. If you configure it you should see an EAP-Identity exchange in the log before the actual authentication (requires the eap-identity plugin).