IP addressing, subnets, NAT, and what corporate networks really look like

What an IP address encodes

An IP address identifies an interface on a network. The version still dominant in most internal networks is IPv4, a 32-bit number written as four decimal parts, such as 192.168.10.24. An address has two components: a network part, shared by every device on the same local network, and a host part, unique to the device. The split between them is not fixed by the address alone; it is set by a subnet mask, which marks how many leading bits are the network part.

The newer version, IPv6, uses 128-bit addresses to solve IPv4 exhaustion. Its addressing changes several assumptions in this chapter, and the differences are noted where they matter. Most internal enterprise traffic a defender examines today is still IPv4, so the body of the chapter uses it. (high)

Subnets and CIDR

A subnet is a contiguous block of addresses treated as one local network. The modern notation is CIDR, Classless Inter-Domain Routing, which writes the network part as a slash and a number: 192.168.10.0/24 means the first 24 bits are the network, leaving 8 bits, or 254 usable addresses, for hosts. A /16 is larger, a /28 smaller. The number after the slash is the mask.

Organisations divide their address space into subnets for two reasons that matter to a defender. The first is routing: traffic between subnets passes through a router or firewall, which is a place a control can be applied. The second is segmentation: putting staff laptops, servers, printers, guest devices and building systems on separate subnets limits what can reach what, and gives each segment its own policy. A device does not decide its own subnet; it is placed on one by the switch port or wireless network it joins, and given an address from that subnet's range.

Private address space and NAT

Most devices inside an organisation do not hold a public, internet-routable address. They hold an address from the private address space reserved for internal use: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. These ranges are not routed on the public internet. A packet with a private source address cannot, on its own, reach an external service and get a reply.

The mechanism that bridges the gap is NAT, Network Address Translation, run by the router or firewall at the network edge. When an internal device connects out, the NAT device rewrites the private source address to the organisation's public address, records the mapping, and rewrites the reply on the way back. In practice this is almost always port-based translation: many internal devices share one public address, distinguished by port number in the translation table. From outside, the entire organisation appears as one address, or a small pool of them.

This is the core fact behind the opening scene. The remote service, and its logs, see the organisation's public address. They do not see 192.168.10.24. The information that maps the public address and port back to an internal device exists only inside the organisation, in the NAT device's translation table, and only for as long as that table or its logs are retained.

What a corporate network really looks like

A real corporate network is not one flat space. A device joining it is typically assigned its address automatically by DHCP, the Dynamic Host Configuration Protocol, which leases an address from the subnet's pool for a set time and records the lease. The device is told a default gateway, the router it sends outbound traffic to, and an internal DNS resolver, which is the resolver referenced in the previous chapter.

The address space is usually carved into separate segments, often as VLANs, virtual LANs: a segment for staff devices, a separate one for guest Wi-Fi, others for servers, printers, voice handsets and building systems. Public-facing services may sit in a DMZ, a segment exposed to the internet but walled off from the internal network. Outbound traffic leaves through a firewall, and often a proxy or secure web gateway, which is where egress filtering and logging happen. Remote staff are pulled back onto this structure through a VPN, or routed through a cloud security service. The important pattern for a defender is that identity and logging are strong on some segments and weak on others, and the guest segment is usually the weakest.

The attribution problem

Return to the four hundred connections. There are two separate attribution problems, and they have different answers.

The external problem is the remote service's view. The AI service recorded the organisation's public address, shared through NAT by every device on that egress. From the service's side, the organisation is one entity. If the organisation later wanted the service to confirm which staff member sent a particular prompt, the service's connection logs cannot provide it; they resolve only to the shared address. Any attribution has to come from the organisation's own records, not the vendor's.

The internal problem is the organisation's own view, and here the answer depends on records and on which segment the device was on. On the staff segment, the proxy or firewall logs the internal source address and the destination. To turn the internal address into a device, the team needs the DHCP lease that was active at that time, because addresses are reassigned. To turn the device into a person, the team needs an identity signal: a proxy that authenticated the user, or a sign-in correlated by time. With all three retained, proxy log, DHCP lease and identity, the four hundred connections can be attributed. With any one missing, the chain breaks.

On the guest Wi-Fi segment, the chain usually breaks by design. Guest networks commonly apply NAT with little or no user authentication, so the record is an internal address that changes with each lease, reaching an AI service at a time, with no link to a named person. This is the same limitation the enterprise sees when it relies on network logs alone: the evidence supports "a device on our network used this service" and rarely "this person used this service". (medium; depends entirely on local proxy, DHCP and identity logging)

Addressing also explains why blocking an AI service by IP address is unreliable. Large services sit behind content delivery networks and shared front ends, so a single address may serve many unrelated sites, and the service's addresses change without notice. An address block is therefore both over-broad and easily outdated, which is why name-based and identity-based controls, covered in later chapters, are preferred. Segmentation is a stronger structural control than address blocking: isolating a class of device on a restricted segment limits what it can reach internally. It does not, on its own, stop a staff laptop on guest Wi-Fi from reaching a public AI service, because guest egress still goes to the internet.

Last updated 9 August 2026