What Router Logs Show When the VPN Payload Is Encrypted

Encryption decides whether a packet's contents can be read, and it says nothing about whether the packet's existence, size and timing get written down. A router forwarding an encrypted tunnel sees a flow it must deliver, and it can count, timestamp and attribute that flow. Compare what a home gateway records against what an upstream network records, and the difference turns out to be about which fields each one has a reason to keep.

That comparison is the useful one, because the two records get conflated constantly in privacy discussions. They answer different questions and they are retained for different periods.

Two Observers, Two Different Records

The gateway at your edge knows which local interface the flow used and, when it hands out addresses itself, which device held that address at the time. It may also see which resolver you queried and which endpoint you contacted. Upstream, the same traffic arrives translated, so another network sees one public address shared by the whole household, which is the function described in RFC 3022. Neither observer read the payload, and neither record contains the other.

Byte totals belong to this category as well. A volume counter records that traffic passed without recording what it was.

Which Fields Actually Leave a Trace

What a given device stores depends on what is enabled, so any universal claim deserves suspicion. The table lists the fields that matter in practice and what each one implies.

Read the table by row rather than by column, since each row supports a different conclusion. The endpoint address shows that a tunnel exists, not what it carried. Local device mapping is the row that ties a flow to a person, and it is the row a home gateway holds while an upstream observer usually does not.

The payload row stays the same in both columns, which is the part encryption actually guarantees. Everything else depends on logging choices.

A Router That Terminates the Tunnel Sees More

A gateway forwarding someone else's encrypted traffic and a router running the tunnel itself occupy different positions. The second holds tunnel state, holds the keys for it, and can therefore see inner addresses and the destinations inside the tunnel. If that router also translates addresses for the inner network, its logs can join a device to an inner destination in one record. That is a different disclosure from the outer flow, produced by the same box.

Compare that with a laptop client behind a plain gateway: the gateway records the outer flow, and the client's own log holds the inner detail. Asking who holds which half of the picture is more productive than asking whether the network can see through encryption. The honest answer to the second question is no, and it is also not the question that decides your exposure.

Check What Your Own Device Records

Look at your own equipment before reasoning about anyone else's. The commands below list firewall rules that carry counters, connection entries still alive, and log lines mentioning a connection. They apply to a Linux-based router, which is what most consumer firmware descends from.

nft list ruleset | grep -A2 counter
conntrack -L 2>/dev/null | grep 1194
logread | grep -iE 'vpn|1194' | tail -n 20
cat /proc/net/nf_conntrack | wc -l

A ruleset with counters tells you what the device is willing to count, and the connection table shows live flows rather than history. Log lines confirm whether the firmware writes connection events at all, which settles most of the argument. Empty output on all four commands means the box forwards without recording, and that is an answer too. Repeat the check on the client, because its log holds the other half of the picture.

Record the enabled facilities and the retention setting beside the outputs. The same hardware can be silent today and talkative after a firmware update that turns telemetry on.