Network address translation

Translation changes addressing context

Network address translation, or NAT, changes network addressing information as traffic crosses a device. A common arrangement also translates transport ports, allowing several internal endpoints to share an outward-facing address. The exact behavior depends on the implementation and configuration.

NAT helps explain why a remote service may observe a different address from the one configured on a learner's laptop. IP addresses describes private address space and why the same private address can appear in many unrelated networks.

Follow two learners through a gateway

Imagine a fictional classroom has two laptops using private IPv4 addresses. Both access the same external training site through one gateway. The gateway maintains the translation context needed to associate returning traffic with the appropriate internal exchange.

The remote site may record a shared public source address. If an analyst sees an event from that address, the observation does not automatically identify one laptop or person. Time, ports, protocol, and translation records may be needed to narrow the interpretation.

This also explains why an address-only incident report can be insufficient. The relevant flow has more dimensions than the visible outward-facing address.

Inbound reachability is a separate decision

A gateway may have explicit forwarding rules or other arrangements that allow incoming traffic to reach an internal service. Do not assume a private address makes a service unreachable in every configuration.

Similarly, translation should not be treated as a substitute for a well-defined firewall policy. Firewalls explains traffic restrictions, while NAT primarily changes how endpoints are represented across a boundary. Devices often combine both functions, which can make their separate responsibilities easy to confuse.

For the classroom, document any published internal services and who approved them. The absence of a remembered rule is not proof that no inbound path exists.

Evidence needs synchronized context

Suppose the training site reports suspicious requests at a particular time. The academy may need gateway translation records, address-lease records, device evidence, and application accounts to investigate. Missing or inaccurate time information can prevent a reliable match.

Even a matched internal flow does not necessarily identify the human responsible. Shared devices, compromised accounts, and automated processes are possible explanations requiring additional evidence. Incident timelines develops the habit of stating what an observation supports and where uncertainty remains.

Draw the before and after

For a safe exercise, create an invented flow with source and destination addresses and ports. Draw the gateway's translated representation and the corresponding return journey. Label which identifiers the internal host, gateway, and remote service can each observe.

Then add a second learner using the same destination. Explain what additional context distinguishes the flows. Continue with Ports and services for transport endpoints and DHCP for the lifecycle of locally assigned addresses. The goal is explaining an observed connection accurately rather than treating a public address as a permanent personal identifier.