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:

connections {
    ikev2-userpass {
      [ ... ]
      remote-1 {
          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:
Hi colleagues,

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 - - 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 certificate).

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 form?

Thank you.

Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison

Reply via email to