NAT (Network Address Translation) is a mechanism where a router or server rewrites the IP address in packets as they pass between networks. It lets many devices with private IPs reach the internet through a single public IP.
NAT Types
| Type | Direction | Use Case |
|---|---|---|
| SNAT (Source NAT) | Inside out | Internet access from the LAN |
| DNAT (Destination NAT) | Outside in | Port forwarding |
| Masquerade | Inside out | SNAT with a dynamic IP |
| Full-cone NAT | Both directions | P2P, VoIP, gaming |
How NAT Works (example)
Device (192.168.1.5:12345) → Router → Internet (1.2.3.4:12345)
Router sees: src=192.168.1.5:12345, dst=8.8.8.8:53
Rewrites it to: src=1.2.3.4:12345, dst=8.8.8.8:53
Stores in table: 1.2.3.4:12345 ↔ 192.168.1.5:12345
Reply: src=8.8.8.8:53, dst=1.2.3.4:12345
Router maps back: 1.2.3.4:12345 → 192.168.1.5:12345Configuring NAT in iptables (Linux router)
# Enable IP forwarding
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
# Permanently: /etc/sysctl.conf → net.ipv4.ip_forward=1
# MASQUERADE — NAT for outbound internet access (eth0 = WAN)
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# DNAT — port forwarding (80 → internal server)
sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.1.10:80
# Save the rules
sudo netfilter-persistent saveWhen NAT on a VPS Gets in the Way
Some hosting providers put VPS instances behind a shared NAT address:
- Mail server — the PTR record does not match the IP, so messages get rejected
- VPN server — IPSec/WireGuard require a public IP without NAT
- Game server — players cannot connect directly
- DDoS protection — rules are harder to configure on a shared IP
Diagnosing common NAT errors
DNAT is configured, but the port is still unreachable from outside — almost always the cause is a missing MASQUERADE/SNAT rule for the return traffic, or a firewall (UFW/firewalld) blocking the packet after address translation already happened.
sudo iptables -t nat -L PREROUTING -n
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 to:192.168.1.10:80
# But FORWARD blocks the traffic:
sudo iptables -L FORWARD -n
Chain FORWARD (policy DROP)DNAT in the nat table changes the destination address, but the packet still passes through the FORWARD chain in the filter table. If its default policy is DROP, you must explicitly allow the forwarded traffic: iptables -A FORWARD -p tcp -d 192.168.1.10 --dport 80 -j ACCEPT.
A server behind NAT sees the same source IP for every client — a typical symptom of carrier-grade NAT (CGNAT) at mobile carriers or cheap hosts: hundreds of clients are hidden behind one public address.
# The web server logs show one IP making thousands of requests
203.0.113.7 - - "GET / HTTP/1.1" 200
203.0.113.7 - - "GET / HTTP/1.1" 200
203.0.113.7 - - "GET / HTTP/1.1" 200Rate-limiting that IP would hit every user behind that CGNAT at once — you need finer signals (User-Agent, cookies, behavioral metrics) instead of just the IP.
NAT types: an extended comparison
| Type | Port symmetry | P2P/VoIP issues | Typical use |
|---|---|---|---|
| Full-cone NAT | Same port for every destination | Minimal | Home routers, VPN servers |
| Restricted cone NAT | One port, but filtered by sender IP | Moderate, needs STUN | Corporate firewalls |
| Port-restricted cone NAT | One port, filtered by IP and port | Noticeable, often needs TURN | Stricter firewalls |
| Symmetric NAT | A new port for every destination | Severe, P2P is nearly impossible without TURN | Carrier CGNAT, public Wi-Fi |
When NAT simply does not fit
- You need inbound VoIP/SIP traffic with no middlebox — the SIP protocol carries the IP address inside the packet body, and NAT does not rewrite it, which breaks the return path; you need either an ALG on the router or a public IP.
- An IPSec server is deployed for site-to-site VPN — most IPSec implementations traverse NAT poorly without NAT-T (NAT Traversal), and some modes (AH) are outright incompatible with NAT.
- The company must give clients a stable outbound IP for whitelisting on the partner's side — behind NAT the outbound IP is shared with other hosting clients, and the partner cannot tell the traffic apart.
Verifying the result
- Confirm IP forwarding is enabled:
cat /proc/sys/net/ipv4/ip_forwardmust return1. - Check the translation table live:
sudo conntrack -L | grep 192.168.1.10must show active sessions going through NAT. - From an external host, test the forwarded port:
curl -v http://YOUR_PUBLIC_IP:80must connect to the internal server. - Confirm the rules survive a reboot:
sudo netfilter-persistent save && sudo reboot, then repeat the check.
NAT is closely tied to IPv4 addressing and subnet masks — see the article on IPv4 and on CIDR calculation, and for configuring the routing itself see the article on ip route.
Frequently asked questions
Is it a good idea to just block an address once it turns out to belong to a carrier's carrier-grade NAT?
Blocking that address outright is a bad idea: a single carrier-grade NAT address hides hundreds of different carrier clients, and the block would hit all of them at once, including ordinary users. Telling an abuser apart from neighbors sharing the same NAT needs finer request signals — browser headers, cookies, behavioral metrics — rather than just the connection's source address.
Does NAT get in the way of ordinary outbound connections like web browsing, or only inbound ones from outside?
No, outbound connections a device starts from inside the network pass through NAT transparently via SNAT or Masquerade, with no extra setup. Trouble shows up only when something outside needs to reach you first — an inbound VoIP call, a VPN peer, or a player connecting directly — which is why those scenarios need a public address without NAT.
Why can a SIP VoIP call connect but end up with no audio even though the signaling gets through NAT?
The cause sits inside the SIP protocol: it carries the device address for the voice stream inside the packet body, not only in the network headers NAT rewrites. The translator changes the header address but leaves that part of the message untouched, so signaling gets through while the media stream tries to reach an address unreachable from outside, leaving silence.
If a VPS already has a dedicated public IP instead of shared NAT, does that mean no NAT configuration is ever needed on that server?
No, a dedicated public address only removes shared-NAT headaches like a mismatched PTR record or blocked game and VoIP ports. The server itself may still need its own translation rules — for routing traffic to containers, say, or to a local network behind that server, which can still sit behind NAT configured by its owner.