NAT, Gateways & Private Networks

Have you ever wondered how the dozens of devices in your house (phones, laptops, smart TVs) all reach the internet through a single connection from your provider? Or why your cloud server shows two different IP addresses? The answer is a small set of networking ideas that work the same way at home, in a data center, and inside a cloud Virtual Private Cloud (VPC). This page explains private networks, Network Address Translation (NAT), default gateways, and routing tables so you understand exactly what is happening when a packet leaves your machine.

Private networks and why they exist

A private network is a group of machines that talk to each other using IP addresses that are not usable on the public internet. The internet ran out of unique public IPv4 addresses years ago, so certain ranges were reserved for private use. Any organisation can reuse these ranges internally without conflict because routers on the public internet refuse to forward them.

The reserved private IPv4 ranges (defined in RFC 1918) are:

Range	CIDR	Typical use
10.0.0.0 – 10.255.255.255	10.0.0.0/8	Large networks, cloud VPCs
172.16.0.0 – 172.31.255.255	172.16.0.0/12	Docker, medium networks
192.168.0.0 – 192.168.255.255	192.168.0.0/16	Home routers

CIDR (Classless Inter-Domain Routing) is the /number notation that says how many bits at the front of the address are fixed for the network. For example 192.168.1.0/24 means the first 24 bits are the network and the last 8 bits (0–255) are individual hosts.

When to use private addressing: for any machine that does not need to be reached directly from the internet (database servers, internal app tiers, your home laptop). When not to: a machine that must be reachable by the public — a web server’s public endpoint — needs either a public IP or something in front of it that has one.

NAT: sharing one public IP

NAT (Network Address Translation) is the trick that lets many machines with private IPs share a single public IP. When a private machine sends a packet to the internet, the gateway router rewrites the packet’s source address from the private IP to the gateway’s public IP, and remembers the mapping. When the reply comes back, the router rewrites the destination back to the original private IP and delivers it. This specific, common form is called PAT (Port Address Translation) or “NAT overload” because it uses port numbers to tell apart many simultaneous connections sharing one public IP.

This is why, at home, all your devices appear to the outside world as one IP address — your router’s public IP. The same mechanism powers a cloud NAT gateway: private servers in a VPC can download updates and call external APIs while staying unreachable from the internet.

Security note: NAT is not a firewall. It blocks unsolicited inbound connections as a side effect, but you should still run an explicit firewall (ufw or security groups). Never rely on NAT alone to protect a server.

There are two directions to keep straight:

Type	Direction	Purpose
Source NAT (SNAT/PAT)	Outbound	Many private hosts share a public IP to reach the internet
Destination NAT (DNAT / port forwarding)	Inbound	Route a public port to a specific private host

The default gateway

A gateway is the router a machine sends packets to when the destination is not on its own local network. The default gateway is the catch-all: “if I don’t know where this goes, send it here.” Without a default gateway, a machine can only talk to other machines on its own subnet.

On Ubuntu you can see the gateway with the modern ip command:

ip route show default

Output:

default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.42 metric 100

This reads: “to reach the default (everywhere else), go via 192.168.1.1 (the router) out of device eth0.” Here 192.168.1.42 is this machine’s private IP.

Routing tables and ip route

The routing table is the list of rules the kernel checks, in order of specificity, to decide where each packet goes. View the full table:

ip route

Output:

default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.42 metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.42 metric 100

The second line is a directly connected route: anything in 192.168.1.0/24 is on the local network and reachable without a gateway. The first line is the default route used for everything else.

To add a static route — for example, send traffic for the 10.10.0.0/16 network through a specific internal router at 192.168.1.254:

sudo ip route add 10.10.0.0/16 via 192.168.1.254 dev eth0

Gotcha: routes added with ip route add are lost on reboot. On Ubuntu 22.04/24.04, make them permanent in Netplan under /etc/netplan/, then apply with sudo netplan apply.

A persistent route in Netplan looks like this:

network:
  version: 2
  ethernets:
    eth0:
      routes:
        - to: "10.10.0.0/16"
          via: "192.168.1.254"

Why your VPS has a private and a public IP

When you rent a cloud server (a VPS — Virtual Private Server), it almost always has two addresses:

• A private IP (e.g. 10.0.1.5) used for traffic inside the provider’s network — talking to a database, a load balancer, or other servers in the same VPC. This traffic is fast, free, and never touches the public internet.
• A public IP (e.g. 203.0.113.20) for traffic to and from the internet. On many clouds the public IP is not even configured on the server’s network interface; the provider’s edge performs NAT to map it to your private IP.

Run ip addr on the VPS and you will typically see only the private IP, which surprises beginners:

ip -4 addr show eth0

Output:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
    inet 10.0.1.5/24 brd 10.0.1.255 scope global eth0

The public IP lives at the provider’s gateway. Confirm what the world actually sees with:

curl -s https://ifconfig.me

Output:

203.0.113.20

Use the private IP for server-to-server links (faster and not billed as internet egress) and reserve the public IP for clients on the internet.

Best practices

• Place databases and internal services on private subnets with no public IP; expose only what must be public.
• Use a NAT gateway (or your router) for outbound updates from private hosts instead of giving each host a public IP.
• Always pair NAT with an explicit firewall — NAT is not a security control.
• Prefer private IPs for traffic between servers in the same VPC to cut latency and egress cost.
• Make routing changes permanent in Netplan, not just with ip route add, so they survive reboots.
• Keep CIDR ranges non-overlapping across VPCs and on-prem networks if you ever plan to peer or VPN them together.

Related Topics

• Networking basics
• IP addresses
• Ports and protocols
• Network commands
• Firewall with UFW