Authentication proxy problems with Watchguard IKEv2 VPN

Hi all,

I’ve been using the authentication proxy with a Watchguard firewall device for SSL VPN connectivity for a while now with no issues at all. We’re using AD authentication.

I’m now trying to get the IKEv2 VPN working but I’m getting failures in the proxy. It’s configured in exactly the same way as the SSL VPN (indeed the RADIUS settings are shared between the two so you can’t configure them differently) but am getting strange errors.

Here’s a successful log excerpt from an SSL VPN authentication:

2019-06-19 09:27:10+0100 [DuoForwardServer (UDP)] Sending request from 192.168.100.6 to radius_server_auto
2019-06-19 09:27:10+0100 [DuoForwardServer (UDP)] Received new request id 79 from (‘192.168.100.6’, 43952)
2019-06-19 09:27:10+0100 [DuoForwardServer (UDP)] ((‘192.168.100.6’, 43952), 79): login attempt for username u’rutter’
2019-06-19 09:27:10+0100 [DuoForwardServer (UDP)] Sending AD authentication request for ‘rutter’ to ‘192.168.100.3’
2019-06-19 09:27:10+0100 [DuoForwardServer (UDP)] Starting factory <duoauthproxy.modules.ad_client._ADAuthClientFactory object at 0x0223A630>
2019-06-19 09:27:10+0100 [_ADAuthClientProtocol,client] http POST to https://■■■■■■■■■■■■■■■■■■■■■■■■■■■■:443/rest/v1/preauth
2019-06-19 09:27:10+0100 [_ADAuthClientProtocol,client] Starting factory <_■■■■■■■■■■■■■■■■■■■■: https://■■■■■■■■■■■■■■■■■■■■■■■■■■■■:443/rest/v1/preauth>
2019-06-19 09:27:10+0100 [_ADAuthClientProtocol,client] Stopping factory <duoauthproxy.modules.ad_client._ADAuthClientFactory object at 0x0223A630>
2019-06-19 09:27:10+0100 [HTTPPageGetter (TLSMemoryBIOProtocol),client] ((‘192.168.100.6’, 43952), 79): Got preauth result for: u’auth’
2019-06-19 09:27:10+0100 [HTTPPageGetter (TLSMemoryBIOProtocol),client] http POST to https://■■■■■■■■■■■■■■■■■■■■■■■■■■■■:443/rest/v1/auth
2019-06-19 09:27:10+0100 [HTTPPageGetter (TLSMemoryBIOProtocol),client] Starting factory <_■■■■■■■■■■■■■■■■■■■■: https://■■■■■■■■■■■■■■■■■■■■■■■■■■■■:443/rest/v1/auth>
2019-06-19 09:27:10+0100 [HTTPPageGetter (TLSMemoryBIOProtocol),client] Stopping factory <_■■■■■■■■■■■■■■■■■■■■: https://■■■■■■■■■■■■■■■■■■■■■■■■■■■■:443/rest/v1/preauth>
2019-06-19 09:27:17+0100 [HTTPPageGetter (TLSMemoryBIOProtocol),client] ((‘192.168.100.6’, 43952), 79): Duo authentication returned ‘allow’: ‘Success. Logging you in…’
2019-06-19 09:27:17+0100 [HTTPPageGetter (TLSMemoryBIOProtocol),client] ((‘192.168.100.6’, 43952), 79): Returning response code 2: AccessAccept
2019-06-19 09:27:17+0100 [HTTPPageGetter (TLSMemoryBIOProtocol),client] ((‘192.168.100.6’, 43952), 79): Sending response
2019-06-19 09:27:17+0100 [HTTPPageGetter (TLSMemoryBIOProtocol),client] Stopping factory <_■■■■■■■■■■■■■■■■■■■■: https://■■■■■■■■■■■■■■■■■■■■■■■■■■■■:443/rest/v1/auth>

By contrast, here’s what I get when I try via the IKEv2 VPN:

2019-12-06 08:34:25+0000 [DuoForwardServer (UDP)] Sending request from 192.168.100.6 to radius_server_auto
2019-12-06 08:34:25+0000 [DuoForwardServer (UDP)] Received new request id 16 from (‘192.168.100.6’, 58691)
2019-12-06 08:34:25+0000 [DuoForwardServer (UDP)] ((‘192.168.100.6’, 58691), 16): login attempt for username u’groves’
2019-12-06 08:34:25+0000 [DuoForwardServer (UDP)] Sending AD authentication request for ‘groves’ to ‘192.168.100.3’
2019-12-06 08:34:25+0000 [DuoForwardServer (UDP)] Starting factory <duoauthproxy.modules.ad_client._ADAuthClientFactory object at 0x0224DEB0>
2019-12-06 08:34:25+0000 [_ADAuthClientProtocol,client] Unexpected Error sending AD auth request to ‘192.168.100.3’. Trying next fallback host…
Traceback (most recent call last):
File “twisted\internet\defer.pyc”, line 577, in _runCallbacks

File "twisted\internet\defer.pyc", line 1157, in gotResult
  
File "twisted\internet\defer.pyc", line 1099, in _inlineCallbacks
  
File "twisted\python\failure.pyc", line 389, in throwExceptionIntoGenerator

— —
File “duoauthproxy\modules\ad_client.pyc”, line 409, in _authenticate_with_host

File "twisted\internet\defer.pyc", line 1099, in _inlineCallbacks
  
File "twisted\python\failure.pyc", line 389, in throwExceptionIntoGenerator
  
File "duoauthproxy\modules\ad_client.pyc", line 111, in authenticate
  
File "twisted\internet\defer.pyc", line 1101, in _inlineCallbacks
  
File "duoauthproxy\lib\ldap\client.pyc", line 161, in perform_bind_ntlm
  
File "duoauthproxy\lib\ntlm.pyc", line 354, in create_authenticate_msg
  
File "duoauthproxy\lib\ntlm.pyc", line 459, in NTOWFv2

exceptions.AttributeError: ‘NoneType’ object has no attribute ‘encode’

2019-12-06 08:34:25+0000 [_ADAuthClientProtocol,client] No remaining AD fallback hosts; returning authentication failure…
2019-12-06 08:34:25+0000 [_ADAuthClientProtocol,client] ((‘192.168.100.6’, 58691), 16): Primary credentials rejected - ‘Failed to communicate with any Active Directory server’
2019-12-06 08:34:25+0000 [_ADAuthClientProtocol,client] Allow concat is configured, but is not supported with MS-CHAPv2 authentications. Did you try to concatenate your second factor to your password?
2019-12-06 08:34:25+0000 [_ADAuthClientProtocol,client] ((‘192.168.100.6’, 58691), 16): Returning response code 3: AccessReject
2019-12-06 08:34:25+0000 [_ADAuthClientProtocol,client] ((‘192.168.100.6’, 58691), 16): Sending response

Does anyone have any ideas why the latter is failing?
Thanks for any help.
Toby.

From the WatchGuard Help Center:

Mobile VPN with IKEv2 supports two-factor authentication for MFA solutions that support MS-CHAPv2. AuthPoint, the WatchGuard MFA service, supports MS-CHAPv2 RADIUS authentication for manually created users as of the October 4, 2018 AuthPoint release.

Your previous config was using PAP from the VPN, with the Duo proxy doing LDAP primary authentication ([ad_client]). Your new config, per the WatchGuard doc, might be trying to use MSCHAPv2.

MS-CHAPv2 with the Duo Proxy requires RADIUS primary authentication ([radius_client] instead of [ad_client] in the authproxy.cfg). This is mentioned here and here. So, you’d need to point your Duo proxy to a RADIUS server for primary auth instead of an AD/LDAP server.

The RADIUS+RADIUS Duo config is described in this WatchGuard document.

If you need help setting this up, please contact Duo Support.

Awesome thank you! I’d only recently discovered the PAP/MSCHAPv2 difference which explains the different data payload being sent to the Duo proxy.

Will look into the links you’ve provided next week.

I’ve now received a response from Duo Support but they’re saying that the proxy isn’t compatible with the EAP-MSCHAPv2 used by WatchGuard for the IKEv2 VPN and thus it won’t work at all.

This is disappointing to say the least and I’m not going to have to look at alternative MFA solutions.

Is there no workaround for this?

If you can’t change the Watchguard to use plain MSCHAPv2 or to use EAP-GTC (which we do support via radius_server_eap then no. There is an open feature request for full EAP-MSCHAPv2 support in the Duo Proxy. The Duo Support engineer you worked with can add you to that feature request.

Hi Kristina,

I did request to be added to the feature request but have not yet had a response.

Honestly, how likely is this feature request to be implemented? How many people have asked for it?

Thanks,
Toby.

While we do try to roadmap our feature work ahead of time, we’re always reevaluating our priorities to deliver good experiences for customers.

If you have an account executive or customer success manager, I suggest that you connect directly with them to provide more context around your use case and the impact to your business. They could share information about the feature request with you as well. We are unable to share specifics in this public community.

1 Like