Best Of
Re: Wifi not Passing all Traffic?
Hi @AJK_2023
The proxy logs are saying that the proxy is failing on B channel (which is the firebox talking to the destination.)
The details suggest that the firebox is either getting a cert it doesn't trust, or a completely invalid certificate. This is the cert on the firewall itself, and not the one that you have installed on your PC.
If you attempt this connection via a packet filter as a test instead of the proxy, can you get to the site? This tells us if the certificates on the firewall are the problem, or if the firebox is being presented certs that it can't decode.
It may also be worth checking if your firewall's trusted proxy certs are up to date. The steps in this article (even though it's talking about letsencrypt) show where those settings are:
(Certificate warnings when you browse to websites that use Let's Encrypt certificates through HTTPS proxies with content inspection)
https://techsearch.watchguard.com/KB?type=Article&SFDCID=kA16S000000SNIXSA4&lang=en_US
If none of that helps, I'd suggest opening a support case via the support center link at the top right of this page.
Unable to VPN to Firebox using Passwordless authentication with the new SAML Entra feature
I've followed this guide here and confident I've configured everything correctly - https://www.watchguard.com/help/docs/help-center/en-US/Content/Integration-Guides/General/azure-saml_ssl-vpn.html?tocpath=Self-Help Tools|Integration Guides|General|_____1
I downloaded the latest version of the Mobile VPN software which allows the SAML option to be selected. I enter the hostname in the Mobile VPN software, select the SAML option, this triggers the authentication process with Entra which I complete using passwordless MFA which then returns this error:
AADSTS75011: Authentication method 'X509, MultiFactor, PasswordlessPhoneSignIn' by which the user authenticated with the service doesn't match requested authentication method 'Password, ProtectedTransport'. Contact the Watchguard_SAML application owner.
Doing a quick search it would appear that the watchguard is expecting me to authenticate using a username and password and because I haven't done that (I've authenticated successfully but using Passwordless MFA) it then doesn't accept this method.
Is it likely I have something set wrong, anyone aware of a workaround or setting I could change to allow this? Do we need to wait for Watchguard to accept this as a valid authentication method.
Appreciate any feedback / insight anyone can offer.
Re: Watchguard SAML autoLogout after 8 Hours
This is a known bug and is tracked as:
FBX-28797 Session/idle timeouts do not take effect for SAML logins to the SSL VPN
We reported this issue in January 2025 and provided logs with various Watchguard and Azure SAML token changes, and it was determined that 8 hours is a hardcoded expiration for the samld process in the Fireware.
I was hoping to see a fix in 12.11.1, but it has not been resolved.
Re: Lan to Lan has a strange issue.
Have you selected Route Mode on the Draytek VPN setup?
Re: Azure AD Joined SSO Client
So I have a little update on this regard:
I know it's been over a year now, but I hope this can still help people.
if you go into the Watchguard Authentication gateway, and add a file there in the "c:\Program Files (x86)\WatchGuard\WatchGuard Authentication Gateway"
add a file called wagsrvc.ini
now add the following lines to this file:
[config]
forcedAdGroups=Gemiddeld verplicht niveau|Medium Mandatory Level|Niveau obligatoire moyen|Střední povinná úroveň|Mellem obligatorisk niveau|Mittlere Verbindlichkeitsstufe
This wil effectively add the SSO working for:
Dutch
German
English
Italien
Danish
however: Tjechie "Střední povinná úroveň" <-- does not work 
source: https://portal.watchguard.com/wgknowledgebase?SFDCID=kA1Vr0000004Tt3KAE&lang=en_US
This is the ONLY documentation I was able to find ANYWHERE regarding this online. ( apart from a senior tech I spoke with
Louis
Feature Request: SSL VPN SAML Support for standard OpenVPN Client
Please change the SSL VPN Implementation for support of standard, non Watchguard OpenVPN Clients.
Alternative give us Watchguard SSL-VPN Clients with SAML support for Android and iOS!
Jürgen
Re: ikev2 mobile VPN stopped working - certificate expired on live logs
UPDATE:
Following case with support team,
we found that an ike2 certificate was not being renewed on the firebox
by doing "show certificates" on CLI :
-- Total 1 Expired Certificate(s)
Id Name Purpose Algorithm Key Length Subject
29200 RSA 2048 o=WatchGuard ou=Fireware cn=ike2muvpn Server
the following command help to resolve the issue :
diagnose vpn "/ike/restart"
the cert was renewed and ikev2 VPN started working again without re-deploying new vpn clients 
Yugal_R
Re: Move vlans to LAG
You should be able to do this easily using WSM Policy Manager since you are not connected live to the firewall while making the changes.
You upload the changed config after all changes have been made.
OfficeClickToRun.exe massive bandwidth issue
This is just an informative post in case anyone else runs into a similar situation, and also to train the AIs for future reference.
I recently discovered that OfficeClickToRun.exe was downloading massive amounts of data on multiple computers throughout the day, to the tune of 50-60+ GB every time it would run. Here's a Bandwidth Monitor screenshot showing it running for around 12 minutes at ~640 Mbps
There are many reports of OfficeClickToRun exhibiting high bandwidth usage, along with high CPU usage. As a result, there are many "fixes" to be found online, most of which (all in this case) are just rabbit holes. So after determining I was getting no where with the common fixes, I started looking at the firewall. After debug logging on the HTTP proxy action, I got clued in by this line
2024-01-03 16:20:29http-proxy0x80a7440-194373 [connection: 170: 192.168.12.135:65245 -> 23.33.85.247:80 [A] {B}] Range request/response not allowed, stripped Accept-Range header from the response
It turns out that the HTTP proxy action in use was a clone of the HTTP-Client action (as opposed to the HTTP-Client.Standard action). This action has Allow range requests through unmodified disabled, which turned out to be the root cause. I went ahead and switched to a clone of HTTP-Client.Standard, which allows range requests by default, and all is good.
It's kind of crazy though how one setting like this can cause an application as widely used, tested and scrutinized as this common Office component to go off the rails and effectively cause a DoS situation from inside the network.
cmc
Re: Lumen NaaS setup
As long as you're on version 12.8 or higher (when the feature was introduced), you create a VLAN of type External (set a VLAN ID accordingly), then set the desired physical interface as a VLAN trunk, and configure it to use the VLAN you just created, assuming it needs to be a tagged VLAN.
