Gateways as routing constructs

Three things called a gateway

The word gateway is overloaded, and untangling it removes a lot of confusion. Each of these is really just a routing table entry plus, sometimes, a translation table.

The important distinction is the last two. An internet gateway changes nothing about a packet except its layer 2 headers and TTL, exactly as in Lesson 5-2. It routes. A NAT gateway additionally rewrites source addresses and ports and keeps a translation table, exactly as in Lesson 6-1. It routes and translates.

That single difference decides what can reach what:

- Behind an internet gateway, a host with a public address is reachable from outside, because the return path exists and nothing was rewritten. - Behind a NAT gateway, a host with a private address can reach out but cannot be reached, because inbound packets have no translation row.

The same idea in a cloud console

Cloud networking uses different words for the constructs from Units 3 to 6, and seeing the mapping once makes the console readable. Taking AWS as the example, since it is the vocabulary most commonly encountered:

The definitions people find confusing turn out to be one line each once the route table is the thing you look at.

- A public subnet is a subnet whose route table sends 0.0.0.0/0 to the internet gateway. That is the entire definition. Nothing about the subnet itself is public. - A private subnet is one whose route table sends 0.0.0.0/0 to a NAT gateway sitting in a public subnet. Instances there can fetch updates and call APIs, and nothing on the internet can open a connection to them.

public subnet  10.0.1.0/24 route table
  10.0.0.0/16  local
  0.0.0.0/0    internet-gateway

private subnet 10.0.2.0/24 route table
  10.0.0.0/16  local
  0.0.0.0/0    nat-gateway in 10.0.1.0/24

Read those two tables with longest prefix match in mind and every behavior follows. Traffic to 10.0.x.x matches the /16 and stays inside. Everything else matches the default route and leaves through whichever gateway that subnet names.

Two facts that follow from the theory rather than from documentation. A NAT gateway must live in a public subnet, because it needs its own path to the internet in order to be the exit for others. And a host in a private subnet still needs a public address somewhere in the chain, which is the NAT gateway's, so its outbound traffic appears to the world as that one address, exactly like your laptop behind a home router.

When translation is the wrong tool

NAT is so common that it gets used where plain routing would be better. Three cases where it is worth pushing back:

1. Between two networks you control. If both sides use private addresses from a coordinated plan, route between them and skip translation entirely. NAT here only hides the source address from your own logs and breaks any protocol that embeds addresses in its payload. 2. Where the source address matters. Server logs, rate limits, and access rules behind a NAT device see the gateway's address instead of the client's, so every client looks like one very busy client. Solutions bolt the real address back on, such as an X-Forwarded-For header at layer 7 or the PROXY protocol, which is a strong hint the translation was in the way. 3. Where overlapping ranges made it necessary. Two sites that both chose 10.0.0.0/8 sometimes get joined with translation on both sides, which works and is miserable to debug. A renumbering plan is more work once and less work forever.

The lesson to carry into Unit 7. NAT is a layer 3 device that had to start reading layer 4 ports to do its job, which is a layering violation from Lesson 1-3 with real consequences. The next unit is about layer 4 itself, and what those ports and connections actually are.