Skip to content

NAT and Port Forwarding

Overview

Explain SNAT, DNAT, and PAT, read Linux NAT rules and conntrack, map the same ideas to cloud NAT gateways, and diagnose common translation failures.

NAT (Network Address Translation) rewrites addresses (and often ports) at a boundary. Home routers, cloud NAT gateways, and port forwarding all depend on it. NAT stretches IPv4, hides private hosts, and complicates debugging — logs show the translator’s IP, and some protocols need helpers.

This is the first tutorial in Module 11 — NAT & Firewalls. Complete HTTP, HTTPS, and the Application Layer first; you should already be comfortable with Routing Fundamentals. Diagrams use Excalidraw only.

This is a core tutorial in Module 11 · NAT & Firewalls of the REBASH Academy Networking for Cloud & DevOps Engineers series — written for Cloud, DevOps, Platform, and SRE engineers.

Prerequisites

Required

  • Cloud account context for NAT gateway discussion (AWS/GCP/Azure)

Learning Objectives

By the end of this tutorial, you will be able to:

  • Distinguish SNAT, DNAT, and PAT (NAPT)
  • Explain why conntrack is required for NAT
  • Sketch iptables/nftables NAT hooks (PREROUTING / POSTROUTING)
  • Describe cloud NAT gateway placement (private → NAT → internet)
  • Design a simple port-forward (DNAT) pattern
  • Debug translation with conntrack and packet capture basics

Architecture

Private hosts reach the internet via SNAT/PAT; published services use DNAT/port forward.

NAT and port forwarding

Theory

Why NAT exists

RFC 1918 private ranges are reused behind translators. Many orgs share 10.0.0.0/8 safely because NAT isolates them. NAT is not a full firewall — pair it with explicit filter policy.

SNAT, DNAT, PAT

Type Direction What changes Example
SNAT Outbound Source IP (often port) 10.0.1.20 → NAT public IP
DNAT Inbound Destination IP/port EIP:443 → 10.0.1.50:8443
PAT/NAPT Many:1 Port multiplexing Whole LAN shares one WAN IP

MASQUERADE is dynamic SNAT using the egress interface address:

# Example only — do not paste on a production jump host
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Conntrack

The kernel stores flow state so return packets are reverse-translated. Inspect:

sudo conntrack -L 2>/dev/null | head -20 || sudo head -5 /proc/net/nf_conntrack

If nf_conntrack_max is exhausted, new flows fail — a classic busy NAT-instance outage.

Linux NAT hooks

In the nat table:

  • PREROUTING — DNAT before routing
  • POSTROUTING — SNAT after routing

Forwarding must be on:

sysctl net.ipv4.ip_forward
# Lab only: sudo sysctl -w net.ipv4.ip_forward=1

Example patterns (lab router):

# Outbound masquerade for a private CIDR
# iptables -t nat -A POSTROUTING -s 10.0.11.0/24 -o eth0 -j MASQUERADE

# Port forward 8080 → internal :80
# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 \
#   -j DNAT --to-destination 10.0.11.50:80

nftables equivalent shape: type nat hook prerouting / postrouting with dnat / masquerade.

Cloud NAT gateways

Typical VPC pattern:

  1. NAT gateway (or Cloud NAT) in a public subnet with a public IP
  2. Private subnet default route 0.0.0.0/0 → NAT
  3. Outbound internet works; inbound initiation from the internet does not

AWS: NAT Gateway + Elastic IP, prefer one per AZ. GCP: Cloud NAT. Azure: NAT Gateway. Public-subnet instances with public IPs use the Internet Gateway path — no SNAT required for their own public address.

What breaks behind NAT

Protocols that embed IP/port in payloads (classic FTP, some SIP/VoIP) may need helpers or redesign. Prefer application designs that work through NAT (HTTPS, TURN, etc.).

Hands-on Lab

Focus: practise the core workflow for NAT and Port Forwarding

mkdir -p ~/rebash-networking/module-11
cd ~/rebash-networking/module-11

sudo apt-get update
sudo apt-get install -y iptables nftables conntrack iproute2

Lab safety

NAT and forwarding rules can break SSH and outbound access. Prefer a disposable VM or cloud lab. Know how to recover via console.

Step 1 – Observe current NAT / filter state

sudo iptables -t nat -L -n -v 2>/dev/null | head -40
sudo nft list ruleset 2>/dev/null | head -40
sysctl net.ipv4.ip_forward

Step 2 – Conntrack view

curl -s -o /dev/null https://example.com || true
sudo conntrack -L 2>/dev/null | head -15 || echo "conntrack tool/table not available — note for your distro"

Step 3 – Mental model: SNAT path

Sketch on paper (or comments in a lab notes file):

Private 10.0.1.20:ephemeral → NAT → Public EIP:ephemeral → Internet :443
Return path reverse-mapped by conntrack → 10.0.1.20

Step 4 – Mental model: DNAT path

Client → EIP:8080 → DNAT → 10.0.1.50:80 → response SNAT/conntrack reverse

Step 5 – Cloud mapping checklist

Answer for your preferred cloud:

  1. Where does the NAT resource live (subnet / AZ)?
  2. Which route table points at it?
  3. What public IP do private hosts appear as externally?

Step 6 – Failure modes (read-only checks)

sysctl net.netfilter.nf_conntrack_max 2>/dev/null || true
sysctl net.netfilter.nf_conntrack_count 2>/dev/null || true

High count vs max is a capacity signal on self-managed NAT hosts.

Validation

  • Lab commands run under ~/rebash-networking/module-11/
  • You can explain each Theory section in your own words
  • You used modern tooling where it applies to this topic
  • You can describe one production failure mode for this topic

Code Walkthrough

Production practice for NAT and Port Forwarding always combines:

  1. Inspect before you change (status, plan, logs, dry-run)
  2. Prefer reversible, documented changes (Git, IaC, drop-ins, version pins)
  3. Capture evidence (command output, pipeline logs) for handovers
  4. Prefer current tools and APIs over legacy shortcuts
  5. Least privilege — escalate credentials only when required

Keep runbooks short enough to follow under pressure. Automate checks; keep humans for judgement.

Security Considerations

  • Treat credentials and tokens for networking as privileged — never commit them
  • Prefer short-lived auth (OIDC, roles, SSO) over long-lived keys
  • Validate blast radius before apply/deploy/delete operations
  • Restrict who can approve production changes
  • Collect audit logs; limit who can read sensitive traces

Common Mistakes

Skipping fundamentals for NAT and Port Forwarding

Validate assumptions against the Theory section and official docs before changing production.

Treating lab defaults as production-ready for NAT and Port Forwarding

Lab shortcuts (open security groups, admin roles, skip approvals) must not ship unchanged.

Changing production without a rollback path

Always know how to revert (previous artefact, prior release, state rollback, DNS failback).

Best Practices

  • Encode NAT and Port Forwarding changes as code and review them in pull requests
  • Pin versions (images, modules, actions, provider plugins)
  • Separate environments with clear promotion gates
  • Alert on symptoms with runbooks attached
  • Destroy lab resources; tag everything with owner and expiry where possible

Troubleshooting

Symptom Likely cause What to do
Private host no internet Missing default via NAT / IGW mix-up Check route tables; confirm NAT healthy
Port forward fails DNAT without FORWARD allow Fix filter FORWARD; check listen address
One-way traffic Asymmetric routing / missing reverse path Align routes; check conntrack entries
Random new-flow failures Conntrack table full Raise max; reduce churn; prefer managed NAT
Wrong source IP in logs Expected SNAT Log X-Forwarded-For / PROXY protocol at L7

Summary

  • SNAT hides private sources; DNAT publishes destinations; PAT multiplexes ports
  • Conntrack makes NAT bidirectional for a flow
  • Cloud NAT gateways are the managed form of outbound SNAT for private subnets
  • Port forwarding is DNAT plus allow rules on the data path

Interview Questions

  1. How does NAT and Port Forwarding show up when operating Cloud or production platforms?
  2. What would you check first if this area misbehaves in production?
  3. Which modern tools or APIs replace older equivalents here?
  4. What security control should accompany this capability?
  5. How would you automate verification of this topic in CI?

Sample answer — question 2

Start with blast radius and recent changes, gather evidence (logs, status, plan/diff), then fix forward with a known rollback path — not guesswork.

References