Comments
-
Looks like 12.10.1 has a new feature: With v12.10.1 of the WatchGuard Single Sign-On (SSO) Agent, WatchGuard Active Directory SSO now supports computers joined to your domain with Azure Active Directory. This support is for hybrid environments, where a local Active Directory domain controller is used for authentication by…
-
Yes, we have more than 10 users with Entra ID joined device, not hybrid, and the SSO client works for all of them.
-
We use AD Connect to sync local AD accounts to Azure. We use the SSO Client on all devices. Other than that, we didn't do anything else. We're not using the Event log monitor either. I've only tested this on one PC so far but should be testing more soon.
-
We have the gateway installed on a server so that isn't an issue. This requirement was a bit worrying since Azure AD Joined computers are not members of the local AD Domain. "All computers from which users authenticate with SSO must be members of the Active Directory domain with unbroken trust relationships."…
-
I have a similar issue with a new T40 WatchGuard Cloud Status registration_status: 2 enabled: 1 connected: 0 token_required: 0 server: firebox.iot.usa.cloud.watchguard.com:443 api_endpoint: https://firebox.usa.agent.watchguard.com disconnect_reason: Connection lost
-
I have a new T-40 as well. I see the device when I click Add the device to the cloud and it works but the device never actually connects to the cloud even though the option is enabled locally. I've tried removing it and adding it plus toggling cloud on and off on the device but nothing helps. webui: WatchGuard Cloud Status…
-
I'm use SD-WAN to send guest traffic over a second isp and fails over to the primary if the second goes down. The opposite is set up for everything else using Multi-WAN so at the moment the guest network has better link monitoring. I had an issue a couple times now where many web sites were barely loading on the primary…
-
That's correct but that brings up a related question for me. Multi-WAN seems inferior to SD-WAN so in order to use SD-WAN, we'd have to select it on every single policy? It would be better if Multi-WAN also had the metric options for loss, latency, and jitter. Either that or let us select one of our SD-WAN options as the…
-
Threatseeker Cloud shows status degraded https://status.forcepoint.com/#/status/1
-
I see that in traffic monitor now too. 2021-07-30 12:19:37 M270-loc1 webblocker categorize_url: curl returned error: Connection timed out after 15001 milliseconds Debug 2021-07-30 12:19:37 M270-loc1 webblocker categorize_url: curl returned error: Failed to connect to rp.cloud.threatseeker.com port 443: Connection refused…
-
Where do you see that? I'm getting these notifications: error: Webblocker server is not available
-
That doesn't say you need the "standard support sku" and the standard support sku doesn't say it's for a firecluster. Again just didn't want to buy the wrong support sku. "support subscription" seems vague when almost all the skus include a support subscription and how am I supposed to know there isn't a sku specifically…
-
Saw that and the regular documentation but it doesn't specifically mention needing "Standard Support renewal" on the passive unit so I wanted make sure I was purchasing the correct renewal. Thanks
-
That's what I suspected, just couldn't find it worded anywhere. Thanks for the confirmation.
-
I ended up disabling WatchGuard cloud on the cluster, then removing it from the cloud. After that I was able to add the firecluster back into the cloud and it's working fine now.
-
The m270 has a TPM chip but according to the status report it does not? token_required The token_required status indicates whether the Firebox has a TPM chip. If the Firebox does not have a TPM chip, it requires a Verification Code to register. 0 — Firebox has a TPM chip 1 — Firebox does not have a TPM chip
-
WatchGuard Cloud Status registration_status: 0 enabled: 1 connected: 0 token_required: 1 disconnect_reason: Not registered
-
12.6.4 has a few fixes per the release notes. In an active/passive FireCluster, DNSWatch no longer fails when the active cluster member has an expired DNSWatch license and the passive cluster member has an unexpired DNSWatch license. [FBX-17093] This release resolves a FireCluster issue that caused the sslvpn_firecluster…
-
I think I didn't explain it completely. In the docs, it says Policy Manager Managed Device Settings - "This name is case-sensitive and must match the name you use when you add the device to the Management Server configuration. This can also be the IP address of the Firebox." So I've input the primary external static IP for…
-
That's what I was looking for. I as able to remove my old ISP IP and that removed it from the BOVPNs. Now I need to change the order but it says the name there must match the device name. Does it matter that the device name is only one of the IP addresses listed in the management properties box?
-
What does one have to do to fix this besides stop using managed VPNs? I've tried deleting my bovpn, waited for the gateway to be removed, and the recreated the vpn but still the same three multi-wan are in the same order. I can't disable the third external interface because it says it's in use by the bovpn gateway.
-
It doesn't seem to be in the interface order or multiwan order. multiwan order ISP1 ISP2 ISP3 (unchecked) Interface order Port 0 ISP3 Port 4 ISP1 Port 7 ISP2 bovpn gateway order ISP 2 ISP 3 ISP 1
-
I may have to look into manual BOVPNs. I'm not sure what finally did it but the new interface is now listed under the bovpn gateways but still all in the wrong order. It doesn't seem to pay any attention to the multiwan failover settings.
-
It also reverts back when the SSL VPN client is updated on the client computer which might happen next time you update the firebox if it includes a new client.
-
So I upgraded my fire cluster to 12.5.3 U1 build 6210990 and the problem came back. I had to go ahead and run the cli command again sslvpn resource default-route-client Now I wonder, did this setting go away because I upgraded or because the firecluster master is different now? Also, how do I check the status to make sure…
-
I made the change a month ago, so far all the issues are gone. Not sure why this isn't the default and why we can't change it in the gui. Maybe they saved that for a future release.
-
Same issue with ssl vpn and it's very annoying that the lease time can't be changed. If users are going to be working remotely more often, may need a new vpn solution. I hope watchguard has this in their roadmap.
-
Thanks, probably going with m270 including HA.
-
Has anyone tried option 1 changing the default route through CLI yet? Just wondering if it solved the problem and if it introduces any other issues. In all the years managing WG devices, I've never had to touch the CLI. Will the option be added to the gui eventually? Option 2 is kind of a waste of time because as soon as…
-
No big issue, just wondering what the lease time is so I could maybe increase it to keep dns working well but so far it's working Ok.