NAT & Private IP Ranges¶

Why Private IP Ranges Exist¶

IPv4 only has ~4.3 billion addresses total — nowhere near enough for every device on every private network to have a unique public one. RFC 1918 reserves three ranges for private, internal-only use — anyone can reuse them inside their own network without conflicting with anyone else's, because they're never routed on the public internet:

Range	CIDR	Size	Common use
10.0.0.0 – 10.255.255.255	10.0.0.0/8	~16.7M addresses	Large enterprise (this wiki's examples use `10.x.x.x`)
172.16.0.0 – 172.31.255.255	172.16.0.0/12	~1M addresses	Medium networks
192.168.0.0 – 192.168.255.255	192.168.0.0/16	~65K addresses	Home/small office (most consumer routers default here)

Other Reserved Ranges Worth Knowing¶

Range	Purpose
127.0.0.0/8	Loopback (`127.0.0.1` = "this host")
169.254.0.0/16	Link-local (APIPA) — a host self-assigns from here when DHCP fails
192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24	Reserved for documentation/examples (used instead of real public IPs in guides)
100.64.0.0/10	Carrier-grade NAT (RFC 6598 shared address space) — if the WAN uplink gets an address here (common on cellular hotspots and provider-supplied uplinks), you're behind the carrier's NAT and inbound port-forwards won't work

NAT (Network Address Translation)¶

NAT translates between private addresses (used internally) and public addresses (used on the internet), letting an entire private network share one or a handful of public IPs. The router performing NAT rewrites the source (and/or destination) address as packets cross between "inside" and "outside."

Types of NAT¶

Type	Behavior	Typical use
Static NAT	One private IP always maps to one specific public IP, in both directions	Hosting an internal server that needs a consistent public address
Dynamic NAT	Private IPs draw from a pool of public IPs, first-come-first-served	Rare today — limited by needing as many public IPs as simultaneous internal hosts
PAT / NAT Overload	Many private IPs share one public IP, distinguished by port number	The default on virtually every home/office router — this is "NAT" in everyday usage

PAT (Port Address Translation) is why NAT actually scales: each internal host's connection gets mapped to the shared public IP plus a unique port, so the router can tell return traffic apart even though it all arrives at the same public address.

Basic Cisco IOS NAT Overload (PAT) Example¶

Note: NAT is a router/firewall feature. Catalyst switches — including the 3560-CX — do not support ip nat; this example is for Cisco ISR-class routers only. On a network fronted by a Netgate 6100, NAT is handled in pfSense — see NAT in pfSense below and Netgate 6100 Admin.

Cisco IOS router — global configuration mode (conf t):

interface Gi0/1
 ip address 10.0.10.1 255.255.255.0
 ip nat inside

interface Gi0/48
 ip address 203.0.113.5 255.255.255.252
 ip nat outside

ip access-list standard NAT_SOURCES
 permit 10.0.10.0 0.0.0.255

ip nat inside source list NAT_SOURCES interface Gi0/48 overload

ip nat inside / ip nat outside mark which interfaces face the private network vs. the internet
The ACL defines which internal addresses are allowed to be translated
overload is what makes this PAT (all sources share the outside interface's single IP) rather than one-to-one dynamic NAT

Verify, from privileged EXEC (Router#):

show ip nat translations
show ip nat statistics

show ip nat translations — view active translation table entries
show ip nat statistics — hits, active translations, configured inside/outside interfaces

NAT in pfSense¶

pfSense splits NAT into separate GUI pages by direction, all under Firewall → NAT. The concept types above map onto them like this:

Concept	pfSense equivalent	Where
PAT / NAT Overload (outbound sharing)	Outbound NAT	Firewall → NAT → Outbound
Static NAT (one-to-one, both directions)	1:1 NAT	Firewall → NAT → 1:1
Inbound translation to an internal host	Port Forward (destination NAT)	Firewall → NAT → Port Forward

Outbound NAT¶

This is the "whole network shares the WAN address" translation, and it works out of the box: the default Automatic mode generates rules translating every internal network (LAN, VLANs, and VPN-connected networks) to the WAN address. The other modes matter when the automatic rules aren't enough:

Automatic — default; rules generated, not editable
Hybrid — automatic rules stay, plus manual rules you add are evaluated first
Manual — only your rules exist; the automatic set is generated once as a starting point, then frozen (new VLANs added later do not get rules automatically — a common "new VLAN has no internet" cause)
Disabled — no outbound NAT at all (routed/public-IP setups only)

Switching to Hybrid or Manual is required when traffic must leave via something other than the WAN address — e.g. sending a subnet out of a tunnel interface rather than the WAN.

Port Forward¶

Inbound NAT: rewrite traffic arriving on the WAN address to an internal host — the pfSense equivalent of "exposing" a server. When creating a port forward, the default Filter rule association also creates the matching WAN firewall pass rule; without a pass rule, the translation exists but the traffic still gets blocked. Port forwards are evaluated before firewall rules on arriving traffic.

Restrict forwards to specific ports and, where possible, known source IPs — see the example in Netgate 6100 Administration.

Reflection caveat: by default, a forwarded service is not reachable from inside the LAN via the WAN address — internal clients must use the internal IP, or enable NAT Reflection (System → Advanced → Firewall & NAT), or better, use split DNS so the hostname resolves to the internal address inside the network.

Verifying¶

Active translations are tracked in the state table: Diagnostics → States, filterable by IP or port. For a port forward that isn't working, check in order: the forward's interface/ports, the associated WAN rule exists, and the internal host's own firewall/gateway.