LAN, WAN, DMZ & NAT in depth: Network Zones, Their Ports, and How NAT Really Works

Every network has ZONES with different trust levels, the gear connecting them has various PORTS for data versus administration, and NAT is the machinery that lets traffic cross between the trusted inside and the untrusted outside. This doc covers all three.

Part 1: The Zones (Trust Boundaries)

flowchart LR
  NET[Internet / WAN] --> FW[Firewall / Router]
  FW --> LAN[LAN - trusted devices]
  FW --> DMZ[DMZ - public servers]
  FW --> MGMT[Management - isolated]
  DMZ -. denied .-> LAN

LAN (Local Area Network): Your internal, trusted side uses private RFC1918 addresses (10.x, 172.16-31.x, 192.168.x). Laptops, phones, servers live here. The firewall trusts it most.
WAN (Wide Area Network): The outside — the internet, reached through your ISP link. UNtrusted. Your single public IP lives on the WAN interface. Everything arriving from the WAN is guilty until proven otherwise.
DMZ (Demilitarized Zone): A semi-trusted middle zone for things that must be reachable from the internet but should not freely reach your LAN. The logic: if an internet-facing box gets compromised, the attacker is trapped in the DMZ, not loose on your internal network. Implemented as a separate firewall interface/zone with directional policies: WAN→DMZ allow specific services (443 to the web server), DMZ→LAN DENY or very tightly limited, LAN→DMZ allow. CRUCIAL beginner trap: the "DMZ host" checkbox on cheap home routers is NOT a real DMZ — it just forwards ALL unsolicited inbound traffic to one internal machine (an "exposed host") with no protection. That's the opposite of security; a true DMZ is a firewalled, isolated segment.
Management Zone: A separate network/interface for administering the gear itself — switch/router/firewall admin, plus server lights-out management (IPMI, Dell iDRAC, HPE iLO). OUT-OF-BAND management means a dedicated, isolated network for this, so (a) you can still reach a device to fix it even when the data network is broken, and (b) admin interfaces are never exposed to data-plane traffic or the internet. Rule: Management interfaces must NEVER be reachable from the WAN. A management VLAN is the homelab version.

Part 2: The Ports on Network Gear

Enterprise routers/switches/firewalls have several kinds of physical port, and confusing them is a classic beginner stumble:

DATA ports: RJ45 copper or SFP/SFP+ fiber cages that carry actual user traffic. On a router, one is designated WAN, the rest LAN.
Management Port: A dedicated Ethernet port often labeled MGMT, wired to the out-of-band management network, kept separate from data.
Console Port: A SERIAL port for direct local configuration — not for data. This is the one people don't expect.

Part 3: Console Cables vs Ethernet (Two Totally Different Jobs)

Ethernet is IN-BAND: It carries data and also management-over-the-network (SSH/HTTPS to the device's IP). But it only works once the device already has a working IP configuration and the network is up. No IP, no ethernet management.
Console (Serial) is OUT-OF-BAND: A direct cable from your laptop to the device’s console port that works even on a factory-fresh device with no config or one that won't boot. You see boot messages and the raw CLI directly, independent of the network.

The Cables:

Classic Cisco light-blue "rollover" cable (RJ45 on the device end, DB9 serial on the old-PC end) — the rollover pinout REVERSES pin order (1↔8, 2↔7...), which is NOT the same as an Ethernet straight-through or crossover cable. Don't mix them up.
Modern gear uses a USB console port (mini-USB or USB-C) with a serial-over-USB chip; laptops without serial ports use a USB-to-serial adapter. Every network engineer carries one.

How You Connect:

A terminal emulator (PuTTY on Windows, screen or minicom on Linux/mac) set to the device's serial parameters — commonly 9600 baud, 8 data bits, No parity, 1 stop bit ("9600 8N1"), no flow control. Wrong baud = garbage characters on screen (the classic "it's all gibberish" symptom).

Why It Matters:

Initial setup of a device with no IP.
Recovery when you locked yourself out over SSH with a bad ACL/config.
Password recovery via the bootloader (rommon).
Watching boot/POST diagnostics when a device won't come up. Ethernet can't do any of these because they all happen before or without a working network.

Part 4: NAT — Really in Depth (The Centerpiece)

What NAT Does:

NAT rewrites the IP addresses (and usually ports) in packet headers as they cross between zones — typically LAN↔WAN. It remembers each mapping so return traffic gets translated back to the right inside host. Born from IPv4 address exhaustion: it lets many private hosts share one scarce public address.

The Translation Table:

The router keeps a stateful table for each outbound flow, recording inside-source-ip:port, the outside-source-ip:port it rewrote it to, and the destination. Replies arriving from the internet are matched against this table and translated back. No table entry = no idea which inside host wants the packet.

Flavors:

Static / One-to-One NAT: One private address maps to one public address, all ports, permanently.
PAT / NAPT / "NAT Overload" / Linux "masquerade": Many inside hosts share one public IP, demultiplexed by rewriting the source port. The router picks a unique public source port per flow so replies are unambiguous.

SNAT vs DNAT:

SNAT (Source NAT): Rewrites the source (outbound, hides the inside — everyday home case).
DNAT (Destination NAT): Rewrites the destination (inbound — this is port forwarding). For the firewall-config side of SNAT/DNAT and virtual IPs, see NAT on real firewalls.

NAT "Types":

Full Cone: After an inside host sends out, any external host can send back to that mapped public port. Most permissive.
Address-Restricted Cone: An external host can reply only if the inside host had previously sent to that host's IP (any port).
Port-Restricted Cone: Reply allowed only from the exact IP and port the inside host sent to.
Symmetric NAT: The router assigns a different public source port for each distinct destination, even when the inside host reuses one source port. Breaks most peer-to-peer hole-punching.

NAT Traversal:

STUN: A public helper server that tells a host what its own public IP:port mapping looks like from the outside.
TURN: A relay server that forwards traffic between peers when direct connection is impossible (e.g., symmetric NAT on both ends).
ICE: The framework (used by WebRTC) that gathers candidate paths — direct, STUN-discovered, TURN-relayed — tries them, and picks the best one.
UPnP IGD / NAT-PMP / PCP: Protocols by which a trusted inside device asks the router to open a port mapping automatically. This is why some games "just work" without manual port forwarding — and a genuine security concern, because malware on the LAN can use the same protocols to open holes. Many people disable UPnP for exactly this reason.

Hairpinning (NAT Loopback):

An inside host trying to reach an inside server by the server’s public IP. The packet goes to the router and has to "u-turn" back inside. Many cheap routers don’t support it — the signature symptom is "my website or game server works from cellular data but not from my home WiFi." Fixes: a router that supports NAT reflection/hairpinning, or better, split-horizon DNS so the internal name resolves to the internal IP and skips NAT entirely.

NAT and State / Timeouts:

NAT is inherently stateful. TCP has explicit start and end (SYN/FIN), so the router can age entries cleanly. UDP relies on idle timeouts to expire mappings, which is why long-idle UDP sessions silently drop and need periodic keepalives.

The Downsides, and Why IPv6 Wants to Retire NAT:

NAT breaks the internet’s original end-to-end model (where any host could address any host directly), complicates every P2P and inbound scenario, and hides internal structure (a privacy upside, a troubleshooting downside). Stacking NAT — an ISP running CGNAT on top of your home NAT, i.e. double NAT — makes inbound essentially impossible.

IPv6 removes the scarcity that NAT existed to solve: with a public address available for every device, security comes from a stateful firewall (default-deny inbound) instead of translation. The important nuance most people get wrong: NAT was never actually a security feature. The protection people credit to NAT comes from the stateful, default-deny filtering that NAT happens to imply — and a plain IPv6 firewall provides that same protection without any translation. (NPTv6, a NAT-like scheme for IPv6, exists but is discouraged.)

Conclusion:

A packet from a LAN host to the internet leaves the trusted zone, gets SNAT'd on the WAN interface, and its reply is matched back through the translation table. You configured all this either over an in-band SSH session or, when that wasn't possible, a serial console cable; and a public service you host lives in the DMZ so if it's breached, the LAN stays safe.

LAN, WAN, DMZ & NAT in depth: network zones, their ports, and how NAT really works