Getting nowhere with IKEv2

Hi,

Been using SSL VPN for mobile users for a while with no real problems.
Have just upgraded to a new M370 running 12.5 and am trying out the IKEv2 to see how it compares. Unfortunately I'm getting nowhere.

I've been through the configuration wizard as per the documentation but can't connect no matter what I do.

I've tried Windows 10 and iOS, both inside and outside the local network. In all cases it fails immediately with a variety of errors, ranging from "IKEv2 credentials" errors to simply "Can't connect...".

I have no idea where to even start in diagnosing this.

With the SSL VPNs, I'm using both RADIUS with Duo 2FA and also Firebox-DB users, both of which work flawlessly. I've tried both with IKEv2 and neither work at all.

One thing I did notice was that the wizard doesn't seem to actually create a policy to allow IPSec traffic in from the outside world - am I misunderstanding something or should I be adding that myself? I did try adding an IPSec packet filter policy but the results were the same.

Any help appreciated as I'm tearing my hair out.

Comments

  • In the same boat here. It tells me the Radius authentication was valid, but my laptop tells me it can't connect to the server.

  • One of us needs to open a support case!

    Gregg Hill

  • edited December 2019

    I am not about to read 11 pages to find their solution on four hours of sleep! To be clear, my IKEv2 VPN works perfectly if I use a Firebox-DB user. It fails to connect if I use a RADIUS/Duo-2FA authenticated user. It gets to the point of my allowing the Duo prompt, then instantly fails.

    It does not matter how I start that VPN connection, either via Settings or via the tray app, which is what that article seems to be implying is an issue.

    Gregg Hill

  • @Greggmh123 said:
    One of us needs to open a support case!

    I stated a support case on Friday, we'll see if I hear back from WG anytime soon.

  • @Uncluesteve said:

    @Greggmh123 said:
    One of us needs to open a support case!

    I stated a support case on Friday, we'll see if I hear back from WG anytime soon.

    I await good news with bated breath!

    If I can clear my noggin for a few minutes, I'll test again. Thank you for being hte guinea pig here.

    Gregg

    Gregg Hill

  • @Uncluesteve said:

    @Greggmh123 said:
    One of us needs to open a support case!

    I stated a support case on Friday, we'll see if I hear back from WG anytime soon.

    Any news yet from WatchGuard on this issue?

    Gregg Hill

  • I would interested in seeing the reply to your ticket.

  • Here is part of the debug Log.

    2020-01-02 23:29:53 iked ike2_process_EAPAuthResult: Store necessary information from authentication result Debug
    2020-01-02 23:29:53 iked ike2_StoreMSCHAPv2Result: Received authentication result does not have the expected content Debug
    2020-01-02 23:29:53 iked MSCHAPv2 state change: MSCHAPV2_AUTH_WAIT ==> MSCHAPV2_FAIL, reason: "Process authentication result failed" Debug

    Here is the finally word on me WG Support case.

    Synology has confirmed that a valid certificate is needed on the DC to make all of this work. So I will be proceeding with the NPS service on the DC.

    J H
    2020-01-16 07:49:00
    Please confirm the below requirements for CA's to allow the Synology RADIUS service to authenticate agents a Windows AD server.

    • It is my understanding that the CA can not be a self-signed certificate for this to work. please correct me if this is not true.
    • Also, please point to your knowledgebase to show what instructions exist from Synology to help users to set this up properly.
      Thanks

    Certificate requirements

    • All certificates that are used for network access authentication with EAP-TLS and PEAP must meet the requirements for X.509 certificates and work for connections that use Secure Sockets Layer-Transport Level Security (SSL/TLS). Both client and server certificates have additional requirements.

    xxxxxx (Synology Support)
    2020-01-16 11:13:46
    Hello,
    You are correct that a Self Signed Certificate would not suffice for what you are wanting to do. This link https://www.synology.com/en-global/knowledgebase/DSM/help/RadiusServer/rad_desc will show you how to configure your RADIUS server, and even backup/restore RADIUS Server as well as answer other questions you may have.
    Please let us know if you still have questions or if you need further assistance.
    Best regards,
    xxx

  • @Uncluesteve,

    Thank you for the update. I am still fighting this IKEv2 issue. I have a Windows Server 2019 Standard server running NPS and the Duo Security authentication gateway. That works for the SSLVPN, but not for IKEv2.

    It works with Firebox-DB user, but not with Duo and RADIUS. I also cannot get it to work with plain RADIUS and no Duo.

    Gregg Hill

  • Have you guys tried using AuthPoint? Aside from my struggle with the Windows Server's firewall (mostly my own fault), the process seems to work well..

    Adrian from Australia

  • Adrian, I cannot get even basic RADIUS to work with IKEv2, so I don't think AuthPoint will work.

    Gregg Hill

  • @Greggmh123 How have you configured the IKEv2-policy in the NPS radius server?
    https://watchguardsupport.secure.force.com/publicKB?type=Article&SFDCID=kA10H000000g3AOSAY&lang=en_US

    Check this following short video about my Lab IKEv2-Policy in NPS:
    https://www.screencast.com/t/kqPRRs5Pe

    !! The PAP unencrypted authentication option is only for testing with Firebox Web Auth, port 4100 or if you use radius with sslvpn !!

    You also need a Radius Client config in the NPS. Firebox device IP and a shared Secret that is the same what you configure in the
    Firebox radius settings.

    You can then use this same IKEv2-Policy with AuthPoint and it’s MS-CHAPv2 config.
    You need to add a new Radius client with the AuthPoint Gateway address.
    The Shared Secret is the same as Firebox radius uses with the AuthPoint GW radius server.

    Check also that the Connection Request Policy allows the connection from Firebox and/or AuthPoint GW.

  • Kimmo,

    I have a working NPS/RADIUS for my SSLVPN that uses Duo Security for 2FA. My Windows 2019 server's setup is nearly identical to your lab video, except that I did not have the box checked to ignore user account dial-in properties.

    My shared secret is 37 characters long.

    In my current working setup for the SSLVPN, I had added the IKEv2-Users filter-id and it still failed. I am going to create a separate network policy just for IKEv2 to see if that works. I suspect that it just won't work when Duo is installed.

    Gregg Hill

  • Kimmo,

    You said "You also need a Radius Client config in the NPS. Firebox device IP...."

    If I set the Firebox' LAN IP in the RADIUS Client setup, RADIUS auth for SSLVPN fails. I have to put my NPS server's LAN IP in that section and SSLVPN auth works.

    I tried a separate network policy just for IKEv2 and it prevents my SSLVPN from authenticating.

    Gregg Hill

  • I have AuthPoint working now for IKEv2 VPN, SSLVPN, and for port 4100 authentication. Duo works for SSLVPN and for port 4100 authentication, but not IKEv2. On the NPS server, I have one RADIUS Client with the LAN IP of the AuthPoint gateway / NPS server (both are on the same server).

    Duo still fails, which may be an actual incompatibility between WatchGuard and Duo specifically with IKEv2. When I try to connect the IKEv2 VPN, I get the Duo prompt and OK it, then I get the following in FSM traffic monitor.

    2020-03-08 21:15:11 admd msg=Authentication of MUVPN user [[email protected]] from 192.168.16.191 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

    I cannot find any relevant information for the "Received authentication result does not have the expected content" message.

    Gregg Hill

  • edited March 2020

    As a side note regarding Duo compatibility, this article https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/authentication/radius_server_auth_about_c.html states, "Mobile VPN with IKEv2 authentication — EAP-MSCHAPv2", and Duo said a few months ago that they do no support EAP-MSCHAPv2...but I don't think it's used anyway.

    I am not sure if that "IKEv2 authentication uses EAP-MSCHAPv2" is correct, because EAP-MSCHAPv2 is nowhere in my NPS setup. Maybe it's used behind the scenes somewhere, but AuthPoint works using just MSCHAPv2 showing in my NPS network policy.

    EDIT: Also, this article https://watchguardsupport.secure.force.com/publicKB?type=Article&SFDCID=kA10H000000g3AOSAY&lang=en_US makes no mention of the EAP-MSCHAPv2 requirement; it just says to use MSCHAPv2.

    Gregg Hill

  • I still do not have an answer from Duo, but WG support says that IKEv2 VPN uses only MSCHAPv2. They think that Duo is the issue.

    On a side note for anyone trying unsuccessfully to use AuthPoint with IKEv2 VPN, what is your AuthPoint gateway version?

    Gregg Hill

  • Hello,

    Getting this problem as well - "cannot get even basic RADIUS to work with IKEv2, so I don't think AuthPoint will work." I have the same feeling.

    I'm able to connect and have access to internet/networks with firebox db authentication.

    If I use radius, the cliente connects and authenticates, but no internet access/networks are available. Seems full-tunnel don't work, don't know why.
    Already opened a support ticket.

    Please let me know if you got this working,

    Regards

  • Hello everyone!

    Wondering if anyone ever got useful feedback from either WatchGuard or Duo on this. I am also getting the "Received authentication result does not have the expected content" after accepting the Duo request. It works for SSLVPN but not IKEv2.

  • Chase,

    Duo 2FA still does not work with WatchGuard's IKEv2 VPN. It is a Duo problem.

    AuthPoint works with it using the current AuthPoint gateway version.

    Gregg Hill

  • If you are using Freeradius , try setting

    use_mppe = yes

    in mschap.conf

Sign In to comment.