Public vs Private IP

Run ip addr show on your laptop and you'll likely see an address starting with 192.168. or 10.. Check any website that tells you "your IP address," and you'll see a completely different number. Neither is wrong — they're two different addresses, serving two different purposes, and the gap between them is the reason a technology called NAT exists at all.

Why private address ranges exist

Every IPv4 address is, in principle, part of the global 32-bit address space discussed in IP addressing — a space that holds only about 4.3 billion addresses. If every single device on every home and office network needed its own globally unique, internet-routable address, that space would have been exhausted decades before it actually started running low.

The fix, standardized in 1996, was to carve out specific address ranges explicitly reserved for use inside private networks, never to be routed on the public internet at all. Every router and ISP on the internet is expected to simply discard, rather than forward, any packet destined for one of these ranges arriving from outside — which means the same private address can be reused, independently and without conflict, inside millions of unrelated networks simultaneously. Your home router's 192.168.1.10 and your neighbour's 192.168.1.10 are both perfectly valid, and neither interferes with the other, precisely because neither is ever meant to leave its own local network.

The reserved private ranges

Any address inside these three blocks is private, and all three are equally unroutable — none is "more private" than the others. The only real difference is size, which is why 10.0.0.0/8 dominates large environments like cloud networks (room for many subnets) and 192.168.0.0/16 dominates home routers (more than enough for a household). Picking one over another is a capacity decision, not a security one.

A fourth reserved range is worth knowing alongside them: the loopback range 127.0.0.0/8, already covered in IP addressing. It isn't a private network range in the same sense, since traffic to it never leaves the host at all, but it's set aside for the same underlying reason — some addresses are deliberately kept out of global routing.

What "not routable" actually means

Public internet routers — the ones operated by ISPs and backbone providers — simply don't carry routes for these ranges. If a packet shows up on the public internet destined for 192.168.1.10, there's no globally agreed answer for which of the millions of networks using that address it's meant for, so it gets dropped. That's not a security feature; it's a structural consequence of the address being locally rather than globally meaningful.

Which creates an obvious problem. If your laptop's address is unroutable, how does it ever reach a public website?

NAT: the bridge between private and public

Network Address Translation (NAT), performed by your home router or an equivalent gateway, solves this by rewriting packet headers as they cross the boundary between your private network and the public internet. When your laptop at 192.168.1.10 sends a request to a public web server, the router replaces the packet's private source address with its own public address before forwarding it — and records the translation in a table so the eventual reply can be sent back to the right internal device.

Laptop (192.168.1.10:51342) --> Router (NAT) --> Internet
                                   |
                          Rewrites source address
                          and often the source port,
                          recording the mapping
                          e.g. 203.0.113.7:61001

Notice the port in that diagram, because it's what makes the whole scheme work at household scale. If two devices behind the router both happen to use source port 51342, the router assigns each a different public source port and remembers which is which. The reply arrives addressed to 203.0.113.7:61001, the router looks up that pairing, and rewrites the destination back to 192.168.1.10:51342. Ephemeral source ports from Dynamic port range are doing the identifying work here — the router is keying its table on them.

That's why every device on your home network can reach the internet at once through a single public address. NAT gets a full treatment later in the course, covering the translation table in detail and what happens for connections initiated from outside, which is the harder half of the problem.

Finding both addresses on your own machine

Your private address is visible locally:

ip addr show

inet 192.168.1.10/24 brd 192.168.1.255 scope global eth0

Your public address isn't something your machine inherently knows, because the rewriting happens on the router, not on your laptop. The only reliable way to find it is to ask something on the outside what address your traffic appears to come from:

curl ifconfig.me

203.0.113.7

Run that same command from two different devices on your home network and you'll get the identical answer both times — hands-on confirmation that NAT is presenting all of them to the internet as one shared address, even though each has its own distinct private address locally.

Practical scenario: "it works on my Wi-Fi"

You run a small API on your laptop at 192.168.1.34:8080. Your phone, on the same Wi-Fi, opens it fine. A teammate at their own house cannot reach it at all. Both observations are correct and both follow from everything above.

Inside your LAN, 192.168.1.34 means something because your router and local devices all agree that this range belongs to your network. On the public internet it means nothing unique — millions of networks use the same range, so no router can know which 192.168.1.34 you meant.

Same Wi-Fi client  -> 192.168.1.34:8080 works directly
Internet client    -> needs your public address plus an explicit inbound path

That "explicit inbound path" has two common forms. Port forwarding is a router rule that says "traffic arriving on my public address at port 8080 should be rewritten and sent to 192.168.1.34:8080" — it works, and it exposes that service to the entire internet, so it belongs in a lab rather than on your home router by default. The other option is a tunnel: a service that your laptop connects outbound to, which then relays inbound requests back down that existing connection. Because the connection was initiated from inside, NAT allows it, and nothing needs to be opened on your router at all.

For development work, a tunnel or simply deploying to a real server is almost always the better answer. And for production, don't lean on private addressing as protection: it reduces accidental exposure, but access control belongs in firewall rules, cloud security groups (the per-instance packet filters that cloud providers apply in front of a virtual machine), authentication, and the service's own configuration.

Where this trips people up in an interview

The single most common wrong answer to "is a private IP address secure?" is a flat yes, usually justified with "it's not reachable from the internet." That's true only until something creates a path — a port forward, a compromised device already inside the network, a VPN, a misconfigured NAT rule — at which point "private" stops meaning "isolated." A strong answer separates two different claims that get conflated constantly: private means not globally routable, a purely structural fact about how internet routers handle that address block; secure means access is actually controlled, which is a property of firewall rules and authentication, not of the address range itself. RFC 1918 addressing was designed to solve address exhaustion, not to solve access control, and it happens to produce a security side effect — not a security design.

A good way to demonstrate this in an interview: point out that malware already running on a laptop behind NAT reaches the public internet exactly as easily as a legitimate browser does, because NAT only filters unsolicited inbound traffic. Nothing about a private address restrains what the device it's assigned to can initiate outbound.

Common mistakes

• Assuming a private-looking address means a device isn't "really on the internet." It can reach the internet perfectly well. It just can't be reached from the internet without NAT plus an explicit inbound rule.
• Expecting two private networks to reach each other because the addresses look compatible. Two homes both using 192.168.1.0/24 have no relationship at all — they're independent, identically numbered spaces, and connecting them requires a VPN or explicit routing, plus renumbering if the ranges overlap.
• Choosing 10.0.0.0/8 for a small network because it "sounds more professional." All three ranges behave identically. What actually matters is picking a range unlikely to collide with a network you'll later need to connect to — which is why 192.168.0.0/24 and 192.168.1.0/24, the most common home defaults, are poor choices for a company network that will eventually terminate VPNs from employees' homes.
• Forgetting that your public address can change. Most residential ISPs assign addresses dynamically, so anything you configure against today's public address may quietly break when it's reassigned.

Practice exercises

1. Run ip addr show and identify your private address and which of the three reserved ranges it belongs to.
2. Run curl ifconfig.me and compare that public address with your private one. Explain what device sits between them and what it rewrote.
3. If you have two devices on the same network, confirm they report the same public address and different private ones, and explain why that's expected.
4. Suppose a company's office network uses 192.168.1.0/24 and it wants to let employees connect from home over a VPN. Explain what breaks for an employee whose home router also uses 192.168.1.0/24, and what the company should have chosen instead.

Exercise 4 is a real migration that real networks have had to do, and the reason it's painful is that private addressing is a decision you make once and live with. That's the last piece of this module: you can now describe how a network is scoped and shaped, name the layer any failure sits at, work out which network an address belongs to, tell a hardware address from a logical one, and explain how one public address serves an entire household.

What's missing is the conversation itself. Everything so far has been about where data goes; nothing has been about the rules that govern how it gets there reliably — how a connection is opened and closed, what happens when a packet is lost, and why some applications deliberately choose a protocol that makes no promises at all. That's the next module, starting with the choice between TCP and UDP.

Sources

• IETF, RFC 1918 – Address Allocation for Private Internets
• IETF, RFC 3022 – Traditional IP Network Address Translator (Traditional NAT)
• IETF, RFC 6890 – Special-Purpose IP Address Registries — the full list of reserved ranges, including loopback.
• Cloudflare Learning Center, What is a private IP address?