Networking › Module 5 › Lesson 1
NAT, Firewalls & Routers
How NAT hides internal hosts and how firewalls filter traffic
Opening
One public IP, many private hosts — and a policy at the door
Your laptop, phone, and printer almost never hold a public IPv4 address. They sit on RFC1918 space (10.x, 172.16–31.x, 192.168.x) behind a router that rewrites packets as they leave. That rewrite is NAT — usually PAT/NAPT, where many internal sockets share one public IP by stealing uniqueness from port numbers. A firewall is a different job: it decides which packets are allowed. Consumer boxes do both, so beginners treat "the router" as one magic. Defenders split them: address translation hides topology; policy filters traffic. Disable neither to "make an app work." This lesson is mechanism on a network you own — your VM, WSL, or home lab — not a hunt across someone else's LAN.
1. PAT/NAPT: many private hosts, one public IP
Classic one-to-one NAT maps a single private IP to a single public IP. Home and office IPv4 almost never works that way — there are not enough public addresses. PAT (Port Address Translation), also called NAPT (Network Address Port Translation) or "NAT overload," maps many internal IP:port pairs onto one public IP by assigning a unique public port for each flow. Mechanism, outbound: host 192.168.1.50 opens TCP from source port 54321 toward 93.184.216.34:443. The NAT device rewrites the source to its public IP, say 203.0.113.8, and an ephemeral public port, say 41200. It stores a translation: 192.168.1.50:54321 ↔ 203.0.113.8:41200 (TCP), plus idle timers. The internet server replies to 203.0.113.8:41200. The NAT looks up the table, rewrites the destination back to 192.168.1.50:54321, and forwards on the LAN. That is why a packet capture on the WAN side never shows 192.168.1.50 — the private address is not a valid internet source. Mechanism, inbound: an unsolicited SYN to 203.0.113.8:41200 has no matching table entry (or the entry expired). The NAT drops it. Casual port scans from the internet therefore see "filtered" or silence on most ports — not because NAT is a firewall, but because there is no mapping. NAT is address rewriting. It hides internal topology from casual discovery. It does not inspect payloads, log intent, or replace default-deny policy.
2. Port forwarding is an explicit hole — then firewalls
Port forwarding (DNAT) is a static inbound mapping you create on purpose: public IP:443 → 192.168.1.10:443. Every forwarded port is a published service. If that internal host is unpatched, the hole is an attack path you chose. "I forwarded 3389 so I can RDP from the café" is a classic self-inflicted exposure; a VPN into a host you administer is the usual better shape. A firewall evaluates packets against rules. Default deny inbound means: unless a rule allows this flow, drop it. That is the sane baseline for both network and host firewalls. A simple ACL (access control list) is often stateless: each packet is judged alone — source, destination, protocol, port — with no memory of a handshake. A stateful firewall tracks connections. An outbound TCP handshake creates an allowed return path for that flow; a random inbound SYN to a high port dies even if an ACL would have matched "any any" on the way back. UDP and ICMP get analogous state or timeout entries. Stateful is why "I allowed outbound HTTPS" still lets the response in without you writing a matching inbound permit. Host firewall vs network firewall: ufw, firewalld, iptables/nftables, or Windows Defender Firewall sit on the endpoint. They still matter when the laptop leaves the office LAN — café Wi-Fi has no corporate edge. A network firewall sits on the router, a dedicated appliance, or a cloud security group. Edge policy cannot see a bind on 0.0.0.0:3000 once the laptop is on a foreign network. Read both: ip route shows the gateway (the NAT box you will blame first); ss -tuln shows what this host is offering if a packet arrives.
3. Wrong vs right: disable the firewall so it works
Worked failure mode — treating a deny as a nuisance instead of a signal. Commands below inventory YOUR VM, WSL, or home router admin — they do not disable policy and they do not scan other networks.
Wrong
A game, printer, or SSH session fails, so you turn off ufw, Windows Firewall, or the router SPI checkbox "just for a minute." Or you add allow any any inbound. Or you port-forward 22/3389 to a desktop and call NAT "security." Or you nmap the café /24 to "see what the firewall is hiding." Unauthorized scanning is still unauthorized; an open host is not a lab.
Right
Leave default deny in place. Read the deny: which direction, port, and program? Add the narrowest allow (that app, that port, that interface). Treat port forwarding as publishing a service — patch it, restrict source IPs if you can, prefer a VPN. On your machine, ip route names the gateway; ss -tuln names listeners; sudo ufw status (if installed) is read-only. Do not disable the firewall to prove a theory.
4. Practical: route, listeners, firewall status — read only
Run these on your Linux VM, WSL, or a machine you administer. You are reading your own default route, your own sockets, and optionally your own host-firewall status. Do not ufw disable, do not iptables -F, do not flip Windows Firewall off. If ufw is missing, that is information — not an order to install and then disable it.
Command guide
ip route, ss, optional ufw status — YOUR machine only
Default route = how packets leave (often your NAT/gateway)
Command — copy this
ip route
Look for: default via <gateway-ip> dev <iface> That gateway is the box doing PAT/NAPT for this LAN — if it is YOUR LAN.
What is this host offering if a packet arrives?
Command — copy this
ss -tuln
127.0.0.1:PORT → local processes only (NAT/internet never reach it) 0.0.0.0:PORT → all IPv4 interfaces — host firewall still matters
Optional command
Host firewall status (optional; READ — do not disable)
Command — copy this
command -v ufw >/dev/null && sudo ufw status verbose || echo 'ufw not installed; skip'
Windows (PowerShell, your PC): Get-NetFirewallProfile | Format-Table Name, Enabled
NEVER: sudo ufw disable NEVER: sudo iptables -F / Set-NetFirewallProfile -Enabled False NEVER: scan or port-forward into a network you do not own NAT hides private IPs. A firewall is policy. You need both pictures.
Mission: name NAT vs firewall on your own path
On your VM or WSL, run ip route and write the default via address (your gateway). Run ss -tuln and note one LISTEN bind (127.0.0.1 vs 0.0.0.0). In one sentence, explain why outbound web works through PAT while unsolicited inbound to your public IP usually dies without port forwarding. If ufw exists, run sudo ufw status only — do not disable anything. Own machine / own VM / WSL only.
Stuck? Ask Cyberlium AI Mentor
If PAT vs "the firewall blocked it" still blur, ask Cyberlium AI Mentor for a hint — not a command that turns filtering off. Try: "Hint only: outbound HTTPS works from 192.168.1.50 but inbound SSH to my public IP fails — is that NAT table, firewall policy, or both?"
You can now separate PAT/NAPT (many private hosts, one public IP, inbound drop unless a mapping exists) from firewall policy (default deny, stateful vs simple ACL, host vs network). You know why "disable the firewall" is the classic wrong fix. Next — Network Troubleshooting Steps — a layered checklist from link up to application, so a broken connection is isolated instead of guessed.
Knowledge Check
APPLY: Ten laptops on 192.168.1.0/24 browse HTTPS through one home public IP. A WAN capture never shows 192.168.1.50. What mechanism is doing that, and what makes each flow unique?
Multiple choice
Knowledge Check
APPLY: A teammate cannot SSH from the internet to a lab VM behind home NAT. Outbound curl from the VM works. They want to disable ufw on the VM "to test." What is the better first model?
Multiple choice
Knowledge Check
APPLY: True or False: A stateful firewall allowing outbound TCP/443 will typically allow the matching return packets without you writing a separate inbound "permit any any" rule, unlike a purely stateless ACL that judges each packet alone.
True or False