Understanding NAT as a Backend Engineer

2
calendar_today agoschedule4 min read
— Originally published at softwareconcepts.hashnode.dev

After learning about TCP, HTTP, TLS, and encryption, the next networking concept I wanted to understand was NAT.

I had always known that my laptop gets a private IP address from the router.

Something like:

192.168.1.2

But websites somehow see a completely different IP address.

That made me wonder:

How does my laptop communicate with a server on the internet if its IP address isn't even publicly reachable?

The answer is NAT.

And once I understood it, routers became much less mysterious.


What is NAT?

NAT stands for Network Address Translation.

It is the process of translating:

IP Address → IP Address

or

IP Address + Port → IP Address + Port

The original goal of NAT was to solve the limited number of IPv4 addresses.

But over time it became useful for much more than that.

Today NAT is commonly used for:

  • Private to Public IP translation
  • Port Forwarding
  • Layer 4 Load Balancing

The Problem NAT Solves

Imagine the following setup:

Client:

192.168.1.2

Router:

Private IP: 192.168.1.1
Public IP: 44.11.5.17

Server:

44.12.1.9:8080

The client wants to send:

GET /

to the server.

The packet initially looks something like:

192.168.1.2:8992 → 44.12.1.9:8080

At first glance this seems fine.

But there is a problem.

The address:

192.168.1.2

is a private IP address.

The public internet cannot route packets back to it.

So even if the server receives the request, it has no valid route to send a response back.

This is where NAT enters the picture.


The Default Gateway

One thing that finally clicked for me was the purpose of the default gateway.

Whenever the client doesn't know how to reach a destination, it sends the packet to its gateway.

Usually that's the router.

The packet is sent using the router's MAC address.

The router sees:

Destination IP = 44.12.1.9

and understands:

This packet isn't for me.
I should forward it to the internet.

But before forwarding it, the router performs NAT.


How NAT Actually Works

The router replaces the private source address with its own public address.

The packet changes from:

192.168.1.2:8992 → 44.12.1.9:8080

to:

44.11.5.17:8992 → 44.12.1.9:8080

Now the packet can travel across the internet.

From the server's perspective, the request appears to come from:

44.11.5.17

which is the router's public IP.

The server has no idea the original request came from:

192.168.1.2

inside a private network.


The NAT Mapping Table

The interesting part is that the router keeps track of these translations.

It creates an internal mapping like:

192.168.1.2:8992
        ↓
44.11.5.17:8992
        ↓
44.12.1.9:8080

This mapping gets stored in the NAT table.

Now when the server responds:

44.12.1.9:8080 → 44.11.5.17:8992

the router checks its table and finds:

44.11.5.17:8992
belongs to
192.168.1.2:8992

It rewrites the packet again and sends it back to the client.

The client receives the response and the communication continues normally.

This entire translation process happens constantly without us noticing.


Why NAT Was So Important

IPv4 provides roughly:

4.3 Billion Addresses

which sounded like a lot decades ago.

Today it clearly isn't enough.

Without NAT, every device would need its own public IPv4 address.

Instead, one public IP can represent an entire home or office network.

Your:

  • Laptop
  • Phone
  • TV
  • Gaming Console

can all share the same public address.

This dramatically slowed down IPv4 exhaustion.

Today IPv6 offers an enormous address space, but NAT is still everywhere because of its additional uses.


NAT and TCP Connections

While learning NAT, I realized why ports are so important.

Suppose two devices both connect to the same server:

192.168.1.2:8992
192.168.1.3:8992

The router can maintain separate mappings for each connection.

This allows many devices behind a single public IP to communicate simultaneously.

Without ports, this would be much harder to manage.

This is another reason understanding TCP and ports helps make NAT easier to visualize.


NAT Application #1: Private to Public Translation

This is the most common use case.

The router acts as a translator between:

Private Network

and

Public Internet

allowing internal devices to access external services.

Most people use NAT every day without realizing it.


NAT Application #2: Port Forwarding

This was one of the first practical networking concepts I had encountered.

Imagine a Node.js server running on:

Port 8080

But users expect to access the application through:

Port 80

The router or firewall can create a NAT rule:

Port 80 → Port 8080

So incoming traffic gets rewritten before reaching the application.

The server doesn't even know the translation happened.

This is one of the reasons developers can run services on non-privileged ports while still exposing standard HTTP ports publicly.


NAT Application #3: Layer 4 Load Balancing

This was the most surprising NAT use case for me.

Load balancers often create something called a:

Virtual IP (VIP)

Clients connect to the VIP.

The VIP itself may not belong to any real server.

Instead, the load balancer receives packets for that address and decides which backend server should receive them.

It then rewrites:

  • destination IP
  • destination port

using NAT rules.

The packet gets forwarded to a real backend server.

Because this happens at Layer 4, it can be extremely fast.

This is one reason Layer 4 load balancers are widely used in high-performance systems.


A Simple Mental Model

The way I think about NAT now is:

A router acts like a receptionist.

The outside world only knows the main office number.

Internally there may be hundreds of employees.

The receptionist remembers:

Who called whom

and forwards messages appropriately.

That memory is the NAT table.

Without it, responses would never reach the correct device.


Why This Matters for Backend Engineers

Before learning NAT, I thought routers simply forwarded packets.

Now I understand they're actively:

  • rewriting addresses
  • tracking connections
  • maintaining translation tables

NAT also appears in many backend systems:

  • Home routers
  • Cloud networking
  • Kubernetes networking
  • Firewalls
  • Port forwarding
  • Layer 4 load balancers

Understanding NAT makes infrastructure behavior much easier to reason about.


Final Thoughts

Before learning NAT, my router felt like a black box.

Now I understand that every request from my laptop is being translated before it reaches the internet.

The most interesting realization for me was that NAT isn't just an IPv4 workaround.

It's also a fundamental building block behind:

  • Port forwarding
  • Cloud networking
  • Container networking
  • Load balancing

Once you start thinking in terms of:

Source IP
Source Port
Destination IP
Destination Port

NAT becomes much easier to visualize.

And a lot of networking infrastructure suddenly makes more sense.

159 Points2 Badges2
2Posts
1Comments
Build your own developer journey
Track progress. Share learning. Stay consistent.

2 Comments

1 vote
0
🔥 Join developers growing publicly
Share your knowledge, build in public, and grow your developer presence with a global community.

More Posts

Understanding Symmetric vs Asymmetric Encryption as a Backend Engineer

Rahul - Jun 9

The Audit Trail of Things: Using Hashgraph as a Digital Caliper for Provenance

Ken W. Algerverified - Apr 28

Local-First: The Browser as the Vault

Pocket Portfolio - Apr 20

Merancang Backend Bisnis ISP: API Pelanggan, Paket Internet, Invoice, dan Tiket Support

Masbadar - Mar 13

Why Email-Only Contact Forms Are Failing in 2026 (And What Developers Should Do Instead)

JayCode - Mar 2
chevron_left

Related Jobs

View all jobs →

Commenters (This Week)

4 comments
1 comment
1 comment

Contribute meaningful comments to climb the leaderboard and earn badges!