Access Log

Summary

Every connection to a fleet device leaves one row: who connected, what they reached, from which address, whether it was allowed, how long it lasted and how much data crossed. Refusals are recorded with their reason. Traffic is never inspected, so nothing here records what was sent.

Needs a fleet, which is on the Pro and Enterprise plans. See Fleets to create one.

What the access log records#

Open Access log under Remote Access in the dashboard sidebar.

Each row is one connection. Allowed connections are written when they close, and refusals are written as they happen. A row carries the identity that connected, the device it reached, the source address, the outcome, the duration and the byte counts.

Nothing about the contents is recorded. No request path, header or body is captured anywhere in the pipeline, so a device serving regulated data leaves a full audit trail and no copy of what crossed it. Request counts are kept, which measures how much a connection did without recording what it did.

Every gate on the platform writes refusals here. Only the client certificate check also writes successes, since it is the only one that identifies the caller at the connection level.

Read a row#

Column	Holds
When	The connection's own clock, from the moment it opened
Identity	The person or machine, by name where one resolves and by identity where it does not
Reached	The fleet, and the device inside it
From	The source address
Outcome	Allowed, or the reason it was refused
Duration	How long the connection stayed open, or `open` while it still is
Volume	Bytes in and out combined

Expand a row for the exact open and close times in UTC and your own timezone, the check that made the decision, the certificate serial, the full source address breakdown and the request count.

The Identity column shows a person's name where one resolves and the raw identity for a machine. Identities from a registered authority appear in their namespaced form, qualified by the issuing organisation.

The access log: who reached which device, from where, and how it went.

Filter down to an answer#

Five filters narrow the table.

Search matches identities and device names, including a machine's display name.
Outcome narrows to Allowed or Refused.
Check narrows to Client certificate, IP allowlist, Password, Header check or Webhook signature.
Source IP is an exact address match, and it reaches inside collapsed rows so an address is never reported as absent when it is there.
Time range covers the last 24 hours, 7, 30 or 90 days, or everything retained.

Source IP is its own field, not part of the search box. It matches an address exactly, so 1.2 never matches 10.1.2.3.

Two shortcuts land here pre-filtered. A certificate's row menu offers What this reached, and a device's menu offers Access log, both opening this page scoped to that one subject. The page names the pinned filter and offers a link to clear it, so a narrowed view is never mistaken for the whole trail.

What a refusal says#

A refused row carries the reason, and the reasons are specific.

Reason	What happened
Certificate required	The caller presented no client certificate
Not allowed to reach this device	The certificate was valid, and no grant covered the device
Certificate expired	Past its own expiry
Certificate revoked	Revoked, either by you or through a registered authority's revocation list
IP not on the allowlist	The source address is outside the fleet's inbound allowlist
Wrong password	Basic authentication failed
Required header missing or wrong	A configured header rule did not match
Signature did not verify	Webhook signature verification failed

The caller is told none of this. The agent reports that the far side refused the certificate and lists what the holder can check, without naming the condition that failed. The exact reason is here, where only your team can read it.

Rows that summarise many connections#

A row covering more than one connection is an aggregate and states how many it covers. Its duration is written as a window, such as over 4m 12s, and its byte and request counts are totals across the set.

Addresses fold the same way. A row covering several source addresses reports how many, and the expansion lists each with its own connection count. Where the set was too large to record exactly, the row says more than that number.

A distinct-address count is attribution, not an alarm. One identity maps to many addresses for ordinary reasons: overlapping certificates during rollover, a person signed in on more than one machine, a CI identity shared by every runner, and NAT putting an office behind one address.

Recent access, without leaving the fleet#

The fleet's Access tab carries a Recent access drawer along its bottom edge. Open it for the last connections to that fleet, or open it from a grant's row menu to see one subject alone.

It is the same data, cropped, so you can check a grant against real connections without leaving the Access tab. The drawer states the retention window under its list, so an empty result means nothing connected within that window.

Export#

CSV downloads the rows currently on screen, with the filters you have applied. Each row carries the timestamps, the outcome, the check, the deny reason, the identity with its resolved name and email, the device, the fleet, the source addresses with per-address connection counts, the certificate serial, the connection count and the byte totals.

Cells starting with a character a spreadsheet would read as a formula are escaped.

To export a longer period, widen the time range and the page size, then export each page.

Retention and who can read it#

The dashboard states your retention window beside the page title, and the range filter is clamped to it. Older rows are not returned. See pricing for what each plan retains.

Reading the access log needs the admin or owner role, since every row carries a source address and the log spans every fleet in the team. Members with the developer role see an explanation instead of the table.

Rows outlive what they describe. Deleting a tunnel, revoking a certificate or removing a member leaves that history readable.

Frequently asked questions#

Does Localport log the contents of my traffic?

No. The access log records connections, not payloads. No request path, header or body is captured anywhere in the pipeline, so there is nothing of that kind to store, export or hand over. What is recorded is who connected, what they reached, when, from where, for how long and how many bytes crossed.

How long does the access log keep records?

The window comes from your plan and is stated beside the page title in the dashboard. A request for older data is clamped to that window instead of being refused. See pricing.

Who can see the access log?

Admins and owners. Every row carries a visitor's source address, and the log covers every fleet in the team, so it is gated the same way the team audit log is. Members with the developer role can still see who has access on a fleet's Access tab.

Are refused connections recorded?

Yes, with the reason. A caller with no certificate, an expired one, a revoked one, or one no grant covers each leaves a row naming the exact condition. Check here first when a caller reports that a device is unreachable.

Why does one row say it covers many connections?

Because a single identity opening thousands of short connections would otherwise bury everything else. Those are folded into one row carrying the count, the total bytes and a window in place of a duration. The row says how many connections it represents, so an aggregate is never mistaken for a single event.

One identity is showing many source addresses. Is that an attack?

Usually not. Overlapping certificates during rollover, one person signed in on several machines, a CI identity shared by every runner and NAT all produce the same pattern. Treat the count as attribution, and use the Source IP filter to check a specific address.

Can I see what one person or one machine reached?

Yes. Open the identity's row menu on the Certificates tab and choose What this reached, or filter this page by that identity directly. It works for revoked certificates too, since what a withdrawn credential reached before you cut it is exactly what an incident review needs.

Can I export the log?

Yes, as CSV. The export covers the rows currently on screen with your filters applied, so widen the time range and the page size before exporting a longer period. Every column the table holds is included, plus the per-address connection breakdown.

What is the difference between the access log and the audit log?

The access log records who reached which device. The team audit log records who changed the configuration, such as writing a grant or revoking a certificate. One is read to answer what happened on the network, the other to answer who changed the rules.

Do connections to ordinary tunnels appear here?

Refusals do, from any gate that turned a visitor away. Successful connections are recorded only where a client certificate identified the caller, so in practice they come from fleets. A tunnel protected by a password or an IP allowlist has no connection-level identity to attribute a success to.