Redact a VPN log without losing the clues that matter

You paste a log into a support thread, a reply points out that it carries your private key, and the paste is permanent. The quieter failure shows up later, when every address has become X and the file no longer proves that the client and the server were different hosts. A redaction pass removes what grants access or names a person, and keeps what explains the failure. That is a transformation with rules, not a deletion with a search box.

Redaction is a transformation, not a deletion

A log carries structure as well as values: this address spoke to that one, at this time, and the handshake stopped at this step. The values are what make the file dangerous to publish. The structure is what makes it worth publishing at all.

Deleting whole lines removes both at once, which is why a trimmed log often answers nothing. Collapsing every value into one token fails differently, because two distinct peers become a single actor. Either pass can look tidy and still destroy the evidence. The test is whether a reader who has never seen your network can follow the sequence and reach the conclusion you reached.

Excerpt first, strip second

Cut the section around the failure before you edit anything. A smaller excerpt is easier to inspect, and it is less likely to carry something you forgot was in the file. Keep the untouched original in protected storage until the issue is closed. Redaction is lossy, and the raw file is the only way to answer the follow-up question.

Read the excerpt as plain text before trusting an export command to have stripped the private parts, because exporters summarise and rotate fields rather than sanitise them. Debug and verbose modes are the most likely place for a key block or an inline credential. Open the file in an editor that shows full lines, not a viewer that wraps and hides the tail.

What has to go, in order

Start with material that grants access, because a miss there ends the exercise: private key blocks, passwords, pre-shared keys, API tokens, recovery codes. These are not merely identifying; they are usable by whoever reads the thread. A pass that removes everything else and leaves one of them has failed.

Then the identity layer: usernames, certificate subjects and serial numbers, account identifiers, and any path that contains a person's name. None of it is usable alone, but together it names a person, and that is the part a public thread does not need.

Then the topology layer, which is where judgement enters. Public addresses, internal ranges and hostnames can all be replaced when their disclosure serves no diagnostic purpose, and stable labels beat blanks. The order matters because the earlier layers are absolute and the last one is a decision. Working in that order also stops you from spending an hour on hostnames while a key block sits in line forty.

Do not destroy the relationships

Give each real value one placeholder and reuse it every time that value appears. If two addresses were different, they must remain different after the pass, or the reader will conclude the client connected to itself. Consistency is the whole mechanism: the reader learns the mapping by watching a label recur. A single reused token for two actors is the fastest way to make a log unreadable.

Ordering and time are part of the same structure. Keep the sequence intact, and if you shift timestamps, shift every one of them by the same amount and say so in one line. Mixing altered and real times is worse than removing them, since the gaps then look like evidence of something that never happened.

Ports, protocol and direction stay as they are. A placeholder on the address does not require a placeholder on the port.

Keep the question the log has to answer

Write down the fields a helper needs before you start editing: the exact non-secret error text, client and server versions, transport, and which side initiated the attempt. Those are what let a stranger recognise the failure. Keeping the list beside you turns the pass into a check rather than a hope.

When you send the file, add one line saying what was replaced, so nobody spends an hour diagnosing a placeholder hostname. OpenVPN's diagnostic log documentation lists the fields its logs carry, which is the list you are about to alter. Ask before sending a memory dump or a packet capture, and use the support channel you can verify. Those artifacts hold far more than the text log, and some of it is not yours to publish.

Read the finished excerpt once from the first line to the last, including the beginning and the end. Screenshots deserve more suspicion than text, because they carry other windows, account names and menu items.