FortiGate VPN Failure Email: Filter Fields, Not Logs
Pick the notification shape, build it from event 39426 fields, then quiet the volume without disabling the VPN log category or the audit trail.
Two decisions hide inside "email me when a VPN login fails". The first is how the notification is delivered: one mail per event, a periodic digest, or an alert from a collector. The second is what the message contains. Getting the first wrong floods a mailbox, and getting the second wrong deletes the fields that make the alert actionable. Neither decision requires suppressing the VPN log category, which is the shortcut that quietly destroys the audit trail.
Three delivery shapes and when each fits
| Shape | Fits when | Cost |
|---|---|---|
| Per-event automation email | low volume, one team responds | a burst of attempts becomes a mailbox flood |
| Scheduled digest | routine review, trend watching | nobody sees an attempt in progress |
| Collector alert with correlation | high volume, shared SOC | one more system to keep fed and tuned |
Choose by who responds and how fast they can, not by which option is easiest to configure. A single FortiGate protecting one office can justify per-event mail. The same configuration on a gateway taking credential-stuffing attempts produces thousands of messages a day and gets filtered into a folder nobody reads.
Start from the event record, not the subject line
Read a representative stored event on the release you actually run. The FortiOS 7.4.8 log reference identifies SSL VPN login failure as event 39426, and its fields include action, user, remip, reason, tunneltype and vd. Designing a filter from a forwarded email subject instead of that record is how people end up matching on a field name their firmware spells differently. Open two or three real failures and confirm the identifiers match before writing a trigger. The five minutes it takes is shorter than a week of alerts that fire on the wrong event.
An automation stitch joins an event-log trigger to an action, and the trigger is where the event selection belongs. Add only the extra field conditions your requirement needs; a trigger that filters on a small set of fields still delivers untested behaviour for the rest.
Build a compact body from supported replacements
In releases that document log-field replacement for email actions, the body can be short and still useful. The shape below is illustrative; confirm the attribute names and replacement syntax against your firmware version before you commit it.
config system automation-trigger
edit "ssl-vpn-login-fail"
set event-type event-log
set logid 39426
next
end
config system automation-action
edit "mail-vpn-fail"
set action-type email
set email-to "[email protected]"
set email-subject "SSL-VPN login failed"
set message "Account: %%log.user%% | Source: %%log.remip%% | Reason: %%log.reason%%"
next
endA template that renders an empty field does not prove the event lacked that data. Check the field name and the replacement syntax first, then test with one controlled failure and read the actual message. Add device identity and occurrence time so a responder can find the full record without guessing which unit sent the mail.
Quiet the volume without deleting the record
Rate control, grouping and correlation belong in the delivery layer. Raising the minimum email severity for everything is a blunt instrument that hides unrelated events, and disabling the VPN log category is worse: the events stop being written at all. Keep the approved logging destination and retention policy exactly as they were, and let the notification path become quieter instead. Document what you suppressed, because the next person will find a gap in the mailbox and needs to know it was deliberate.
When the new path is validated, retire any overlapping legacy email rule through a reviewed change. Ending with two paths that both fire, or with neither firing because the old one was disabled first, is a common result of doing the cleanup before the test.
Read a failure as a failure
A failed authentication event is not a successful VPN session, and a user name in an event is not verified attribution to a person. Correlate the reason with successful logins, known user activity and repeated attempts before declaring an account compromised, and say in the alert which of those you checked.
Send the notification only to authorized recipients. Account names, internal device identifiers and source addresses are operationally sensitive, and a distribution list that grows by convenience becomes a leak path. One actionable path plus an intact audit trail is the whole objective.