Forty Simultaneous VPN Logins and a Twelve-Month Audit

The pattern - a burst of simultaneous logins, timeouts, success on retry, and admin logins failing in the same window - points at the authentication path being serialised or slow, not at wrong credentials. Wrong credentials produce rejections, not timeouts.

Check in this order:

1. Firebox diagnostic log, filtered on authentication events for that window. Look for which auth server object is being attempted and how long it takes to time out. That tells you whether it is one server or both.
2. NPS event log on both domain controllers (success/failure audit events around 08:25). If one NPS server logged almost nothing, it is unreachable or its shared secret is stale, and every login is paying a timeout before falling through.
3. Name resolution. If the auth server objects use hostnames rather than IPs, a slow DNS answer adds delay to every attempt, and delays multiply at burst time.
4. Reachability and ordering. Confirm both NPS servers are listed on the Firebox and that failover actually happens - test by stopping the primary and logging in with a single account.

Biggest single change: remove the timeout from the critical path. Use IP addresses for the auth server objects, confirm the secondary is genuinely being tried, and if your Fireware version exposes timeout/retry on the auth server object, tune it to the NPS response time you measured rather than the default. The change that matters most operationally is a break-glass local admin account in the Firebox database, so an authentication outage cannot lock admins out of the device they are trying to fix.

Do not fix this by shortening the VPN certificate lifetime or resetting shared secrets until you have the log evidence; both create new failure modes.

Exactly 30 minutes with active traffic rules out an idle timeout: idle timers only fire when there is no traffic. A precise interval on an active session means something is being told to end the session at that mark.

Where to look, in order:

1. RADIUS attributes returned for that user. NPS connection policies can return Session-Timeout (commonly 1800 seconds) with a termination action. The Firebox honours it and the session ends on schedule regardless of activity. Check the NPS network policy applied to VPN users, not the Firebox first.
2. Mobile VPN with SSL global/user settings. Look for session and reconnection settings that impose a maximum session length rather than an idle limit. Distinguish clearly between 'idle timeout' and 'session timeout' on the configuration page - they are different fields and only one matches this symptom.
3. Client-side behaviour. Some clients reconnect on a fixed cycle; a client that drops and re-establishes every 30 minutes looks like a session drop in the logs but is not.
4. Confirm with a controlled test: give one test user a policy with no Session-Timeout and compare. If the test user stays connected past 30 minutes, the cause is confirmed on the NPS side.

Fix in the right place. If the 1800-second value came from a default NPS policy nobody chose deliberately, change NPS. Patching around it on the Firebox leaves an unexplained timeout that will resurface when someone rebuilds the NPS policy.

Retention is a function of log volume and storage, not a setting you can simply raise. Work the arithmetic before buying anything.

Options, in the order I would try them:

1. Cut the volume before buying storage. The overwhelming majority of log volume is normally allowed-traffic records on the busiest policies. Turn off logging of allowed traffic on high-volume policies (guest, server-to-internet, internal-to-internal) and keep it on for denied traffic, authentication, VPN sessions and anything named in the audit scope. This routinely buys the retention multiplier outright, because the audit asks for session and denial records, not every successful HTTP GET.
2. Resize Dimension. Retention per log type is driven by the disk allocated. Expanding the VM disk is usually cheaper than a new appliance, and each log type (traffic, diagnostics, authentication) has its own retention setting you can tune independently - do not treat them as one number.
3. Archive off-box for the audit period. Send logs to an external syslog/log server, or use WatchGuard Cloud's log retention for the archive while Dimension stays as the day-to-day reporting/search tool. The auditor needs retrievable immutable records, not a live dashboard.
4. Certify exports. For many audits, periodic signed exports plus a documented retention procedure satisfy the requirement where on-box retention cannot.

Be explicit with the customer about the trade: 12 months of full traffic logging for 120 users on 80 GB is not achievable, and if their auditor genuinely requires every allowed session, that is a storage sizing project. Get the requirement in writing before committing to a number - '12 months of VPN session records' and '12 months of all traffic' differ by an order of magnitude.