All tools

WatchGuard Firebox Toolkit

WatchGuard Cloud log-search query builder, cloud-managed SNAT/port-forward helper, and guided Firebox triage.

Why this exists

WatchGuard Cloud's Log Search syntax is finicky and cloud-managed policy/NAT lives behind a maze of tiles. This bundles the known-good query builder, a Static-NAT/port-forward helper, and symptom-driven triage with the fixes to try in order. Cloud-only: no Fireware CLI or on-prem Policy Manager.

How to use
  1. Log Search: pick fields and values, then paste the query into WatchGuard Cloud → Monitor → Devices → Logs → Log Search.
  2. Policy / NAT: build a cloud Static NAT action and the policy reference from a form.
  3. Troubleshoot: pick the symptom (BOVPN down, mobile VPN, site blocked, Firebox offline) and work the fixes in order.

Filters

Last template auto-saved to this browser.

Query

Pick at least one filter to build a query.

Where to paste this

  1. WatchGuard Cloud → Monitor → Devices → (folder/device) → Logs → Log Search.
  2. Set the date/time window. The query does the filtering — the log-type dropdown (defaults to Traffic Logs) only scopes the message class; widen it if the line you want isn't traffic (VPN / service events are Event logs).
  3. Paste the query into the search bar and run.

Field names are the keys from a Firebox log message (disp, src_ip, dst_ip, dst_port, pr, dstname, src_user, msg). Click the field icon in the search box to browse every field for the selected log type.

Operators are uppercase

Combine terms with AND (both must match), OR (either matches), or NOT (exclude, must follow an AND or OR unless it's the first term). The builder joins your filters with AND; edit the query in the bar for OR/NOT logic.

Group with one level of parentheses

You can wrap terms in a single level of parentheses to control evaluation order, e.g. disp:deny AND (dst_port:443 OR dst_port:80).

Wildcards use *

Use * for partial matches (max four per query). A field-qualified term allows leading, central and trailing wildcards (src_user:a*); a bare term allows central/trailing only.

The query is the search, not the type filter

Field-qualified terms do the work: src_ip:10.0.2.1 AND disp:deny finds a block, msg:*ike* finds VPN negotiation. The log-type dropdown (defaults to Traffic Logs) only scopes which message class is searched — widen it when the line you want isn't traffic (VPN negotiation and service events are Event logs), but build the query first.

Searching the past vs watching it live

Log Search is historical. To observe something as you reproduce it (force traffic across a tunnel, retry a login, reload a blocked site), use Monitor → Devices → (device) → Live Status → Traffic Monitor → Live Logs instead, and filter the live feed by message type there.

Locally-managed Firebox? No cloud Log Search

These queries are WatchGuard Cloud Log Search syntax, so they only apply to cloud-managed (or cloud-reporting) boxes. A locally-managed Firebox keeps no searchable history — watch live instead in its own Web UI: Dashboard → Traffic Monitor (filter box + log-type buttons). WSM exists if a job truly demands it, but the Web UI is the standard path.

Any field in a log message is searchable

The query bar accepts any field that appears in a Firebox log message, not just these. Click the field icon in the search box to browse the fields available for the selected log type.

Notes you can keep with the query