Some troubles with RRAS IKEv2 with EAP or MSCHAPv2 with MAC/Iphone, Android and linux machines

Question

Some troubles with RRAS IKEv2 with EAP or MSCHAPv2 with MAC/Iphone, Android and linux machines

Pierre-Yves M 20

I built an RRAS server on Windows 2016 (tested in 2022 too) for the purpose of using IKEv2 service.

So I prepared the certificate template from my authority with the following parameters:

The desired duration
Authority compatibility => Windows Server 2016
Recipient compatibility => Windows 10 / Windows Server 2016
Extensions:
- Application Policies: Server Auth / IPSEC IKE intermediate / Client Auth / non-critical extension
- Key Usage: Digital signature / Allow key exchange only with key encryption / extension critical
Security: Give access to my RRAS computer object to make the enrollment
Cryptography:
- Maximum key size: 2048 Determined by CSP
- Requests must use one of the following: MS RSA SChannel Crypto Provider

I was then able to request a certificate by positioning the correct common name (external and internal DNS names) and associating it in the RRAS config, security tab.

Authentication Methods:

EAP
MS-CHAP v2
CHAP
Allow machine cert for IKEv2

Then from elevated powershell on server:

Set-VpnServerConfiguration -CustomPolicy -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -SALifeTimeSeconds 28800 -MMSALifeTimeSeconds 86400 -SAData SizeForRenegotiationKilobytes 1024000

$rootcert = ( Get-ChildItem -Path cert:LocalMachine\root | Where-Object -FilterScript { $_.Subject -Like "*CN=myorga*" } )
Set-VpnAuthProtocol -RootCertificateNameToAccept $rootcert -PassThru

Restart-Service RemoteAccess -PassThru

From Windows client in elevated prowershell after created the IKE connection in IKEv2 mode:

Set-VpnConnectionIPsecConfiguration -ConnectionName "IKE" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -Force

This client is on the same domain so through a GPO the machine already have the root CA certif on his container, and the connection works for my Windows client, but unable to get the connection to work on MacOS, Iphone, Android 12+ and linux.

On each of the cases where it does not work I was able to integrate the root certificate without problem so my concern does not come from there, in the logs of the linux machine I have the following sample:

Root CA has been placed on trusty CA, I downloaded the RRAS certif to use it on the config, select authentication EAP, and specified Ciphers as:

IKE=aes128-sha256-modp2048

For ESP I use:
ESP=aes128-sha256

And same result with :
ESP=aes128-sha256-modp2048

Jun 26 13:35:16 LAP charon-nm: 07[IKE] authentication of 'CN=internal-name, CN=external-name' with RSA signature successful
Jun 26 13:35:16 LAP charon-nm:07[IKE] server requested EAP_IDENTITY (id 0x00), sending 'user-test'
Jun 26 13:35:16 LAP charon-nm: 07[ENC] generating IKE_AUTH request 2 [ EAP/RES/ID ]
Jun 26 13:35:16 LAP charon-nm: 07[NET] sending packet: from IP-LAN[45713] to IP-PUB[4500] (96 bytes)
Jun 26 13:35:16 LAP charon-nm: 16[NET] received packet: from IP-PUB[4500] to IP-LAN[45713] (112 bytes)
Jun 26 13:35:16 LAP charon-nm:16[ENC] parsed IKE_AUTH response 2 [ EAP/REQ/MSCHAPV2 ]
Jun 26 13:35:16 LAP charon-nm:16[IKE] server requested EAP_MSCHAPV2 authentication (id 0x01)
Jun 26 13:35:16 LAP charon-nm: 16[ENC] generating IKE_AUTH request 3 [ EAP/RES/MSCHAPV2 ]
Jun 26 13:35:16 LAP charon-nm: 16[NET] sending packet: from IP-LAN[45713] to IP-PUB[4500] (144 bytes)
Jun 26 13:35:16 LAP charon-nm: 09[NET] received packet: from IP-PUB[4500] to IP-LAN[45713] (128 bytes)
Jun 26 13:35:16 LAP charon-nm:09[ENC] parsed IKE_AUTH response 3 [ EAP/REQ/MSCHAPV2 ]
Jun 26 13:35:16 LAP charon-nm:09[IKE] EAP-MS-CHAPv2 succeeded: '(null)'
Jun 26 13:35:16 LAP charon-nm:09[ENC] generating IKE_AUTH request 4 [ EAP/RES/MSCHAPV2 ]
Jun 26 13:35:16 LAP charon-nm: 09[NET] sending packet: from IP-LAN[45713] to IP-PUB[4500] (80 bytes)
Jun 26 13:35:16 LAP charon-nm: 08[NET] received packet: from IP-PUB[4500] to IP-LAN[45713] (80 bytes)
Jun 26 13:35:16 LAP charon-nm:08[ENC] parsed IKE_AUTH response 4 [ EAP/SUCC ]
Jun 26 13:35:16 LAP charon-nm: 08[IKE] EAP method EAP_MSCHAPV2 succeeded, MSK established
Jun 26 13:35:16 LAP charon-nm:08[IKE] authentication of 'user-test' (myself) with EAP
Jun 26 13:35:16 LAP charon-nm:08[ENC] generating IKE_AUTH request 5 [ AUTH ]
Jun 26 13:35:16 LAP charon-nm: 08[NET] sending packet: from IP-LAN[45713] to IP-PUB[4500] (112 bytes)
Jun 26 13:35:16 LAP charon-nm: 11[NET] received packet: from IP-PUB[4500] to IP-LAN[45713] (80 bytes)
Jun 26 13:35:16 LAP charon-nm: 11[ENC] parsed IKE_AUTH response 5 [ N(FAIL_CP_REQ) ]
Jun 26 13:35:16 LAP charon-nm: 11[IKE] AUTH payload missing
Jun 26 13:35:16 LAP charon-nm: 11[ENC] generating INFORMATIONAL request 6 [ N(AUTH_FAILED) ]
Jun 26 13:35:16 LAP charon-nm: 11[NET] sending packet: from IP-LAN[45713] to IP-PUB[4500] (80 bytes)

Impossible in the state to pass a connection with something other than the Windows machine.

So the question, are we sure that devices other than Windows can access a Windows 2016 or later IKEv2 (EAP / MSChapv2) VPN server?

And if so, does my concern speak to someone?

Thanks for reading me !

7 answers

Your answer

Answer 1

Hello Pierre-Yves,

Yes, I am sure that non-Windows devices can access Windows 2016 via an IKEv2 (EAP-MSCHAPv2) VPN connection.

The first sign of the problem in your trace data is the text "[N(FAIL_CP_REQ)]" - this indicates an error code with the full (RFC 5996) name of "FAILED_CP_REQUIRED".

The IKEv2 packet exchanges should look like this extract from RFC 5996 (appendix C.3):

   first request       --> IDi,
                           [N(INITIAL_CONTACT)],
                           [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
                           [IDr],
                           [CP(CFG_REQUEST)],
                           [N(IPCOMP_SUPPORTED)+],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, TSi, TSr,
                           [V+][N+]

   first response      <-- IDr, [CERT+], AUTH,
                           EAP,
                           [V+][N+]

                     / --> EAP
   repeat 1..N times |
                     \ <-- EAP

   last request        --> AUTH

   last response       <-- AUTH,
                           [CP(CFG_REPLY)],
                           [N(IPCOMP_SUPPORTED)],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, TSi, TSr,
                           [N(ADDITIONAL_TS_POSSIBLE)],
                           [V+][N+]

AlthoughThis trace shows the packets that are typically exchanged in your scenario:

User's image

Gary

Answer 2

Pierre-Yves M 20

Ok Gary and thanks for your answer,

I will have a look on that!

Answer 3

Pierre-Yves M 20

Regarding Android or Ipad where I cannot specify much parameters, we only have remote dest, credentials, and tunnel type (IKE EAP/MSCHAP), this problem can not be solved from the RRAS?

Gary Nebbett 6,216 Reputation points

2023-06-27T16:28:49.9666667+00:00

Hello Pierre-Yves,

No, the problem can't be solved or compensated for by RRAS - the client needs to know what address has been assigned to it (and that is not possible without an exchange of "configuration" payloads).

Gary
Pierre-Yves M 20 Reputation points

2023-06-27T16:33:58.75+00:00

Hum ok, but in this case from my phone or tablet I can only specify parameters provided above
Gary Nebbett 6,216 Reputation points

2023-06-27T16:43:41.25+00:00

Hello Pierre-Yves,

Are you using the "built-in" IKEv2 providers for Android and iOS? If so, it would be very hard to explain why the configuration request payload was missing. If you are using something different (e.g. strongSwan) then you should have some more configuration options.

Gary
Pierre-Yves M 20 Reputation points

2023-06-27T16:55:14.9933333+00:00

Yes I use the built-in config, So I specify as follow:

Server : VPN_Public_name

Id. distant : VPN_Public_name

Authentication type:

username: filled

password: filled

I have imported the ROOT CA of my authority and this don't work, I will put a wireshark on server side to analyze others devices than linux.
Gary Nebbett 6,216 Reputation points

2023-06-27T17:12:28.1033333+00:00

Hello Pierre-Yves,

One thing that looks odd in your configuration is "Id. distant" - is that a translation from some French text? A plausible English name could be "Remote Id", but it is unusual to set that on a client. The IKEv2 RFC says:

The optional payload IDr enables the initiator to specify to which of the responder's identities it wants to talk.

IDr is the "Remote Id". Typically, RRAS will only have one Id.

Gary
Pierre-Yves M 20 Reputation points

2023-06-28T07:24:16.8966667+00:00

Hey Gary, yes it was french word, I suppose Remote id yes, I find this method on forums where it's recommended to fill Server and Remote Id with the same dns name, this filed is mandatory.
Pierre-Yves M 20 Reputation points

2023-06-28T07:32:02.5133333+00:00

But when I try to connect with a macbook or an Ipad I see nothing on RRAS event viewer.
Gary Nebbett 6,216 Reputation points

2023-06-28T08:54:52.95+00:00

Hello Pierre-Yves,

I don't have a MacBook, but I do have an iPad and Android phone.

Let's tackle the iPad first. My iPad settings are:

Type: IKEv2

Description: [something meaningful to me]

Server: 192.168.0.3

Remote ID: RAY

Local ID: [empty]

User Authentication: Username

Username: gary

Password: xxxxxx

In this setting the "Remote ID" is not sent as an IDr payload, but is just used locally to match the name in the server certificate.

There is some tracing that can be performed on the RRAS system, but you probably would not be able to interpret the (binary) trace data.

Gary
Pierre-Yves M 20 Reputation points

2023-06-28T12:04:15.26+00:00

But for this case I cannot see anything arriving at the gateway, strange but I think I have some element which are missing.
Pierre-Yves M 20 Reputation points

2023-06-28T14:46:44.3+00:00
Ok, I had a network issue which is now fixed regarding my attempt with my Ipad, and now I have a network trace:

LAN_IP.500 > VPN_IP.500: [udp sum ok] isakmp 2.0 msgid 00000000 cookie e17057c9351356eb->0000000000000000: parent_sa ikev2_init[I]: LAN_IP.500 > VPN_IP.500: [udp sum ok] isakmp 2.0 msgid 00000000 cookie e17057c9351356eb->61a0fdd571fe3d5e: parent_sa ikev2_init[R]:

I only got this and nothing after that, on my Ipad I activate the connection and it cuts off immediately.

And don't get logs on VPN's event viewer for Ipad, Mac and Android.
Gary Nebbett 6,216 Reputation points

2023-06-28T15:11:52.7333333+00:00

Hello Pierre-Yves,

I guess that you have edited that brief trace extract: the "address" information indicates that two packets went from LAN_IP to VPN_IP, but the details show that one message was from the initiator and one was from the responder - that looks very much like a contradiction.

These first two packets are not encrypted - you might be able to get some idea of what might be wrong by looking at the packets in detail.

Gary
Pierre-Yves M 20 Reputation points

2023-06-28T15:46:40.41+00:00

Yes I masked the ips of the client and the server,

On the other hand, if my server-side settings are good, and I fill in the few settings on my Ipad, I'm a little stuck on what I can do to move forward.

Answer 4

A tcpdump extract for the linux attempt :

IP_DNS.53 > IP-LAN.55258: [udp sum ok] 38237 q: A? remote-VPN. 1/0/1 remote-VPN. A IP-PUB ar: . OPT UDPsize=4096 (72)
IP_DNS.53 > IP-LAN.34656: [udp sum ok] 10760 q: A? remote-VPN. 1/0/1 remote-VPN. A IP-PUB ar: . OPT UDPsize=4096 (72)
IP-LAN.60908 > IP-PUB.500: [bad udp cksum 0x9a98 -> 0x8249!] isakmp 2.0 msgid 00000000 cookie 1412d1d2645a4f9f->0000000000000000: parent_sa ikev2_init[I]:
IP-PUB.500 > IP-LAN.60908: [udp sum ok] isakmp 2.0 msgid 00000000 cookie 1412d1d2645a4f9f->eff776d3d4e46255: parent_sa ikev2_init[R]:
IP-LAN.51846 > IP-PUB.4500: [bad udp cksum 0x9a3c -> 0x6c6e!] NONESP-encap: isakmp 2.0 msgid 00000001 cookie 1412d1d2645a4f9f->eff776d3d4e46255: child_sa  ikev2_auth[I]:
IP-PUB.4500 > IP-LAN.51846: NONESP-encap: isakmp 2.0 msgid 00000001 cookie 1412d1d2645a4f9f->eff776d3d4e46255: child_sa  ikev2_auth[R]: [|v2e] (len mismatch: isakmp 2080/ip 1468)
IP-PUB > IP-LAN: ip-proto-17 IP-LAN.51846 > IP-PUB.4500: [bad udp cksum 0x992c -> 0xcb65!] NONESP-encap: isakmp 2.0 msgid 00000002 cookie 1412d1d2645a4f9f->eff776d3d4e46255: child_sa  ikev2_auth[I]:
IP-PUB.4500 > IP-LAN.51846: [udp sum ok] NONESP-encap: isakmp 2.0 msgid 00000002 cookie 1412d1d2645a4f9f->eff776d3d4e46255: child_sa  ikev2_auth[R]:
IP-LAN.51846 > IP-PUB.4500: [bad udp cksum 0x995c -> 0xfdda!] NONESP-encap: isakmp 2.0 msgid 00000003 cookie 1412d1d2645a4f9f->eff776d3d4e46255: child_sa  ikev2_auth[I]:
IP-PUB.4500 > IP-LAN.51846: [udp sum ok] NONESP-encap: isakmp 2.0 msgid 00000003 cookie 1412d1d2645a4f9f->eff776d3d4e46255: child_sa  ikev2_auth[R]:
IP-LAN.51846 > IP-PUB.4500: [bad udp cksum 0x991c -> 0xc29b!] NONESP-encap: isakmp 2.0 msgid 00000004 cookie 1412d1d2645a4f9f->eff776d3d4e46255: child_sa  ikev2_auth[I]:
IP-PUB.4500 > IP-LAN.51846: [udp sum ok] NONESP-encap: isakmp 2.0 msgid 00000004 cookie 1412d1d2645a4f9f->eff776d3d4e46255: child_sa  ikev2_auth[R]:
IP-LAN.51846 > IP-PUB.4500: [bad udp cksum 0x993c -> 0xa1ed!] NONESP-encap: isakmp 2.0 msgid 00000005 cookie 1412d1d2645a4f9f->eff776d3d4e46255: child_sa  ikev2_auth[I]:
IP-PUB.4500 > IP-LAN.51846: [udp sum ok] NONESP-encap: isakmp 2.0 msgid 00000005 cookie 1412d1d2645a4f9f->eff776d3d4e46255: child_sa  ikev2_auth[R]:
IP-LAN.51846 > IP-PUB.4500: [bad udp cksum 0x991c -> 0x52b3!] NONESP-encap: isakmp 2.0 msgid 00000006 cookie 1412d1d2645a4f9f->eff776d3d4e46255: child_sa  inf2[I]:
IP-PUB.4500 > IP-LAN.51846: [udp sum ok] NONESP-encap: isakmp 2.0 msgid 00000006 cookie 1412d1d2645a4f9f->eff776d3d4e46255: child_sa  inf2[R]:

Gary Nebbett 6,216 Reputation points

2023-06-27T16:55:30.1733333+00:00

Hello Pierre-Yves,

tcpdump traces are not much use in this case - the configuration payload is in one of the encrypted messages and is small in size (its presence/absence cannot be inferred from the total message size).

Gary
Pierre-Yves M 20 Reputation points

2023-06-28T16:47:17.59+00:00

I revert to default cipher with 3des-sha1-modp1024 and I get much element,

IP_LAN.500 > VPN_IP.500: [udp sum ok] isakmp 2.0 msgid 00000000 cookie a5c84b7a81698476->0000000000000000: parent_sa ikev2_init[I]: VPN_IP.500 > IP_LAN.500: [udp sum ok] isakmp 2.0 msgid 00000000 cookie a5c84b7a81698476->6c6a75d1c9f8624d: parent_sa ikev2_init[R]: IP_LAN.500 > VPN_IP.500: [udp sum ok] isakmp 2.0 msgid 00000000 cookie a5c84b7a81698476->0000000000000000: parent_sa ikev2_init[I]: VPN_IP.500 > IP_LAN.500: [udp sum ok] isakmp 2.0 msgid 00000000 cookie a5c84b7a81698476->eb87f0aa960e4a40: parent_sa ikev2_init[R]: IP_LAN.4500 > VPN_IP.4500: [udp sum ok] NONESP-encap: isakmp 2.0 msgid 00000001 cookie a5c84b7a81698476->eb87f0aa960e4a40: child_sa ikev2_auth[I]: VPN_IP.4500 > IP_LAN.4500: NONESP-encap: isakmp 2.0 msgid 00000001 cookie a5c84b7a81698476->eb87f0aa960e4a40: child_sa ikev2_auth[R]: [|v2e] (len mismatch: isakmp 2060/ip 1468) VPN_IP > IP_LAN: ip-proto-17
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Pierre-Yves M 20 Reputation points

2023-06-29T15:01:36.4633333+00:00

This reminds me of a packet fragmentation issue, Windows 10 clients support IKEv2 fragmentation by default which might explain why it works with him.
Pierre-Yves M 20 Reputation points

2023-06-30T08:14:27.37+00:00

Another precisions, in this case I don't use NPS, it doesn't seem necessary to me but maybe I'm wrong?

Answer 5

Pierre-Yves M 20

Another point to check regarding that, the root certificates as well as the RRAS certificate were exported in base 64, it seems that it is necessary for me for at least the Linux machine to have this certificate in hand and not to simply retrieve it by initiating the connection, in any case I have logs that go further in the case of doing this import.

Share via

Some troubles with RRAS IKEv2 with EAP or MSCHAPv2 with MAC/Iphone, Android and linux machines

7 answers

Your answer