What protocol does IKEV2 VPN use?

I have IKEv2 VPN working fine with Windows 10 IKEv2 client when using only RADIUS and no Duo. My NPS server is set to use only MSCHAPv2 and not EAP-MSCHAPv2, so I don’t think that lack of EAP-MSCHAPv2 support is the issue, i.e., IKEv2 VPN connects without it in my NPS server settings.

When I throw Duo into the mix, I try to log into the IKEv2 VPN, I get the prompt on my phone and allow it, and the VPN rapidly says “Cannot connect to…” my IKEv2 VPN name. In FSM traffic monitor (with Authentication set to Debug level), I get:

2020-03-08 21:15:11 admd msg=Authentication of MUVPN user [Gregg@Duo] from 172.112.x.y was accepted msg_id=“1100-0004” Event
2020-03-08 21:15:11 iked msg=ike2_StoreMSCHAPv2Result: Received authentication result does not have the expected content Debug

What does “Received authentication result does not have the expected content” mean? I have no idea and Google searches come up with nothing helpful.

Can Duo work with an IKEv2 VPN that works fine using only MSCHAPv2 for a plain-RADIUS connection?

I asked Duo support about using Duo with WatchGuard IKEv2 and they say WG uses EAP-MSCHAPv2, and Duo is not compatible with EAP-MSCHAPv2. Duo IS compatible with MSCHAPv2. They asked, “Is it certain that the WatchGuard IKEv2 VPN isn’t using EAP-MSCHAPv2?” I don’t think it is certain because the log line says "iked msg=ike2_StoreMSCHAPv2Result", which to me indicates it is indeed using plain MSCHAPv2

The WatchGuard firewall sees the authentication successfully, but it appears to be missing some mystery content when it is sent back to the firewall. I don’t know what the “expected content” is supposed to be.

I am at a loss to figure it out.

Gregg Hill

Comments

  • I just did more testing. On my NPS server, I removed MSCHAPv2 and added EAP-MSCHAPv2 as the only protocol, then tried to connect, and I got an instant "Cannot connect to WG IKEv2" message. Even the working plain-RADIUS breaks with only EAP-MSCHAPv2 protocol. If I add MSCHAPv2 back, or go to only MSCHAPv2, plain RADIUS works again. Using only EAP-MSCHAPv2, my firewall live logging shows:

    "2020-03-10 12:03:24 admd msg=Authentication of MUVPN user [Gregg@Duo] from x.x.x.x was rejected, received an Access-Reject response from the (192.168.16.11) server msg_id="1100-0005" Event

    It rejects the EAP-MSCHAPv2 connection outright.

    So, yes, I can confirm that WatchGuard's IKEv2 VPN uses only MSCHAPv2.

    Now, I get to back to dancing with Duo.

    Gregg Hill

  • These questions remain unanswered:

    What does “Received authentication result does not have the expected content” mean? I have no idea and Google searches come up with nothing helpful. What content does WatchGuard expect to see?

    Can Duo work with an IKEv2 VPN that works fine using only MSCHAPv2 for a plain-RADIUS connection? E.g., is there something in WatchGuard IKEv2 that would stop Duo form working?

    Gregg Hill

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @Greggmh123
    The firebox still expects to see Attribute 11 (FilterID) with the user group -- is the RADIUS server (in this case, RADIUS proxy, DUO), providing it? We've seen previous instances of DUO stripping that attribute.

    As far as I'm aware, there is nothing in DUO that should be incompatible. So long as we're getting a valid ACCESS-ACCEPT with that attribute, all should be good.

    -James Carson
    WatchGuard Customer Support

  • Duo works for the SSLVPN using the FilterID of SSLVPN-Users. My NPS also has a FilterID of IKEv2-Users for the IKEv2 Network Policy. You could be correct that Duo is stripping it, so I will ask them.

    Gregg Hill

  • I would expect that Diagnostic Logging in XTM for Authentication, set to Debug, would show you the FilterID being returned to XTM.

  • Bruce,

    With logging at Debug for Authentication, IKEv2 VPN, and SSLVPN, there are log references to the Filter-ID "IKEv2-Users" in FSM traffic monitor logs, but it still won't connect when using Duo.

    I will open a support case.

    Gregg Hill

  • I just opened Case Number 01347831.

    Gregg Hill

Sign In to comment.