Fireware OS 12.5.4 kills remote active directory authentication

Upgraded our T50 to 12.5.4 last night. Mobile SSL-VPN users were immediately unable to authenticate and connect to our Active Directory. Was also unable to login at the authentication page for the firewall. We run a Windows Server 2016 network.

Had to return physically to the office and downgrade back to 12.5.3 Update 1. Everything was back to normal when the downgrade finished. Before downgrading, I was able to confirm that the T50 itself could authenticate to the AD internally with 12.5.4 installed. Appears that only external users were locked out.

Comments

  • Can you explain what you mean by "Was also unable to login at the authentication page for the firewall"? Was that internally, once connected to the SSLVPN, or from remote locations?

    I have a T35 on 12.5.4 and would like to test your scenario.

    Gregg Hill

  • I was referring to the Mobile VPN with SSL Client Download page hosted by the Firebox for clients to grab the software if they don't already have it remotely.

    Was unable to get any remote connection to work. Had to be physically behind the firewall at the office to open the firewire web ui. What was interesting, the web ui authentication test to the active directory server worked. It authenticated just fine. I was still unable to authenticate and connect a vpn client even behind the firewall though. Didn't think to try that download page again internally before I downgraded.

  • There was an upgrade while back that caused the "WatchGuard Authentication" policy to remove "Any-External" from the From field. Compare your 12.5.3 config to your 12.5.4 config using Policy Manager and see if that was the issue for the WatchGuard Authentication page on port 4100 not being reachable externally.

    I just tested my SSLVPN Client Download login page and it still works externally and internally. I also just downloaded and ran the SSLVPN client and connected while using a computer behind the firewall. I'm sorry that I cannot offer anything else for you.

    Gregg Hill

  • edited July 2020

    Same here. Found the error "2020-07-04 13:53:28 admd Authentication failed: user XXX@XXX@RADIUS isn't in the authorized SSLVPN group/user list!" in the logs. Nothing has been changed between the update so it is something that was wrongly configured before or after (or a bug in the update). On a T70.

  • edited July 2020

    I found a workaround of some sort, I’ve changed the “User's AuthPoint group” to “User's Active Directory groups” in the Authpoint resource.
    And on the firebox changing the group name in Mobile VPN setting to the one of the AD groups, it works. This is probably a long way to solve that problem, but it worked. But the question is why it stopped working with the “User's AuthPoint group” as attribute 11 in 12.5.4.

  • Mine probably has worked all along because I have been using the built-in "SSLVPN Users" group on my Fireboxes and I match that name for my AD group. I use the “User's Active Directory groups” in the AuthPoint resource to connect.

    Gregg Hill

  • james.carsonjames.carson Moderator, WatchGuard Representative
    edited July 2020

    @MartinS @Greggmh123 @JTrout

    The firewall gets group information for RADIUS via FilterID (Radius attribute 11) -- it's likely that we weren't getting that if the error message you posted "user XXX@XXX@RADIUS isn't in the authorized SSLVPN group/user list!" was what occurred. The firewall may have also been parsing it incorrectly.

    Authenticating against both AuthPoint and NPS (server2012R2) via Radius work on my test firewall in lab, so if something is going on, there's likely a bit more to it and could potentially be a bug.

    I'd suggest opening a case with support if you haven't already, so that they can look into this more deeply.

    -James Carson
    WatchGuard Customer Support

  • I had the same issue with upgrading to v12.5.4. I rolled back to v12.5.3 and the AD auth for SSL VPN worked properly again. I will wait for Watchguard to fix things before my next upgrade attempt.

  • edited July 2020

    Same issue after an update 3 days ago. WG Support noted the workaround is to remove the SSLVPN AD group from the FW config, then re-add. This worked for me, though there have been strange other bugs such as password lock outs, erroneous VPN timeout log messages, etc.

    Rolled back to previous version OS and the issues were solved.

  • Known Issue:

    After upgrade to Fireware v12.5.4, LDAP/AD user groups used by Mobile VPN no longer appear

    Description
    After you upgrade a Firebox to Fireware v12.5.4, the LDAP/AD (and possibly Radius) groups that are used for SSL and/or IKEv2 Mobile VPN no longer appear in the User and Groups dialog box. This issue seems to occur when third-party servers are in use.

    To verify whether you have this issue:

    In the SSL/IKEv2 Mobile VPN settings, review the groups on the Authentication tab. 
    Select Setup > Authentication > User and Groups and check if the groups appear in the Users and Groups dialog box.
    

    If a group that appears in the Mobile VPN settings does not appear in the User and Groups dialog box, this bug is present.
    Workaround

    In Policy Manager, in the SSL/IKEv2 Mobile VPN settings, Authentication tab, clear the check box for the missing group.
    Select Setup > Authentication > User and Groups and add the missing group.
    In the SSL/IKEv2 Mobile VPN settings, Authentication tab, enable the group again.
    Save the changes to the Firebox.
    

    Note: To avoid this issue, you can perform these steps before you upgrade to Fireware 12.5.4.

    https://watchguardsupport.secure.force.com/publicKB?type=Known Issues&SFDCID=kA10H000000boygSAA&lang=en_US

  • No revision in the 12.5.4 Release Notes yet to perform these steps prior to doing the upgrade.

  • I have no problem with my 12.5.4 upgrade on my T35, but I also only use the default IKEv2-Users and SSLVPN-Users groups on the T35 in the SSL/IKEv2 Mobile VPN settings on the Authentication tab. I have matching names in my AD. Maybe those of you with non-standard names are the ones affected? Is anyone using the standard names and still affected?

    Gregg Hill

  • Same issue, think it's a Fireware upgrade bug.

    Upgraded WSM from 12.5.3 to 12.6.1U1 and Fireware from 12.5.3 to 12.5.4. Following upgrade, but not immediately, SSL VPN users logging in using AD accounts could not authenticate. Still could log in using firebox-db account. Found AD security group was missing under Setup>Authentication>Users and Groups. Re-added group, saved configuration, was able to connect remote client successfully using AD auth.

    Should note that this happened with two different clients, same hardware, same upgrade path. Submitted case #01401763

  • There is now a note in the updated V12.5.4 Release Notes, Revision on July 15.

    In the "Upgrade to Fireware v12.5.4" section, this was added:

    To avoid a known issue that causes LDAP/AD user groups used by Mobile VPN to no longer appear,complete the workaround steps in this Knowledge Base article before you upgrade to Fireware v12.5.4.

    https://watchguardsupport.secure.force.com/publicKB?type=Known Issues&SFDCID=kA10H000000boygSAA&lang=en_US

  • wcodya,

    Are you using the default "SSLVPN Users" name for your AD security group name?

    Gregg Hill

  • Hi, same, we had to remove the AD group from SSL VPN config, save config, then add it back and save again.

  • Was finally able to circle back around to this on our production T50. Had to wait until I was physically present in the office. I didn't dare try running the update remotely again.

    Went straight from 12.5.3 to 12.5.5 with no issues. My AD group stayed connected, and the VPN still works great. They must have fixed the issue from before. I'm sure using the workaround for 12.5.4 would have worked too.

Sign In to comment.