DEV Community: Ganesh Angadi

The Great IP Illusion: Public vs. Private IPs and How NAT Saves the Internet

Ganesh Angadi — Sat, 18 Jul 2026 18:39:45 +0000

The Great IP Illusion: Public vs. Private IPs and How NAT Saves the Internet

In my last blog, I talked about IPv4 vs. IPv6, mentioned that there are about 4.29 billion IPv4 addresses in existence, and dropped a small hint about the "NAT Gateway."

Now, the question is: Are all those 4.29 billion addresses usable by anyone on the internet, and what exactly is NAT?

Sometimes, you might run an ipconfig or ifconfig command on your computer and get something like 10.24.35.211, or you might try to hit 192.168.1.1:8090 in your browser. You might think, "Ooh, this is my IP! I can get IPs, I am a hacker!" But is that your real IP? Is that the IP you use when you search for something on Google?

The answer is a big NO.

Private IPs: The Local Illusion

Even though there are 4.3 billion addresses, you can't use all of them on the open internet. There are specific ranges of IP addresses that cannot be assigned to public devices. These are called Private IPs.

For example, anything starting with 192.168.x.x or 10.x.x.x is a private IP, not an actual public one. This means those IP addresses only exist locally inside your specific network. So, good luck trying to "hack" your mobile phone from your laptop using its private IP if you aren't connected to the exact same Wi-Fi router!

Public IPs: The Global Address

On the other hand, a Public IP is a globally routable IP address. In most homes, it's assigned to the router rather than individual devices, allowing those devices to communicate directly on the open internet. Each Public IP is assigned based on its location and is managed by an Internet Service Provider (ISP). For example, the router in my hostel has a public IP address of 118.151.x.x.

The biggest difference between public and private IPs is that you can easily find the approximate location of a public IP because it is registered to an ISP, which operates in a specific region.

Meanwhile, your laptop at home and someone else's mobile phone in Russia can both have the exact same private IP (like 192.168.1.3). Because private IPs are only routable inside their own local networks, multiple devices across different networks can safely reuse them. However, no two systems or routers on the entire public internet can ever share the same public IP.

Enter NAT (Network Address Translation)

So, how does everything talk to the internet if we are using private IPs?

Imagine your phone, laptop, printer, and smart TV are all connected to the same Wi-Fi router in your house. Your devices won't get unique public IPs. Instead, the router gives each device its own private IP (e.g., 192.168.1.2 for your phone, 192.168.1.3 for your laptop).

The three most common private IPv4 ranges are:

10.0.x.x
172.16.x.x
192.168.x.x

Routers on the public internet are configured not to route these addresses, which is why they can safely be reused in millions of homes and offices.

When you browse the internet, the data packets from your laptop travel to your router. The router replaces the source IP address in the packet with its own public IP (something like 42.53.56.112) before sending it to the internet. The internet never actually knows if your laptop, your mobile, or even your smart doorbell is trying to view an Amazon cart. The router acts as the middleman; it remembers which internal device asked for the data, receives the response from the internet, and forwards it back to the correct device.

This is NAT.

The Office Building Analogy (For Non-Techies)

If all of this sounds a bit too technical, think of it like a large office building:

The Building Address (Public IP): The entire office building has one main street address and one main phone number (e.g., 1-800-COMPANY). Anyone in the outside world can use this to reach the building.
The Internal Desk Numbers (Private IPs): Inside the building, there are 500 employees. Each employee has their own internal desk number (e.g., Desk No. 402).
The Receptionist (NAT Router): If a guy at Desk No. 402 wants to order a pizza, he calls from his desk phone. The pizza place's caller ID shows the building's main phone number, not the guy's internal desk number. When the pizza arrives, the delivery driver drops it off at the front desk. The receptionist (your router) remembers that the guy placed the order, so they bring the pizza directly to Desk No. 402.

The pizza delivery guy (the internet) never knows the guy's exact desk location. They only know the building's main address. The receptionist handles all the internal routing. That is exactly how NAT and Private IPs work!

Saving the Internet (At Scale)

To give you a practical example of why this is necessary: Let's say a university provides internet to 1,000 students and 20 computer labs, totaling around 2,000 devices. In India alone, there are around 5,000 colleges. If every single device got a Public IP, we would run out of our 4.29 billion limit instantly!

To solve this, the internet lets each college use just one (or maybe a handful of) Public IPs. The college router then assigns every student's computer a Private IP. Those private IPs can never be accessed directly from the outside world. This is exactly why, when you want to test a local website, share files via SFTP, or do some cool networking tricks, both devices usually need to be on the same local network.

What exactly is a VPN IP?

Since your Public IP is assigned by your Internet Service Provider (ISP), it is tied to a physical region. When websites look at your IP, they query a database that says, "Ah, this IP block belongs to an ISP in Mumbai, India." They can't see your exact room number or street, but they know your general city and your provider.

(Your Private IP, on the other hand, is completely invisible to these websites. It only exists inside your house!)

So, how do you hide your location? You use a VPN (Virtual Private Network).

When you use a VPN, instead of your router sending your request directly to Amazon or Google, it sends it through an encrypted tunnel to a VPN Server (let's say, in New York). The VPN server then requests the Amazon page on your behalf.

To Amazon, the request came from the VPN server's Public IP in New York, not your router's Public IP in India. When Amazon replies, it sends the data to the New York server, which then securely forwards it back to your laptop. You have successfully masked your location!

Summary

A Public IP is the face you show to the entire internet, while a Private IP is only visible to devices within your own local network.

Because of NAT, that 4.29 billion limit has been stretched far beyond its original capacity, allowing the internet to grow to what it is today!

Cloud providers run millions of virtual machines, but only a small percentage of them are assigned public IPv4 addresses. Most live entirely inside private networks behind load balancers, NAT gateways, or proxies.

So, never get scared when someone says "I have your IP!" and then reads out 192.168.x.x 😄 — unless they actually read out a real public IP like [YOUR_PUBLIC_IP]! :)

Wondering whose IP that is?

To see your real IP, visit the interactive blog for my page click here

Bonus: What Else Can Websites See?

If your Public IP isn't enough to hack you, what are websites actually looking at? The answer is... almost everything else. Without you ever typing a single word, any website you visit can legally and automatically read:

Your Hardware: They know your screen resolution, CPU architecture, your battery level, and even whether your device is currently plugged into a charger.
Your Software: They can see your exact operating system, browser version, installed fonts, system language, and timezone.
Your Movement: On supported mobile browsers, websites may access motion sensors such as the gyroscope and accelerometer (usually with permission).
Your Network: Even without your IP, they can measure your connection speed to guess if you are on 5G, Wi-Fi, or a restricted corporate network.

[WHAT_YOUR_BROWSER_TOLD_ME]
I have built a Interactive table that shows what your browser is telling to every user. Read Here

The Illegal/Shady Stuff:
If a website is malicious and exploits vulnerabilities in your browser (like a zero-day flaw or an unpatched WebRTC leak), they can go even further:

True Identity Leaks: Leaking your real IP through browser vulnerabilities or WebRTC misconfiguration.
Local Network Scanning: Using your browser as a bridge to secretly scan your local Wi-Fi for other devices, smart TVs, or vulnerable routers (192.168.x.x).
Port Sweeping: Checking to see if you have any local developer servers or insecure applications running in the background.

So while a Public IP is just a digital street address, your browser is constantly handing out your full digital profile. Stay curious... and keep your browser updated. 😉

If you were shocked by how much your browser reveals drop a comment i will come back with even cooler topic about it :)

Why the internet is still stuck on IPv4

Ganesh Angadi — Wed, 15 Jul 2026 19:09:27 +0000

We all learned in school that IPv4 is 32-bit and IPv6 is 128-bit. But that never really explains why the whole world hasn't just switched over yet.

I just published a quick deep-dive on why NAT basically became the most successful temporary band-aid in tech history, and why replacing a core internet protocol is so painfully hard.

Give it a read here and let me know if you're dealing with dual-stack headaches at work:

SSH vs. HTTPS: A Shared Machine Case Study

Ganesh Angadi — Wed, 08 Jul 2026 18:33:10 +0000

Most SSH vs HTTPS articles compare encryption.

Mine started because of a college lab.

I realized that using Git over HTTPS on a shared machine could leave cached credentials behind, creating problems for whoever used the computer next. That question led me into understanding how Git authentication really works and why SSH can be a cleaner option in temporary or shared environments.

The article isn't about declaring a winner. It's about choosing the right authentication method for the situation.

If you've worked in computer labs, training environments, or shared systems, I'd genuinely love to hear how you handled Git authentication.

🔗 Read Here

Monolith vs. Microservices: Simplicity vs. Scalability ⚔️

Ganesh Angadi — Sat, 04 Jul 2026 18:48:03 +0000

When I started out, I fell for the hype: I thought microservices were the only modern way to build apps.

After building a modular monolith and a fully distributed microservices platform (TicketFlow), I learned the hard way that you are trading code complexity for operational complexity.

If you aren't ready to manage API gateways, distributed tracing, and complex Kubernetes pipelines, a monolith is going to make you much happier.

I wrote a full breakdown comparing local development, deployment, scaling, and the exact directory structures of my real-world projects.

👉 Read the full deep-dive on my blog!

GitHub Actions vs Jenkins | DevOps Duel #2

Ganesh Angadi — Wed, 01 Jul 2026 18:33:36 +0000

CI/CD has become a core part of modern software delivery, but choosing the right automation platform isn't always straightforward.

This article compares GitHub Actions and Jenkins across architecture, scalability, security, maintenance, cost, ecosystem, and real-world production scenarios.

Rather than declaring a universal winner, the goal is to understand where each tool excels and the trade-offs involved.

Whether you're just getting started with DevOps or designing production pipelines, I hope this comparison helps you make a more informed decision.

Happy reading!

🔗 Click Here

Docker Compose vs Kubernetes: Which One Should You Actually Use?

Ganesh Angadi — Sun, 28 Jun 2026 14:12:52 +0000

Docker Compose and Kubernetes are often compared as if they're direct competitors.

They're not.

I deployed the same application using both to understand where each one fits and what problems each is actually designed to solve.

In this article, I cover:

Why Docker Compose is perfect for local development
When Kubernetes becomes worth the complexity
Key architectural differences
Real-world use cases
A practical comparison instead of feature lists

If you've ever wondered whether you should learn Kubernetes before mastering Docker Compose, this article is for you.

Read here:
Click Here

I'd love to hear your thoughts and experiences using either tool.

# DevOps Duel ⚔️

Ganesh Angadi — Sun, 28 Jun 2026 14:11:39 +0000

Welcome to DevOps Duel, a new series where I compare popular DevOps tools and technologies through practical examples instead of marketing claims.

No hype.
No "X is dead."
Just when to use what, why it exists, and the trade-offs that actually matter.

Upcoming duels include:

Docker Compose vs Kubernetes
GitHub Actions vs Jenkins
Nginx vs Traefik
Terraform vs OpenTofu
PostgreSQL vs MongoDB
Prometheus vs Grafana

The first duel is already live:

Docker Compose vs Kubernetes

Read here:
Click to Read

Feedback, corrections, and discussions are always welcome.