NAT, Firewalls & Private Networks

Learning goals

By the end of this chapter you should be able to:

• Explain NAT in plain English and why home Wi‑Fi shares one public IP
• Describe private IP ranges and VPC isolation in cloud networks
• Compare firewall DROP vs REJECT and tie it to TCP vs UDP behavior
• Reason about security groups vs NACLs (conceptual) and inbound/outbound rules

Your laptop, your company’s servers, and every cloud VPC live behind boundaries that hide internal addresses and filter what may cross. This is the glue between “I opened a socket” and “why did it hang forever?”

Plain English: public vs private addresses

Not every IP address means “on the whole Internet.” RFC 1918 private ranges (simplified):

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

These are reused in millions of homes and VPCs. Routers on the public Internet do not forward them as global destinations — they are local-only addressing inside a network.

A VPC (Virtual Private Cloud) is your cloud provider’s isolated virtual network: subnets, route tables, private IPs for VMs, optional public IPs and gateways.

Precise term: public IP is globally routable (with provider assignment). Private IP is meaningful only inside that network (or connected peers via VPN/peering).

NAT: many devices, one public face

Network Address Translation (NAT) rewrites addresses on packets crossing a boundary.

Classic home router NAT:

1. Your phone (192.168.1.50) opens TCP to 203.0.113.10:443.
2. Router replaces source with router’s public IP + an ephemeral source port.
3. Return packets hit router; it maps port back to your phone.

From the server’s view, the whole household looks like one IP. From your phone’s view, you reach the world normally.

SNAT (Source NAT) — hide internal source. DNAT (Destination NAT) — publish internal service on a public IP (port forwarding: public 443 → internal 192.168.1.10:8443).

Cloud NAT Gateway lets private-subnet instances reach the Internet for updates without giving each instance a public IP.

Interview hook: NAT is stateful — the translator remembers (internal IP:port) ↔ (public IP:port) mappings. Idle timeouts drop state; long-idle TCP may need keepalive.

Firewalls and security groups: allow vs deny

A firewall (host iptables, cloud security group, network ACL) applies rules to packets:

• Allow traffic matching port/protocol/source
• Implicit or explicit deny everything else

Security group (AWS-style, simplified): stateful — if you allow inbound TCP 443, return traffic for established flows is typically allowed automatically.

NACL (network ACL): subnet-level, often stateless — you must allow both directions explicitly.

Rules are evaluated in priority order until a match. Default deny is the safe posture: only open what you need.

DROP vs REJECT: silence vs “no”

From the HTTPS foundations guide — worth repeating with production context:

Why DROP exists: hide that a host/port exists (stealth), reduce scan noise. Downside: legitimate clients wait — bad for UX debugging.

Ops tip: internal dev environments often REJECT for clearer errors; public edge sometimes DROP on unused ports.

Tie to private VPC IP: from your laptop on the Internet, connecting to 10.0.1.5 in someone’s AWS VPC — packets may never arrive (non-routable) or hit DROP at border. Your TCP client times out; UDP looks like it sent.

VPC layout (conceptual sketch)

Typical three-tier cloud pattern:

Internet
   │
 [Internet Gateway]
   │
 Public subnet  — LB, NAT gateway (public IP)
   │
 Private subnet — app servers (private IP only)
   │
 Private subnet — databases (no direct Internet route)

• LB in public subnet accepts HTTPS from world; forwards to apps in private subnet.
• DB security group allows only app SG on port 5432 — not 0.0.0.0/0.

Bastion / SSM: admins reach private instances via jump host or session manager, not by exposing SSH to the world.

Inbound vs outbound thinking

Junior mistake: “I opened port 443 inbound on the server” but corporate egress firewall blocks outbound 443 from laptop.

Both directions matter:

• Inbound rule on server — who may connect to me?
• Outbound rule on client — may I leave?
• Return path — stateful firewalls track connections; stateless need symmetric rules.

DNS egress: app in private subnet needs UDP/TCP 53 to resolver or it cannot resolve names.

Peering, VPN, and hybrid

VPC peering / PrivateLink: connect two private networks without public Internet.

Site-to-site VPN: on-prem datacenter ↔ cloud VPC — private IPs routable across tunnel.

Same private IP space cannot overlap between peered VPCs without NAT tricks — planning matters.

Common mistakes

1. Security group open to 0.0.0.0/0 on SSH (22) — brute-force magnet; use bastion or SSM.
2. App listens on localhost only inside container — LB health checks fail from outside container network namespace.
3. Assuming ping works means HTTPS works — ICMP often blocked separately (HTTPS guide note).
4. Forgetting ephemeral ports for outbound NAT — restrictive NACL blocks return traffic.
5. Confusing “private subnet” with “secure” — still need SG rules; private means no direct Internet route, not automatic auth.

Practice checkpoint

1. Why does your home network show one public IP to websites? Answer: router NAT translates many private devices to one public source address (with port mapping).

2. Can the Internet route to 10.0.0.5 in a random company’s VPC? Answer: no — private range is not globally routable; you’d need VPN/peering into that VPC.

3. Firewall DROP on TCP 443 — client symptom? Answer: connection hangs then times out (no RST).

4. Stateful security group allows inbound 443 — must you add outbound allow for response? Answer: typically no — stateful tracking allows return packets for established connection.

5. SNAT vs DNAT — which hides internal clients going out? Answer: SNAT (source NAT); DNAT publishes internal server to outside.

Interview angles

• NAT purpose: conserve IPv4, hide topology, enable private RFC1918 reuse.
• DROP vs REJECT with TCP timeout vs fast fail — link to debugging “hang vs immediate error.”
• VPC: isolation, subnets, IGW vs NAT gateway, least-privilege SG rules.
• Defense in depth: SG + NACL + WAF + app auth — different layers.
• Why DB has no public IP: shrink attack surface; access only from app tier.

Next: /networking/learn/reliability/timeouts-retries-idempotency/