For example, it seems that MacOS (10.12 Sierra) native client supports
only EAP-MSCHAPv2 and rejects any other methods, e.g.
when I configure swanctl.conf in the following way:
[ ... ]
auth = eap-peap
# auth = eap-ttls
I get the following messages in logs:
Mar 2 14:23:32 vpn strongswan: 16[ENC] <ikev2-userpass|4> generating
IKE_AUTH response 1 [ IDr CERT CERT AUTH EAP/REQ/PEAP ]
[ ... ]
Mar 2 14:23:32 vpn strongswan: 11[ENC] <ikev2-userpass|4> parsed
IKE_AUTH request 2 [ EAP/RES/NAK ]
Mar 2 14:23:32 vpn strongswan: 11[IKE] <ikev2-userpass|4> received
EAP_NAK, sending EAP_FAILURE
and same for EAP-TTLS: "generating IKE_AUTH response 1 [ IDr CERT CERT
AUTH EAP/REQ/TTLS ]"receive EAP/RES/NAK
So the question is there an alternative to EAP-MSCHAPv2 which can be
used on mostly deployed clients?
On 3/2/18 10:48 AM, Volodymyr Litovka wrote:
which, from your experience, is the lowest common denominator for EAP
methods availability on various clients (hardware appliances [Cisco,
Juniper, Mikrotik, etc], software clients [Windows, MacOS, iOS]), if
we don't talk about EAP-MSCHAPv2 ?
Since mschap use NTLM hash which isn't secure enough, it's not bad to
store credentials in backend in a non-reversable format like SHA2.
Looking at the following table -
http://deployingradius.com/documents/protocols/compatibility.html - I
see two possible ways to achieve this target: EAP-GTC or PAP, tunneled
inside other EAP method (TTLS, PEAP, other which require only server
So the question is - which pair of inner/outer EAP methods you will
recommend to choose in order to get support for most client types and
to have ability to store credentials in backend in non-reversable hash
"Vision without Execution is Hallucination." -- Thomas Edison