Adding this to Dimension and other WatchGuard management servers would also be very beneficial.

Apple and Google plan to reduce SSL Certificate lifespans to 45 days by 2027.

As a feature request, I believe Watchguard should consider enabling automatic SSL Renewal (like Let's Encrypt or something similar). The current recommendation is that SSL Certificates should be renew automatically by the web server, so I believe Watchguard should consider adding a method for Automatic Renewals of SSL Certificates for use in proxy servers. Especially before they shorten the renewal time.

A client wants us to block all AI/AI chatbots, etc except Copilot. Application Control can do this and includes ChatGPT, Claude, DeepSeek, MS Copilot, Perplexity, and POE (which is great!)

Freature request to please add Grok/xAI to this list and any others/smaller ones that might be out there.

Thanks much....

-m

Preconfigured VLANs already assigned to a physical interface (e.g., eth1).

Predefined intra-VLAN policies, so I don’t have to manually configure the From and To fields for each VLAN combination during every deployment.

Use Case:
For customer standardization, I would like to:

Create a template with predefined VLANs (e.g., LAN, Guest, IoT, Server, etc.) already mapped to an interface.

Have all the required intra-VLAN policies already in place within the template (e.g., LAN ↔ Server, LAN ↔ IoT, etc.).

At deployment time, only adjust customer-specific parts (e.g., External interface, SSO, etc.), without having to manually rebuild all intra-VLAN policies.

Benefits:

Increased efficiency in deploying configurations.

Reduced risk of human error when recreating policies.

Stronger standardization across customer environments.

Request:
Please add the ability to include in a template:

VLANs already preconfigured on an interface.

Predefined intra-VLAN policies that can be reused without manual reconfiguration of the From and To fields.

We've listened to your feedback about product enhancement requests and have been hard at work to provide you with a better system. The WatchGuard Idea Portal allows you to submit ideas directly to our Product Management team and receive feedback on your requests.

You can navigate to the Idea Portal by logging into WatchGuard Cloud. https://cloud.watchguard.com

-Click the question mark at the top right of the page and select Give Feedback.
-The idea portal will load and allow you to make submissions for new ideas or upvote existing requests.

Thank you,

One primary use case for this is to specifically deny Tor exit nodes for all my inbound policies and including the block sites list. Which I can copy the Tor feed, but it updates and is dynamic. There is also many other EDL lists uses cases for hooking into for various kind of feeds. I do already have it set to temporarily block unhandled packets and that is good. But I want it where my webservers/ftp etc is blocked from these nodes as our business doesn't require any Tor based traffic.

Some examples of of what you can do -

Example 1

Example 2

Similar request on Reddit

DDoS is becoming more of an issue in todays world. The larger cloud based DDoS mitigation providers (Akamai and Cloudflare to name a few) use GRE tunnels from their cloud to facilitate services. Currently there is no way to implement these connections on a WatchGuard appliance.

This leaves 3 options, purchase expensive dedicated connections, find sub optimal DDoS providers or move away from Watchguard products to another Firewall vendor. Replacing the WatchGuards is seen as the easiest and lowest friction option.

The ability to create a GRE tunnel exists already, just not without layering encryption over it. This has to be a simple fix from a development perspective and has a strong business case to prevent users of enterprise appliances migrating away.

With the recent enhancements to Azure AD MFA implementing number matching, this would be a huge boost for security with the mobile workforce.

Currently, we can use RADIUS via approve/deny or purchase AuthPoint at an additional license fee and use tokens. For those of us already paying for Azure AD, it would be nice to tie it all in together without another purchase.

Unfortunately RADIUS does not support anything except for approve/deny and that is now being exploited through "MFA fatigue" attacks, where an attacker repeatedly sends MFA requests to your device until you approve. Number matching removes this problem.

more info:

https://learn.microsoft.com/en-us/azure/active-directory/authentication/how-to-mfa-number-match

Background:
Currently, on a Firebox running version 12.11.3, the available options for SNMPv3 encryption are limited to the following:

Authentication Protocol:

None
MD5
SHA
Encryption Protocol:

None
DES
These protocols no longer align with current security standards and are widely considered insecure. Additionally, we use Domotz for SNMP communication and the article referenced here https://www.watchguard.com/help/docs/help-center/en-US/Content/Integration-Guides/General/Domotz RMM.html is incorrect. Domotz uses SNMPv3 and we would like to use SNMPv3 for Domotz and Watchguard communication.

Thank you,

I would like to kindly request the opening of a feature request to update the encryption algorithms available for SNMPv3 on Watchguard devices, specifically to include modern standards such as SHA256, AES128, AES256, and similar options.

Background:
Currently, on a FireboxV running version 12.11.1 (Build B711554), the available options for SNMPv3 encryption are limited to the following:

• Authentication Protocol:

  • None
  • MD5
  • SHA

• Encryption Protocol:

  • None
  • DES

These protocols no longer align with current security standards and are widely considered insecure. Additionally, the upcoming Zabbix cluster, based on AlmaLinux 9, no longer supports the DES protocol at all. According to the Red Hat Enterprise Linux 9 documentation (see: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/considerations_in_adopting_rhel_9/assembly_shells-and-command-line-tools_considerations-in-adopting-rhel-9#ref_changes-to-system-management_assembly_shells-and-command-line-tools), the DES algorithm has been removed from net-snmp communication in RHEL 9 due to its insecurity and lack of support in the OpenSSL library.

Impact:
Without updated encryption options, encrypted SNMPv3 monitoring will not be possible with the new Zabbix system unless the firewall is monitored via a proxy running AlmaLinux 8. This limitation could significantly affect secure network management moving forward.

Request:
Please consider adding support for modern encryption algorithms (e.g., SHA256, AES128, AES256) to SNMPv3 in future Watchguard firmware updates to ensure compatibility with current and future systems and to meet modern security standards.

Thank you for your attention to this matter. Please let me know if you need any further details to process this request.

Best regards,
Fabian Öttl

We've found that our vFirewall needs to be rebooted every few weeks so this type of feature would be handy.

What are others opinion?

My issue is I have several users that need to use the VPN to login and clock in and out each day. I can make this work by forcing all traffic thru the VPN.

However IT does not need to have this ability forced on them, or they need access to different network resources than a regular user does,

I hope this makes sense.

1. Remove dnsdynamic.org - The service was discontinued and is no longer operational as of Oct 2023.
2. Cloudflare - It should not require the Global API key. We should be able to use regular restricted API tokens.
3. Digicert DNS Made Easy - Please add this service to the list of options https://dnsmadeeasy.com/technology/dynamic-dns

Thanks

IPv6 seems to have a problem where vendors are not completely supporting IPv6 because users are not demanding IPv6 support because the vendors are not providing full IPv6 support.

1. Add Device as Cloud Managed > Set IP addressing (No MTU options present at this stage)
2. Device deploys as cloud managed, all interfaces set at 1500, device password hits, Cloud Managed WebUI takes over, i.e. some of that initial config has taken place.

If ETH0 requires an MTU under 1500 am finding the firewall remains in a “never connected” state, never connected means no configuration is possible in WGC i.e whatever you do here isn’t deployable if its in the never connected state. In addition, the CLI prompt changes to Cloud Managed meaning no config options from CLI either. So am left with a cloud managed firewall that believes its cloud managed but never connects into WGC so I can’t fix it.

Am sure this is a rare circumstance and am also not yet 100% sure its MTU but I have repeated it a few times and end up with a device that I can’t configure from WGC, CLI or any other method to repair it.

What are the chances of getting VLAN's added to the external interface part of the setup wizard?
In Australia a lot of our ISP's are using VLAN's when providing network connections, I'm watching all of the setup videos for the Watchguard devices and it's all either DHCP/PPPoE/Static IP options, but it'd be great to be able to setup a VLAN with the static IP so that we can get the benefit of the automatic setup of the subscription services also.

Hopefully it's not too difficult to implement because it'd definitely be useful for our business connections.

Thanks !

Many devices that I know have a possibility to block a source IP after a certain number of wrong password requests for some minutes, e.g. 10 minutes after 3 wrong passwords. As far as I see, the WG Firboxes do not have such a feature, which would make brute-force attacks much harder. And blocking the source IPs by hand is a tedious job as they change all the time.
What das WG support say?

I know and read the KB article 000024807 "Unknown authentication attempts against Mobile VPN with SSL from a user named "test" or other random users", but the actions described there are limited to detecting such attacks and applying geolocation. In our cose this does not help as the attacks come from countries we cannot easily block. The suggested connection rate limits would not help either as these attempts are 1 every 5 minutes or so. And we have AuthPoint 2FA, but this does not prevent the login attempt. So a feature to block such requests after some false logins would improve security a lot.