Problem with RADIUS authentication
Hi. We're currently using SSL-VPN, however my users are complaining about poor performance (a known issue with SSL-VPN). In looking at other options, both L2TP and IKEv2 seem much better (about 2x the throughput in my testing), so I want to switch to either L2TP or IKEv2.
For SSL-VPN, we're using AD authentication. Since neither of the other protocols supports AD/LDAP, I'm forced to use RADIUS. However, the device (XTM 26 running 12.1) claims that it can't talk to the RADIUS server:
2020-02-12 15:44:43 admd Authentication server 10.0.0.7:1645 is not responding id="1100-0003"
I've run a Wireshark trace on the RADIUS server (NPS on Windows Server 2019), and it is receiving the Access-Request and is returning Access-Accept (on the initial request and two subsequent retries per session). Response time from the RADIUS server is < 100ms, so well below the default 5s timeout value.
So, RADIUS is working fine. It kind of smells like the client on the device isn't receiving the response. Both the device and the server are on the same subnet (10.0.0.0/16). Clearly, the request is getting to the server OK.
I've also used other tools to confirm that the RADIUS server is working OK.
Any thoughts as to where I should look? It seems like one of those issues where some kind of internal routing or firewalling is preventing the response packet from being seen by the device.
Thanks!
P.S. I checked the logs, and aside from the message above, there are no other messages referencing the RADIUS server. That is, no "Unhandled external packet" or similar messages involving the conversation. However, the timing of the log messages is interesting.
2020-02-12 16:31:13 iked (xxx.xxx.xxx.xxx<->yyy.yyy.yyy.yyy)'L2TP-IPSec' L2TP IPSec tunnel is established. local:xxx.xxx.xxx.xxx/32 remote:yyy.yyy.yyy.yyy/32 in-SA:0xf800ce61 out-SA:0x0f51c62a role:responder id="0207-0001"2020-02-12 16:31:13 admd RADIUS:check RADIUS authenticator failed
...a couple of unrelated external Deny events...2020-02-12 16:31:19 admd RADIUS:check RADIUS authenticator failed
...a couple of unrelated external Deny events...2020-02-12 16:31:24 admd RADIUS:check RADIUS authenticator failed
...a couple of unrelated external Deny events...2020-02-12 16:31:29 admd Authentication server 10.0.0.7:1645 is not responding id="1100-0003"2020-02-12 16:31:29 admd Authentication of L2TPVPN user [zzzzzzzz@RADIUS] from yyy.yyy.yyy.yyy rejected, Recv timeout id="1100-0005"
The interesting part is the initial failure immediately after the tunnel is established. From this, it almost seems like the device actually saw the Access-Accept response, and either ignored it, or didn't like it for some reason, so went into timeout mode.
It sure would be nice if they had an authentication test tool like they do for AD/LDAP...
Comments
You could try setting SSLVPN to use UDP intstead of TCP, and see if that improves speed.
You can use TCP dump to capture packets in Fireware.
In Firebox System manager, go to Tools -> Diagnostic Tasks.
-Choose TCP Dump from the drop down.
-Choose the "advanced options" checkbox.
tcpdump argument "-i eth0 host 10.0.0.7
A common RADIUS authentication problem is not setting the Group Attribute to 11.
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/authentication/radius_server_auth_about_c.html?Highlight=radius
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
Also see this note:
"If your configuration includes a RADIUS server, and you upgrade from Fireware v12.4.1 or lower to Fireware v12.5 or higher, the Firebox automatically uses RADIUS as the domain name. To authenticate, users must select RADIUS as the server and type RADIUS as the domain name. If a user types a domain name other than RADIUS, authentication fails. This applies to authentication through the Web UI, WatchGuard System Manager v12.5 or higher (to a Firebox with any Fireware version), Mobile VPN clients, and the Access Portal."
Thanks for the quick response. From the Wireshark trace:
Attribute Value PairsAVP: t=Filter-Id(11) l=12 val=L2TP-UsersAVP: t=Framed-Protocol(7) l=6 val=PPP(1)AVP: t=Service-Type(6) l=6 val=Framed(2)AVP: t=Class(25) l=46 val=3e54049e00000137000102000a0000070000000000000000…AVP: t=Vendor-Specific(26) l=42 vnd=Microsoft(311)AVP: t=Vendor-Specific(26) l=42 vnd=Microsoft(311)AVP: t=Vendor-Specific(26) l=51 vnd=Microsoft(311)AVP: t=Vendor-Specific(26) l=13 vnd=Microsoft(311)AVP: t=Vendor-Specific(26) l=12 vnd=Microsoft(311)AVP: t=Vendor-Specific(26) l=12 vnd=Microsoft(311)...so, the Filter-Id looks OK. I'll try a diagnostic log - I think I did that a while ago, but will do so again.
Regarding the other attributes, I did wonder whether any of them might cause problems, as the docs didn't say anything about other ones, and those are defaulted.
Sigh.
Problem solved. I ran a diagnostic trace, and while looking at the output, found this:
https://reddit.com/r/networking/comments/ezehn3/watchguard_m400_mobile_ikev2_with_radius_fun_and/
I think I had read about the limitation on the RADIUS client shared secret, and mine shouldn't have been too long, but I made it much shorter, and now can connect.
Thanks, WatchGuard, for the bugs, and lousy error messages.
Thanks, Bruce, for leading me down the path to look into this further...
That's almost comical where the Reddit poster says he needed to read the manual, then ends with "Moral of the story is don't use WatchGuard." How about ""Moral of the story is read the manual"? That is exactly how I figured out the problem when I had too long of a secret.
Gregg Hill
To that guy ... Um RTFM...
And for the version of your firmware