How to Tell Which Address the FTP Server Actually Logs

A log line shows one address. The laptop carries a tunnel address, the connection may leave through a different exit, and the browser check you ran proves nothing about FTP. Those three can all differ, and the log line only ever records one of them. Decide which connection you are asking about before you compare anything.

These steps assume an authorized investigation with a defined time window, not a browse through somebody's transfers.

1. Fix which connection you are asking about

FTP uses two connections. The control connection carries commands and replies, and the data connection carries the file itself. A login event belongs to the first, a transfer event belongs to the second, so one session in a log may hold observations from two different network paths. Write down which event the address field belongs to before you draw conclusions from it.

The split has a practical consequence. A login line and a transfer line from the same session can carry two different source addresses, so quoting either one as "the client address" is a guess about which connection you are reading. Check the event type before you match an address against anything.

2. Follow the control connection

Run the client with debug output enabled, or capture on the client while it connects, and note the peer it actually reaches. If a VPN is up and the client is routed through it, the server sees the VPN exit address rather than the laptop's access-network address.

If the client bypasses the tunnel, the server sees the access address and the VPN interface's own address never appears on the wire. That is why the laptop's tunnel address is usually the least useful value in the picture: it exists only inside the tunnel. Use ss or a packet capture to confirm the source the client presents, rather than reading it off a configuration screen.

Two commands cover most of it:

ss -tnp state established "( sport = :21 or dport = :21 )"
tcpdump -ni any tcp port 21

The first lists the local and peer endpoints your own stack used. The second shows the addresses written on the wire, which is closer to the server's view but still stops at your interface, so only the server's log or its own capture shows what the server recorded.

3. Check whether the data connection matches

In passive mode the server tells the client where to connect, and in active mode the server connects back to an address the client supplied. Both modes can send the data connection somewhere different from the control connection when translation or a proxy sits in the path. Confirm the mode from the client log, then check whether the data connection used the same path.

A transfer logged from a different address than the login is a real observation rather than a corrupt record, and it usually says something about the path.

4. Ask the operator for a narrow record

Give the server operator the session time with its timezone, the account, the operation and the destination. Ask which connection produced the address field, and whether a trusted intermediary changes its meaning.

Read that server's actual schema instead of assuming every product records the original client, the control peer and the data peer separately, because some summarize a whole session under one line. Keep the protocol clear too: SFTP is an SSH-based protocol rather than FTP on another port, and FTPS adds TLS to FTP, so the service identity in the log depends on which one you deployed.

5. Verify before you attribute

An exit address can serve many customers, and one account can be used from several permitted sources, so an address and a username do not identify the same unit. Logging is a server policy: a VPN changes the source a connection presents, but it does not erase the account name, the filename or the operation the receiving service processed. Attribute only what the record shows and mark the rest as unknown. The WinSCP FTP description is a compact reference for the two-connection model if you need to explain it to somebody else.

Two ordinary cases show why that matters. An office can send every user out through a single exit address, so a hundred people produce one value in the log. The reverse happens just as often: one account connects from a home line and from an office line in the same week, and both entries describe the same person.