Gateway or Forwarded Client? Reading the Source Address

The web server logs one address, and everyone assumes it belongs to the gateway's own process. It may belong to a forwarded client whose private address disappeared at the translation step. The destination sees the visible network source and nothing more. That is a boundary statement, not a claim that the origin can never be established.

What the Destination Actually Sees

Take a client at 10.20.0.7, a gateway whose outside address is 198.51.100.10, and a destination on the internet. If the gateway translates the client's source, the destination's socket records 198.51.100.10. The private address is gone from the packet, and the destination cannot read it back from that header. Those numbers are illustrative, not a capture from your network.

The observation is still useful: it identifies the network source that the destination must allow or block. It simply does not identify the person or the process behind it. For the destination's operator, that distinction decides whether a block is a network decision or an account decision.

Translation State Is Not Visible to the Destination

The gateway keeps the mapping between the translated connection and the original client, and that state is exactly what the destination lacks. The traditional NAT description separates the translation record from the headers visible afterwards. Reading one side does not give you the other.

Different designs produce different evidence. Routed traffic with preserved source addresses shows the client's real address, while an application proxy terminates the connection and creates a new one. A preserved-source route also requires the client's address to be routable back from the destination, which not every deployment provides. Ask which design is deployed before interpreting a log line.

conntrack -L -s 198.51.100.10
tcpdump -ni eth0 host 198.51.100.10

TTL and Fingerprints Are Clues, Not Proof

An IPv4 TTL depends on the initial value chosen by the sender and the number of hops the packet crossed. Without both facts, a value cannot prove that a VPN hop occurred. A known extra routed hop also fails to distinguish a LAN router, a tunnel path, or another forwarding arrangement. Treat a TTL difference as a question, not a conclusion.

Other signals behave the same way. A user-agent header can be set by the application, and timing similarity can reflect shared infrastructure rather than a shared person. Several users can share one exit, and one user can change paths between sessions. Collected together, several weak signals may justify a closer look at a gateway's records, but they do not become strong evidence by accumulating.

Authorize by Identity, Not by Address

If the destination must separate gateway administration from remote-user activity, give those roles separate authenticated identities and permitted operations. A shared public source can still serve as a network restriction, yet it is no substitute for authenticating the user or the device.

Keep the evidence labelled: observed source, authenticated account, timing, and the inference under consideration. Do not translate no inner source visible here into no attribution possible anywhere. The label matters when someone who was not part of the investigation reads the record months later.

Record the date of the observation and the system that produced it. An unattributed log excerpt is difficult to defend later.