WatchGuard Firewall Alerts

Triage a WatchGuard event: Firebox appliances, AuthPoint MFA, and the mobile VPNs behind
them. Console checks, log review, AuthPoint changes and config edits are technician actions
you direct and record. Verify certificate and firmware facts in the console; never invent
detail.

1. Firebox offline → device-offline-runbook logic with the firewall twist: "offline" in
   WatchGuard Cloud means the management tunnel is down, not necessarily the site. Check
   other site alerts and user tickets first. Cloud management down
   while the site passes traffic is an ISP blip or the appliance's outbound path: low
   urgency, still investigate. Site down → network-outage-triage: power, ISP, then the
   appliance; an unreachable firewall is a full-site event. Never close on "it came back"
   without noting the gap window and checking prior tickets — a nightly flap is an
   ISP/DHCP/power problem ticket.

2. AuthPoint MFA — identity first. Verify the requester on a number on file before touching
   MFA state (same canon as duo-mfa-anomalies) — MFA "help" is a takeover vector; the
   channel it came from is not proof. Push not arriving → mobile side first (notifications,
   connectivity, app signed in); token codes rejected → device clock drift. Pushes the user
   didn't initiate → the password is burned: rotate now and have the technician review the
   auth logs; a push approved by mistake goes to compromised-account-containment.
   Re-enrollment on a new phone follows the verified-identity ladder — remove the old token
   first. No standing bypasses: anything issued is time-boxed and logged.

3. VPN auth failures — scope decides the branch. One user → credential state upstream
   (AuthPoint, RADIUS, the directory), client version, their network; walk
   vpn-troubleshooting. Many at once → the server-side chain (Firebox, authentication
   server, directory): check certificate expiry on the VPN portal, auth-server health and
   recent config changes. Mass failure right after a config or certificate change is that
   change until proven otherwise. Repeated failures for one account from unfamiliar sources,
   with no user at the keyboard, is credential stuffing — a security event
   (security-alert-response), never resolved by unlocking the account again.

4. Note what was checked in which console, the verdict and outcome — plain text, no
   markdown or emojis (apply the PSA Note Discipline base skill). Firewall config changes
   run under the client's change process, never as routine ticket work. Escalate hardware or firmware
   suspicion to WatchGuard support with a package: serial, firmware version, cloud status
   history, log excerpts, what was ruled out. For hands-on work, deep-link the tech to
   the device in the RMM.

Without console visibility, say the view is partial and name what the tech should pull. When
in doubt do nothing irreversible and escalate.