Mobile VPN Client with SSLVPN v 12.11.3 SAML broken following Edge Update on Windows Systems

Alan_MercerAlan_Mercer
in Firebox - VPN Mobile User

Yesterday Microsoft released Edge version 139.0.3405.86 which after Windows systems update to this version, the SSLVPN client using SAML authentication to Microsoft Entra is failing, locking out remote users. Reportedly downgrading Edge resolves the issue but with automatic and managed updates, this is a temporary and short term fix. Uninstalling the client and installing 12.11.2 client appears to work, but only because we have not yet upgraded the firebox to 12.11.3 from 12.11.1 Update 1 as we still have nearly 100 systems to update so that we can update the firewall. Reverting to legacy Active Directory authentication is also failing now, leaving client downgrades, a slow and tedious process with remote users, as our only option.

Comments

  • kimmo.pohjoisahokimmo.pohjoisaho
    https://techsearch.watchguard.com/KB?type=Known Issues&SFDCID=kA1Vr000000CffJKAS&lang=en_US
  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @Alan_Mercer

    Please see the KB here for a workaround:
    Mobile VPN with SSL Client v12.11.3 SAML connections fail after WebView2 v139 update

    The SSLVPN client just has an update regarding a security vulnerability. You can use the 11.12.3 client on 11.12.2 with no issue if you're looking to upgrade the firewall later.

    Enhancements and Resolved Issues in Fireware v12.11.3
    This release resolves a local privilege escalation vulnerability in the Mobile VPN with SSL Client (CVE-2025-1910). View the full advisory details on psirt.watchguard.com. [WGSA-2025-00008]

    -James Carson
    WatchGuard Customer Support

  • B_ChristB_Christ

    The Workaround was working fine until Microsoft decided to remove all WebView Versions older than v139. Can you tell when a new Mobile VPN Client Version will be released? In our Case we just created local Users to make SSL VPN working for our Staff. Thank you and best Regards

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @B_Christ
    Reverting to local users will bypass the issue with WebView. The KB article has also been updated to include a workaround using LDAPS for Entra users.

    https://techsearch.watchguard.com/KB?type=Known Issues&SFDCID=kA1Vr000000CffJKAS&lang=en_US

    If you'd like to be notified when this is resolved, please create a support case and mention FBX-30242. You can be notified via the support case.

    -James Carson
    WatchGuard Customer Support

  • Maik_GMaik_G

    If you’re having issues with the WatchGuard SSL VPN client due to WebView2 runtime compatibility with SAML, you can force the client to use a specific WebView2 version. This is useful when downgrading the client or using a local user account is not an option.

    Steps:

    1. Download the Fixed Version (x86) from Microsoft Edge WebView2
      => https://developer.microsoft.com/en-us/microsoft-edge/webview2/?form=MA13LH#download
    2. Extract the archive and move the folder (e.g., 138.0.3351.121) to: C:\WebView2_Fixed\
    3. Create a batch file with the following content:
    @echo off
setlocal
rem Use Fixed WebView2 138 (x86) only for this process
set "WEBVIEW2_BROWSER_EXECUTABLE_FOLDER=C:\WebView2_Fixed\138.0.3351.121"
start "" /D "C:\Program Files (x86)\WatchGuard\WatchGuard Mobile VPN with SSL" "wgsslvpnc.exe"
endlocal

    What this does:

    • Sets the environment variable WEBVIEW2_BROWSER_EXECUTABLE_FOLDER so the WatchGuard VPN client uses the specified WebView2 runtime.
    • Launches wgsslvpnc.exe from its installation directory.
    • The setting applies only to this process and ends after the script finishes.

    Hope this helps someone facing the same issue.
    Cheers

  • NazMNazM

    We have had this same issue - but we also had updated our Firebox to 12.11.3
    we have rolled back the VPN Client to 12.11.2 and it still connects to the FB ok.

    hopefully a fix from watchguard comes soon!

  • phanaaekITphanaaekIT

    We're faced with the same issue and the temp fix posted by @Maik_G worked perfectly.

  • kimmo.pohjoisahokimmo.pohjoisaho

    WG has new workaround for this problem
    https://portal.watchguard.com/wgknowledgebase?type=Known Issues&SFDCID=kA1Vr000000CffJKAS&lang=en_US

  • AndyWortleyAndyWortley

    is there any news on a more permanent fix or work-around as this is causing a lot of problems in our network

  • james.carsonjames.carson Moderator, WatchGuard Representative

    @AndyWortley A permanent fix is being worked on. Any new information will be updated via the KB.

    -James Carson
    WatchGuard Customer Support

  • phanaaekITphanaaekIT
    edited September 19

    The release notes for 12.11.4 indicate that this issue has been resolved, but it has actually worsened for us. SAML login continues to fail, and the workaround is ineffective with SSL VPN client 12.11.4. However, the workaround still functions with 12.11.3.

    Release Note: Mobile VPN with SSL Client SAML connections no longer fail after the WebView2 v139 update. [FBX-30242]

    Does 12.11.4 work for anyone else?

  • YvesDLYvesDL

    @phanaaekIT said:
    The release notes for 12.11.4 indicate that this issue has been resolved, but it has actually worsened for us. SAML login continues to fail, and the workaround is ineffective with SSL VPN client 12.11.4. However, the workaround still functions with 12.11.3.

    Release Note: Mobile VPN with SSL Client SAML connections no longer fail after the WebView2 v139 update. [FBX-30242]

    Does 12.11.4 work for anyone else?

    Hello, having the same problem as you, not able to connect via SAML it is stuck on requesting client configuration.

  • Dave_DanielsDave_Daniels WatchGuard Representative

    Hi all,

    We have discovered one issue reported by customers where the SAML connection fails and that is due to the SSLVPN client still pointing to the latest WebView2runtime version.

    In the 12.11.4 SSLVPN client, we have added a folder that is installed in the user's App Data\Local folder (the user that installed the client). This folder has an older WebView2 runtime version that the client mini browser is able to run on.

    The issue we have found is that when its installed, the admin user that has installed it is not the same user that is actually using the SSLVPN client. So when the non-admin user who actually uses the client looks for that folder and cant find it since its not the same admin user that installed the 12.11.4 client and instead defaults to using the latest WebView2 version.

    Here is a KB that explains the issue and the workaround.
    https://techsearch.watchguard.com/KB?type=Known Issues&SFDCID=kA1Vr000000DQKrKAO&lang=en_US

    If you find that the C:\Users\\AppData\Local\WatchGuard is present, then it is a different issue then. Which you will need to create a case on the issue so tech support can gather data and work on the issue with you.

  • YvesDLYvesDL

    @Dave_Daniels

    Any information regarding a post on Reddit? Having a similar issue ..

    Has anyone got the 12.11.4 working with an account that has Windows Hello (with Cloud Kerberos Trust) enabled?

    In the pervious versions there was the option during sign-in to do it with password+MFA instead.

    Now that it uses the Primary refresh token automatically my colleague can't get to that. It simply shows an error message, that Windows Hello is not supported.

    I don't have the displayed error at hand, but in Entra Sign in Logs it says:

    Error 75011 - Authentication method '{usedMethod}' by which the user authenticated with the service doesn't match requested authentication method '{requestedMethod}'. Contact the {appName} application owner

  • Dave_DanielsDave_Daniels WatchGuard Representative
    edited September 24

    Hi @YvesDL ,

    I dont monitor Reddit. But we have had discussions on having a representative answer questions on that site.

    I reviewed that error and currently we are working on feature request to stop the samld process from setting the parameter RequestedAuthnContext to PasswordProtectedTransport with exact comparison in the SAML requests. If Entra ID users use a SAML passwordless authentication, Firebox SAML requests will be rejected, because the RequestedAuthnContext doesn't match the IdP's authentication methods e.g. the PasswordlessPhoneSignIn.

    This is tracked under:
    FBX-36510 - Remove "RequestedAuthnContext" from SAML Request

    Currently we do not support passwordless signin
    https://www.watchguard.com/help/docs/help-center/en-US/Content/Integration-Guides/General/azure-saml_ssl-vpn.html

    But this feature request would be to allow the user to choose the authentication methods presented by the Identity Provider (in this case Entra ID).

    It is slated for 12.11.5 SSLVPN client. There is no ETA on when this will be available.

    For now the user would need to disable Windows Client Hello for the specific SSLVPN group that is connecting on SSLVPN with SAML.
    To do this they would need to log into the Admin Center on Entra and go to their Authentication Methods > Policies and edit the Windows Hello method and add the SSLVPN group to the excluded list.
    This will stop it from being presented when the SSLVPN user authenticates via SAML.

    The above feature request FBX-26510 will address this issue on the 12.11.5 client. But for now the workaround I mentioned should suffice.

    If you are in contact with that Reddit user, you can have them create a case and I can explain this to them myself.

  • phanaaekITphanaaekIT
    edited September 25

    @Dave_Daniels said:
    Hi all,

    We have discovered one issue reported by customers where the SAML connection fails and that is due to the SSLVPN client still pointing to the latest WebView2runtime version.

    In the 12.11.4 SSLVPN client, we have added a folder that is installed in the user's App Data\Local folder (the user that installed the client). This folder has an older WebView2 runtime version that the client mini browser is able to run on.

    The issue we have found is that when its installed, the admin user that has installed it is not the same user that is actually using the SSLVPN client. So when the non-admin user who actually uses the client looks for that folder and cant find it since its not the same admin user that installed the 12.11.4 client and instead defaults to using the latest WebView2 version.

    Here is a KB that explains the issue and the workaround.
    https://techsearch.watchguard.com/KB?type=Known Issues&SFDCID=kA1Vr000000DQKrKAO&lang=en_US

    If you find that the C:\Users\\AppData\Local\WatchGuard is present, then it is a different issue then. Which you will need to create a case on the issue so tech support can gather data and work on the issue with you.

    That seems to be our issue as we typically deploy the app. Will this be reworked or fixed in the next version?

  • Dave_DanielsDave_Daniels WatchGuard Representative

    @phanaaekIT yes, it will be fixed on a later version. I am assuming the next version we release. There is discussion on putting the required folder in some location that is not user specific. A machine-wide directory like %Program Data%.
    No ETA on when this will be done though. Its in testing phase now.

Sign In to comment.