Where Are Azure Point-to-Site VPN Logs? Look in Monitor

A user cannot connect to the point-to-site gateway, you open the gateway blade, and there is no connection history anywhere on the page. Configuration, certificates, status: all present, no records. The logs exist, but they are not produced by the networking pages at all. They come from a diagnostic setting attached to the gateway resource, and that setting lives under Monitor, which is why the first search in the obvious place returns nothing and people conclude the service keeps no audit trail.

Why the obvious search fails

Older guidance states that Azure point-to-site VPN has no auditing, and that was true when the service exposed no per-connection record. Current gateways publish tunnel diagnostic records, so the useful question changed: not whether logs exist, but which resource emits them and which category you switched on. The gateway blade is a configuration surface, and configuration surfaces rarely double as log viewers. A diagnostic setting is a per-resource object, so the resource you choose determines everything that follows.

The other half of the confusion is authentication. Certificate-based point-to-site connections do not generate a per-user sign-in event the way an identity provider does, so there is no record of a named person typing a password to find.

Attach the diagnostic setting to the gateway resource

Open Monitor, then Diagnostic settings, and add a new setting whose target is the virtual network gateway itself rather than the virtual network that contains it. Select the point-to-site diagnostic category, the one named P2SDiagnosticLog, which is what carries per-client connection records; add the tunnel, route or IKE categories only for the site-to-site errors they cover. Then send the data to a Log Analytics workspace you control with a retention period you chose on purpose. Most failed searches are a setting attached to the wrong resource, not a missing feature.

Category lists differ by gateway type and generation. If the point-to-site category is absent, the gateway may predate the feature or run a SKU that never emits it, so check the supported categories before you go looking for a permissions problem. A gateway with no point-to-site category is not broken; it simply cannot be the source of that record, and the closest substitute is the tunnel or IKE category, which records the client address even though it does not describe a point-to-site session. Confirm the category list before you open a support case about missing logs.

Read the records in whichever table your mode uses

With the legacy collection mode, entries land in the AzureDiagnostics table and the category appears as a column value; with resource-specific tables, the gateway has a table of its own. Either way, query by the gateway resource and a window around the failed attempt, then read the correlation rather than the individual rows:

AzureDiagnostics
| where ResourceType == "VIRTUALNETWORKGATEWAYS"
| where _ResourceId has "gateway-name"
| where TimeGenerated > ago(2h)
| project TimeGenerated, Category, OperationName, ResultType, ResultDescription
| order by TimeGenerated desc

The column set follows your collection mode, so treat the query as a shape rather than a script. What you are looking for is a client address that appears and then disappears, with a result type that is not success.

Pair the gateway record with the client's own view

Gateway logs describe the tunnel, not why a laptop failed to build one. Collect the client side at the same timestamp: the Windows event log for the RAS client, the macOS connection log, or the error text the client app displayed. A gateway record with no matching client attempt points at the client; a client reporting success while the gateway records nothing usually means the profile is aimed at a different gateway.

Keep both halves in the same ticket. A gateway log alone invites the wrong conclusion, and a client log alone cannot show whether the packet ever arrived.

If nothing appears in either place, check the clock on the client before doubting the platform. Skewed timestamps make correlation fail in a way that looks exactly like missing data.

Retention, scope and the runbook entry

Tunnel records carry client addresses and connection timestamps, so treat them as personal data with a deletion schedule instead of leaving the platform default in place. Check too that the workspace is not ingesting every category from every resource in the subscription, because a noisy workspace makes correlation slower than reading the client log directly.

Finally, write the setting name, the workspace and the chosen categories into the gateway's runbook. The next person to debug a client will look in the gateway blade first, find nothing, and conclude the logs do not exist.