IKEv2 Problems
Hello,
I'm attempting to setup an Mobile User VPN using IKEv2. I've configured RADIUS authentication on the Firebox, and added the NPS policies as outlined in WG KB. I've configured the Windows 10 client following WG instructions, but when I attempt to connect to the VPN I see the following error in traffic monitor -
2020-11-10 22:04:05 iked (xx.xx.xx.xx<->xx.xx.xx.xx)IKEv2 IKE_AUTH EAP exchange from xx.xx.xx.xx:4500 to xx.xx.xx.xx:4500 failed. Gateway-Endpoint='WG IKEv2 MVPN'. Reason='domainname' authentication domain is not configured. id="021A-001E" Debug
I haven't found much in the way of help on this particular error. I've checked and rechecked my RADIUS/NPS settings and they match the WG documentation exactly. I also attempted to edit the client settings on the Windows 10 computer and manually specified the domain suffix and DNS servers, but that has had no effect. Any help is appreciated.
Comments
Did some additional testing and this appears to be RADIUS related. I am able to connect using a Firebox account, but not an AD account.
Have you reviewed this?
Configure Windows Server 2016 or 2012 R2 to authenticate mobile VPN users with RADIUS and Active Directory
https://techsearch.watchguard.com/KB/WGKnowledgeBase?lang=en_US&SFDCID=kA22A000000XZlhSAG&type=KBArticle
I have followed that to the T at least three times now with no results. One point worth making is that the documentation is conflicted on EAP-MSCHAPv2 and MSCHAPv2. The article above refers to the latter, while other documentation shows the first for IKEv2.
Consider opening a support incident.
You can turn on diagnostic logging for authentication which may show something to help:
. Policy Manager: Setup -> Logging -> Diagnostic Log Level -> Authentication
or
. Web UI: System -> Diagnostic Log
Set the slider to Information or higher
I opened up a ticket. I'll post back the findings for future reference.
On my Server 2019 domain and running a T20-W with 12.6.2 U3 (or my T35-W with 12.5.5 U1)), I have mine set up using only MSCHAPv2. I matched my AD user group name to the WatchGuard "IKEv2-Users" group name and I use that name in the Filter-ID in NPS.
Gregg Hill
Same here. Same in every possible way. Doesn't work for me. It seems like it's not passing domain information. I had the same Firebox and RADIUS server working for IPSec MUVPN, but not for IKEv2. Let me ask you something - what format do you enter user/domain information in the client? I've tried domain\user, user@domain and just plain user. If I omit the domain or use user@domain then I can see entries in the WG logs showing the account as user@RADIUS or user@domain@RADIUS, respectively. If I pass just the user name then I see no authentication entries.
I use 2FA with mine, so it's likely different than what you have.
I use AuthPoint as my primary 2FA on my VPNs, with DuoSecurity as my secondary, so if I want to have AuthPoint confirm a login, I just type my domain username and password. If I want to have Duo do the 2FA, I have to enter "DuoSecurity\username" and my domain password. "DuoSecurity" is what I have in my Fireboxes as the Authentication Servers RADIUS name, along with "AuthPoint" name on the RADIUS tab.
MY NPS Server has:
Conditions tab:
Authentication type = MSCHAPv2
User Groups = InternalDomainName\IKEv2-Users
Constraints tab:
Only MSCHAPv2 checked.
Settings tab:
Filter-ID = IKEv2-Users
Framed-Protocol = PPP
Service-Type = Framed
Gregg Hill
I also just have a "RADIUS" name so that I can test without using 2FA, but because AuthPoint is primary, I have to enter "RADIUS\username" and then my password to connect when not using 2FA.
Gregg Hill
I haven't used the VPN since March, but I just tested it. When I log in with username and password only, it uses AuthPoint, which I approve, and then it shows Gregg@AuthPoint in FSM traffic monitor. Using DuoSecurity\username shows Gregg@DuoSecurity in traffic monitor. I have plain RADIUS disabled, but I believe it showed Gregg@RADIUS previously.
Gregg Hill
Seems like I created my own issue by following the directions exactly. I did not create a connection policy (we don't use the default CP on the NPS server) specifically for Watchguard since the instructions didn't include that as a step. That seemed odd to me, but I just followed the instructions.
I am confused by what you are saying you left out.
You stated that "I did not create a connection policy (we don't use the default CP on the NPS server) specifically for Watchguard since the instructions didn't include that as a step." However, isn't that what the whole "Configure a Network Policy" section tells one to do?
Gregg Hill
No, you can create a network policy without creating a connection policy. They aren't the same thing. While they are dependent they are also mutually exclusive. When I brought this up to support I was told that they assume the default connection policy is enabled which is why it's not in the instructions. We don't use the default CP, so...
OK, I see what you mean now. My Connection Request Policies section has the default policy enabled. I disabled it and then could not connect to the VPN. Re-enabling it allows connection to work again.
Gregg Hill
I've managed to get the connection going (IKEv2), but using the automatically generated 'IKEv2-Users' group in firewall policy seems to have no effect (even though 'L2TP-Users' in the same policy DOES work.
For example, I set up a policy that forces VPN users to go through a bandwidth-controlled HTTP/HTTPS proxy but I'm only seeing a regular traffic denied for the IKEv2-Users group.
Windows RADIUS set-up exactly the same as L2TP, just with updated group names.
Scratching my head why this might be happening...
Is your RADIUS server returning the group name IKEv2-Users in the FilterID ?
You can turn on diagnostic logging for authentication which may show something to help:
. Policy Manager: Setup -> Logging -> Diagnostic Log Level -> Authentication
or
. Web UI: System -> Diagnostic Log
Set the slider to Information or higher
Bruce,
Looking over logs, a reference to the L2TP-Users group popped up; checked group enrollment in AD and removed my account from all but the IKEv2-Users group; seems to work now.
However is only true on my work Windows 10 laptop; installing the same profile for OS X (Big Sur), the connection starts, holds for about 5 seconds, then promptly gets dumped...
Sorry, I'm not a MAC guy.
If no help in Traffic Monitor, consider opening a support incident
Do you have NTLM disabled in your environment and only allowing NTLMv2? If so, then your RAS/NPS server is by default still only attempting communications utilizing NTLM and thus not working. Add the following to the registry on the RAS/NPS server to enable NTLMv2 for RAS/NPS
Locate and then select the following registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy
New - DWORD Value.
Type Enable NTLMv2 Compatibility
On the Edit menu, select Modify.
In the Value data box, type 1, and then select OK.
Quit Registry Editor.
.
Awesome! This was my exact issue. Thanks for the assist!
Hey! I have exactly the same Problem. Which CP do I have to create?
Hi!
We have the same problem - but only with IKEv2. Users can login with username and username@domain.com - but not with DOMAIN\username
In this case we get
2022-02-06 11:55:29 FWStatus, (XXXXXX<->YYYY)IKE SA EAP state change: EAP_AUTH_REQ ::> EAP_FAIL, reason: "'DOMAINNAME' authentication domain is not configured.", pri=6, proc_id=iked, msg_id=
2022-02-06 11:55:29 FWStatus, (XXXX<->YYYYY)MSCHAPv2 state change: MSCHAPV2_CHALLENGE_I ::> MSCHAPV2_FAIL, reason: "'DOMAIN' authentication domain is not configured.", pri=6, proc_id=iked, msg_id=
although we have created an radius server entry in the watchguard config for the domain for the domain - so we have "RADIUS " and "DOMAIN".
Interestingly it works for IPsec dial in - but not for IKEv2.
Hi @kraeg - The firewall interprets anything in front of the \ as a command to use a different authentication server, and will try to match that against its list of configured auth servers.
The older IPSec/IKEv1 Mobile VPN had the auth server defined in the user's ipsec profile, so the \ was ignored.
-James Carson
WatchGuard Customer Support