VPN Login Alerts: Which Event Should Actually Trigger Them?
Auth success, an established tunnel and a RADIUS accounting Start are three different claims. Pick the one your recipient can act on, then correlate.
Authentication success, an established tunnel and a RADIUS accounting Start are three different claims, and a login email only means something once you pick one. Most VPN alert designs mix all three and produce a mailbox nobody trusts. The decision comes down to who reads the alert and what they can do in the next five minutes. Get that wrong and the alert becomes noise that hides the one event you needed.
Three questions decide the trigger
Ask who receives it, what they will do, and how fast the action has to happen. A security team watching for credential misuse wants a failed-then-succeeded pattern from one account within minutes. An operations team watching capacity wants session duration and disconnect reasons, not logins. A helpdesk wants the session identity so it can match a ticket.
Those answers point at different events, and no single rule satisfies all three. If the recipient's action is "call the user", authentication is enough. If the action is "free a license" or "verify the tunnel carried traffic", only establishment or accounting Start will do. If the action is "bill the time", you need Stop records rather than a login.
Write the answer as one sentence before configuring anything. "This email tells the on-call engineer that account X opened a tunnel from network Y at time Z, so they can check whether the maintenance window was used." If you cannot fill every slot, the trigger is not chosen yet.
Match the event to the claim you are making
| Record | What it proves | What it leaves open |
|---|---|---|
| Rejected credentials | The attempt failed at the credential step | Whether it was a stale client or a real person |
| Access-Accept | Credentials passed for this attempt | Anything about tunnel state or policy |
| Policy match record | A rule matched the request | Whether later steps completed |
| Tunnel established | The gateway accepted a session | Whether traffic flowed or the user got an address |
| Accounting Start | User service began at the accounting layer | Whether the application behind it worked |
| Accounting Stop | That session was closed, with a reason field | Whether the reason is meaningful on your release |
The table hides a dependency: each row is only trustworthy if the gateway emits it reliably and your collector keeps the field you need. Read the event definition for the exact release you run, because the name of "session established" changes between versions and the semantics change more often than the name. When a definition is vague, ask for a session capture rather than guessing from the label.
Treating an Access-Accept as the completion of everything after it is the most common mistake. It is a credential verdict, not a session. The mirror mistake is reading a policy match as proof of authorization, when a rule can match and the next step can still fail.
One session, one notification
One account, several devices, retransmits and reconnects: an email per event will be wrong in both directions, duplicating one session while splitting another. Key the notification on the gateway plus a session identifier, and treat the account name as an attribute rather than the key. A user with a laptop and a phone can hold two tunnels at once, and both deserve their own line.
Retransmitted accounting records are normal, so de-duplicate on the session id and timestamp before rendering the message. Consecutive sessions from the same device should stay separate, and a reconnect during a maintenance window should remain visible instead of collapsing into the previous one. If your collector rewrites timestamps on ingest, deduplicate on the original record fields, not the stored ones.
A missing Stop record is uncertainty, not a permanent session. Gateway reboots, collector outages and UDP loss all leave gaps, so the alert needs a reconciliation path that queries the live session table before anyone concludes that a tunnel is still up.
Keep audit and notification separate
The audit stream and the alert stream have different jobs. Keep the raw records, including account, gateway, session id, timestamps and termination reason, even when routine emails are grouped, suppressed or sent to a small on-call list. A severity threshold is a delivery filter, not a selection of the lifecycle event you meant to announce.
Send the minimum context the recipient needs to find the protected record. Account names, internal addresses and session details are sensitive, and an email that forwards well is an email that leaks well.
Then prove it end to end. Run a normal login and logout, a reconnect, two simultaneous sessions and a forced delivery failure, and trace one event from the gateway through the collector to the delivered message. If the email arrives without a session id, the contract is incomplete. If two emails describe one session, correlation is broken. Neither problem shows up when the only thing you test is that mail delivery works.