Open WhatsApp and send a message. Open YouTube and start a video. Search something on Google. The information just appears — as if "the internet" were one place your device reaches into.

It isn't one place, and it isn't one computer. Here is what actually happens.

Your laptop is a device — a computer. So is your phone. The app or website you open runs on another device: a computer in a building somewhere, maybe in another country, always on, waiting to answer requests. (That always-on kind of device is a server — a computer that mostly just sits there storing, computing, and answering whoever asks, with almost no one touching it. More on it in the next lesson.)

So the two ends are not the same: one is the device in front of you, which asks; the other is a server, which answers.

Keep one more pair separate. The devices are those two ends. The data is what travels between them: a message, a video, a piece of a page. A device sends or receives; data is the thing that gets sent.

So "the internet" is not a place or a single computer. It is millions of devices — phones, laptops, and these always-on servers — passing data to each other, all day long. (That is what your "mobile data" gets spent on: real information moving back and forth.)

Here is the one idea the rest of these lessons build on: a piece of data can't be delivered unless it knows where it is going. Picture each piece of data as a parcel handed to a courier. A parcel with no address goes nowhere. Data is the same — every piece carries a destination, or it goes nowhere.

You have seen what a failed delivery looks like. "This site can't be reached." A page that spins and never loads. Underneath, the plain reason is often exactly this: the data didn't reach the right place, or nothing came back. The rest of this topic is about making that delivery work — and understanding it when it doesn't.

Every piece of data names its destination. So what is that destination, exactly?

It is an address — and to keep it apart from a street address, its real name is an IP address. It is a unique label for one specific device. Unique is the key word: no two devices online share the same IP address at the same moment, just as no two houses on one street share a number. If two did, your data wouldn't know which one you meant.

What does it look like? Usually a number, like this:

For now, treat it as a unique number that every device online has. (Why it is written in that four-part shape, and why the world is starting to run short of these numbers, comes a little later — there is a real reason.)

(Wondering why you type "youtube.com" and not a number like that? Good question. A separate system turns the name you type into the number underneath. It is DNS — the Domain Name System, and it is the next lesson.)

Now the part that's easy to miss: both ends need an IP address — not only the website, but your own device too. It makes sense once you see it is a two-way delivery:

→ Your device needs the server's IP address, so it can send its request to the right place.
→ The server needs your device's IP address, so it can send the reply — the actual page or video — back to the right place. Without your address, the reply is ready with nowhere to go.

So is the website's computer just like your laptop? Almost. Your laptop and a server are both computers — the difference is the job. Your laptop is yours: you carry it, and you use it to ask. A server is nobody's personal machine — it sits in a data center and does one thing, all day: wait for requests and answer them. Same kind of device, different role.

(Two questions naturally come up, both answered soon: where your device's own IP address comes from — it is given to your device when it connects — and whether that address ever changes. Hold them.)

A device's address is a number, like 142.250.1.100. But you type "youtube.com", not a number. So how does the name reach the number?

The internet keeps a directory — a phonebook — that does one job: you give it a name, it gives back the number. Name in, number out. It translates the name you remember into the number your data needs.

The phonebook's real name is DNS — the Domain Name System. You have probably heard the term. That is all it is: the lookup that turns the name you type into the number your data then travels to.

You have felt it fail. "Server not found" usually means the phonebook couldn't match the name to any number — so there is no address to deliver to, and nothing loads.

You now know what an address is, and that both ends have one. But here's the question that's easy to skate past: where does that address actually go? It can't just float alongside your data — something has to carry it.

Here's the answer, and it's the same parcel from the first lesson, up close. Every piece of data is wrapped like an envelope: your actual message sits inside, and the addresses are written on the outside, as a label — a TO (the destination) and a FROM (your own address, so the reply knows where to come back).

That address label on the outside has a name: the header.

And the envelope as a whole — the header on the front, your data inside — has a name too: it's a packet. A packet is just the envelope you've been picturing; "packet" is simply the technical word for it.

Two things fall out of this that matter later:

→ The network reads only the label, never the contents. Each router along the way glances at the TO address, sends the packet one hop closer, and passes it on — without ever opening it. That's how data crosses the whole world without anyone in the middle needing to understand what's inside.

→ The FROM address is why replies work. Because your own address rides on the front, the far end knows exactly where to send the answer back — the two-way delivery from the last lesson, made concrete.

You already know a device needs an address to be reached. Here's something that trips people up: a device actually carries two different labels, and they do different jobs.

The first is burned into the device at the factory and never changes. It identifies the device itself. Its name is the MAC address (Media Access Control) — think of it like a national ID number: it says who this device is, permanently, wherever it goes.

The second is the IP address from before — but here's the new part. A device is not born with an IP address. It's given one when it joins a network, the way you're given a room number when you check into a hotel. Join your home Wi-Fi, you get one IP. Join a café's Wi-Fi, a different one. The IP says where the device can be reached right now.

→ MAC — who the device is. Permanent. Set at the factory.
→ IP — where it's reachable. Assigned when it joins. Changes as it moves.

In the parcel-delivery analogy: your MAC is your national ID — it's you, and never changes. Your IP is your current mailing address — where post reaches you now, different when you move house.

One thing worth settling before we move on: the MAC is permanent and unique to each device — but it's not the address the internet delivers to. Data travels to the IP, the where. And unlike the factory-set MAC, an IP is handed out and reused, never owned. Hold onto that "handed out, not owned" idea — it's about to explain almost everything.

This is the one fact that explains almost everything else about addressing. If you remember nothing else, remember this.

When IP addresses were designed, each was a number of a fixed size — and "fixed size" has a consequence: there are only so many of them. About 4.3 billion, total. In the 1980s, with a few thousand computers, that felt endless.

It wasn't. Count the phones, laptops, servers, routers, TVs, and cameras online today and you're far past 4.3 billion — many times over. The world ran out of addresses.

That's the cause. Everything that follows — private addresses, the sharing tricks, the reason your address keeps changing — exists for one reason: there aren't enough public addresses to give every device its own. Each new idea coming up is just another way to cope with that shortage. Keep that sentence in your pocket.

In the parcel-delivery analogy: imagine the postal system only ever printed about 4.3 billion possible street addresses for the whole planet, and the world outgrew them. You'd have to get clever about sharing — which is exactly what happened.

So the world is short on addresses. Here's the first trick for coping — and you can see it on your own device right now.

Open your Wi-Fi settings and look at your device's address. It very likely starts with 192.168. or 10. — and yet a website never sees that number. That's because it's a private address: one of a special set of ranges set aside to be reused.

Instead of spending a scarce, globally-unique address on every device, networks reuse the same private addresses inside themselves. The address 192.168.1.5 exists inside millions of homes at once — fine, because a private address only has to be unique inside its own network, not across the whole internet.

The parcel-delivery analogy shifts here, from the open road to inside an apartment building. Picture a large apartment building with one street address on the front. Inside, the apartments are numbered 1, 2, 3… Every building has an "Apartment 3", and nobody's confused, because "Apartment 3" only means something inside that building. Private addresses are apartment numbers: reused in every network, meaningful only inside.

Trace it back to the cause: pure scarcity-coping — reuse the same internal numbers everywhere instead of burning a scarce global address on every device.

But notice where the picture strains: an apartment number alone can't receive a letter from outside the building — and neither can a private address. So how does your device reach the internet at all? That's the next lesson.

A private address can't be reached from the public internet. So how does your private-addressed laptop load a website?

Through a translator at the edge of your network: your router. It has two faces — one public address facing the internet (the building's street address), and your private devices facing inward.

When your laptop sends a request, the router swaps the laptop's private "from" address for its own public one, sends it out, and writes a line in its logbook — this reply belongs to your laptop. When the answer returns to the public address, the router checks its logbook and hands it to the right device inside.

That swap-and-track is called NAT (Network Address Translation).

In the parcel-delivery analogy, the router is the building's front desk. Outgoing mail leaves under the building's single street address; replies arrive at the desk, which checks its logbook — "this one's for Apartment 5" — and walks it over. One street address out front; many apartments behind it, sharing it.

Trace it back to the cause: NAT is the second scarcity trick. One public address now serves a whole network, instead of being spent on just one.

Here's the honest thing about CGNAT (Carrier-Grade NAT — your provider running NAT a second time, on top of yours): day to day, you'll never notice it — everything you do dials out, so it just works. It only bites the day something needs to reach you directly from outside: hosting a server, linking two offices, reaching equipment at a remote site. That's almost always a business need — exactly the problem you'll solve for clients. (You may also have spotted the smaller sign: your address keeps changing and isn't really "yours".)

NAT let one building share one public address. But there still aren't enough to give every building its own. So your internet provider — your home-internet company or your mobile network; to the data, they're the same thing — does the very same trick one level up.

It's the same translation, stacked twice — that's the "double" in double NAT: your router turns your private 192.168. apartment numbers into the one address your provider gave it; your provider's gateway turns that into the single real public address the internet sees.

The address your provider hands your router is itself shared — and you can spot it, because it starts 100.64.. So you can read the layer straight off the number: 192.168. = inside your building; 100.64. = the shared rung between you and your provider; a normal public number = the real street address out front.

That second, provider-level translation is CGNAT (Carrier-Grade NAT — "carrier" just means your internet provider). Two translators stacked is double NAT.

The apartment picture, one level out: even building street addresses are now scarce, so a whole gated complex of apartment buildings shares one street address, with a central gatehouse routing mail. Two gatekeepers between you and outside: the complex gatehouse (your internet provider) and your building's front desk (your router).

Your mobile data has worked this way for years — which is exactly why your mobile network counts as an internet provider here too.

Trace it back one last time: same scarcity, one level higher — the provider shares one public address across many customers.

Now the consequence that matters, and it's a split: sending out still works — you start the conversation, so the gatehouse and front desk each log a line, and the reply finds its way back. But being reached from outside breaks — something outside arrives at a street address shared by hundreds, with nothing in any logbook saying which building, let alone which apartment, so the gatehouse can't place it. That outbound-works / inbound-breaks split is the whole reason behind the customer question we tackle in Part 2.

Right at the start we said an IP address is handed to a device when it joins, not built into it. Here's how that happens — and why your address quietly changes.

Because addresses are scarce, nobody gets to keep one they aren't using. Addresses are leased. When your phone joins a network, something hands it a free address from a pool, for a while. When it leaves, that address drops back into the pool for the next device. Join again tomorrow and you might get a different one.

The thing handing them out has a name: DHCP (Dynamic Host Configuration Protocol). It runs quietly inside your router — but you've felt it every time your address changed.

→ Dynamic — the normal kind. You get whatever's free, and it can change. Nearly every phone and laptop.
→ Static — a fixed address, set deliberately so it doesn't change. You arrange one for something that must always be found at the same place: a server the business runs, or the office gateway that branch sites and remote staff connect back to.

In the parcel-delivery analogy, a dynamic address is a hotel room number — assigned at check-in, handed back at check-out, given to the next guest. A static address is your own place — your name permanently on the door, the number always yours.

Trace it back once more: leasing exists because addresses are scarce. You can't permanently hold one you're not using — so dynamic is the default, and "fixed and yours" is the special case you have to arrange.

A client calls: "I can browse fine, but I can't reach my office camera from home." Before you can fix it — and before you give the wrong answer that sounds right — you need the one idea underneath it: who starts the conversation.

→ Outbound — you start it. When you open a website, you send the first request. On the way out, your router and your provider each write a line in its own logbook: "a reply is coming back for this customer." So when the answer returns to the shared public address, there's a trail leading it home. This is the everyday direction — which is exactly why nobody notices CGNAT.

→ Inbound — someone outside starts it. Now something outside tries to reach you first — and "outside" includes people you want: head office reaching a branch, your own laptop dialling in from a café. Its request lands on that one public address — shared by hundreds of customers — with no logbook entry, because nothing started from inside. The provider's equipment has no way to know which customer it's for, so it's dropped — welcome or not.

In the parcel-delivery analogy: outbound is mailing a letter with your return address — the front desk logs it, the reply comes straight back. Inbound is a letter posted to "the complex's shared street address, for… someone in there" — the gatehouse can't tell which building, let alone which apartment, so it can't deliver. A courier you were expecting and a stranger off the street fare exactly the same: nothing on file, no delivery.

Now the part that keeps you honest — because here the easy answer is wrong. This does not mean you're unreachable. Almost everything that feels like being reached actually works, because something on your side dialled out first. That office camera the client is worried about? It very likely works remotely — because the camera holds an outbound connection up to its vendor's cloud, and the phone reaches the same cloud; both dialled out, each has a logbook entry, so they meet in the middle.

What truly breaks is being a direct, unsolicited destination: something outside connecting straight to a service at your address, with no middleman. And for a Zuba client, that's where real money is on the line: linking two branch offices, reaching equipment at a remote site without a vendor's cloud, hosting their own server in-country — often the very function they bought a solution for. Every one of those needs the same thing — to be reachable directly, at an address that's theirs and stays put: a stable, directly-reachable endpoint. That's the target everything from here builds toward — and the next three ideas (ports, how a conversation opens, and port forwarding) are how you get there.

These two show up the moment you touch a firewall rule or set up remote access — "open port 443," "forward port 3389." Here's what a port actually is, because you can't diagnose a connection without one.

An address gets data to the right device. But one device runs many services at once — a laptop loading a web page, on a video call, and syncing files all in the same moment. So how does incoming data reach the right service? A second number: a port.

A port is a number that labels a service. The full destination is always address + port, written with a colon: 203.0.113.7:443. Common services have standard numbers — 443 secure web, 22 remote terminal, 3389 remote desktop. The address gets data to the device; the port says which service on it. And note who does the work: the port decides nothing — it's just the label. The receiving device reads that number and hands the data to the matching service.

Handy reference — the ports you'll meet most:

Where a port actually lives: each service is a separate program on the device, each listening on a claimed number — the web-server program on 443, remote desktop on 3389. ("Virtual" just means it's a software convention, not a socket you can point at — but there's always a real program on the other end.) And keep one thing separate: a port says which service, nothing about how the conversation runs — TCP vs UDP (next) is a separate choice, and the same number 443 exists as a TCP port and, independently, a UDP port. A port isn't "a UDP port" by nature; it's just a label.

In the parcel-delivery analogy: the address gets the parcel to the right device. Zoom in, and that device runs several services the way a business runs departments. The port is the "Attention:" line on the parcel — [address], Attention: Legal Department. Same street address; it just names which desk handles it. Notice it's a different kind of sub-address than a street or apartment number — not another one of those, but a marker for which function inside.

This also sharpens the logbook entry from Reaching out vs being reached: the line your router logs on the way out isn't just your address — it's your address and a port. Every conversation is pinned to one service, so the replies to your web page never get mixed up with the replies to your call.

Here's exactly when this lands on your desk. A client wants head-office staff to reach a server — or the CCTV recorder, or the phone system — at a branch, from outside. The standard action is one line on the branch router: forward the port that service runs on, so outside requests reach the right machine inside. You'll set that up or explain why it isn't working. It's also the language your firewall work is written in — a rule is allow this port, block that one. So ports aren't trivia; they're the unit the job is expressed in. (And the hook for what's coming: try that same port-forward on a CGNAT line and it won't connect — exactly the problem the next lessons solve.)

You'll set up VPNs and you'll troubleshoot "why won't this connect / why does it keep dropping." The difference between guessing and knowing is understanding how a conversation starts. There are two styles.

→ TCP opens with a handshake — a quick "can we talk?" / "yes, go ahead" / "thanks" before any real data moves. That handshake is exactly the moment your router and your provider each write a line in its own logbook. So a TCP conversation has a clear, trackable beginning. (Web, email, file transfer, remote desktop.)

→ UDP skips the handshake — it just fires data off and hopes (it's connectionless). With no clear "start" to latch onto, the NAT can't tie a clean logbook entry to an opening; instead it keeps a tentative entry alive on a timer and erases it after a stretch of quiet. (Voice and video calls, gaming, DNS — and, importantly, most VPNs run over UDP.)

In the parcel-delivery analogy: TCP is a signed-for delivery — both sides agree before anything ships. UDP is a postcard dropped in the slot — no confirmation, just sent.

Why two styles exist at all — it's a trade between getting everything and getting it now. TCP guarantees the whole message arrives, in order, re-sending anything lost — right for a web page, a file, an email, where one missing piece corrupts the result. UDP gives that up on purpose: in a live voice or video call you can't stop to re-send a lost packet — by the time it arrived it'd be a slice of video from a second ago, useless, and it would only jam up the live picture. So for real-time, "send it and move on" beats "send it and be sure."

Here's why it earns its place (and we stop here — how TCP guarantees delivery is a later lesson): the VPN you deploy for a client almost certainly rides UDP, and UDP behind CGNAT lives on that timer. So when a client's tunnel "works, then quietly dies after it's been idle," this is often the reason — the logbook entry timed out and was erased.

The one-line takeaway: TCP's handshake gives the NAT a solid, tracked connection to hold onto; UDP gives it only a timer — so an idle UDP tunnel quietly drops, while a TCP session stays put.

This is the first fix any technician reaches for — and the exact moment you'll realise a CGNAT client is stuck. Both halves matter.

Normally, unsolicited inbound is dropped (no logbook entry). But you can write a permanent logbook entry yourself, in advance. You tell your router: "any request that arrives on port 3389 — send it straight to the server at 192.168.1.42." That's port forwarding: a standing line in your front desk's logbook, one you write yourself — always send this port's inbound traffic to this one machine. On an ordinary connection — one where you have your own public address — this is how you host a server or reach a device from outside. Standard fix.

Now the catch, and it's the whole point. Port forwarding only writes in your router's own logbook — translation ① from the double-NAT picture. Under CGNAT there's a second one — the carrier's logbook, kept at the gatehouse — translation ② — and you can't write in it, can't configure it, and it sits on an address that isn't even yours. So you can fill your router's logbook with standing instructions and outsiders still can't get past the gatehouse: the carrier's logbook has no line for you, and it's not yours to add one.

That's the payoff in a client call: the instant port-forwarding "doesn't work" on a CGNAT line, you stop fiddling and recognise the diagnosis — "you're behind CGNAT; no router setting fixes this; you need a stable, directly-reachable endpoint by another route." Naming that correctly in thirty seconds beats an hour of config — and it's where what Zuba actually sells begins.

Now you can name, precisely, what a CGNAT client is missing — and it's narrower and sharper than "they can't be reached."

Remember: they're not unreachable in general — anything relayed through a cloud they dialled out to works fine. What they lack is a stable, directly-reachable endpoint.

The word, pinned down — and located. An endpoint (more precisely a connection endpoint) is a place a connection can be made to — concretely, a service running on a machine, reachable at an address + port (from One address, many services: the address reaches the machine, the port the service on it). It's a real program on a real computer sitting somewhere — not an abstraction, and not the whole device: one machine can offer several endpoints, one per service. So picture an actual machine with its own public address, out on the open internet where any outsider can reach it — a small server the client rents or runs, sitting outside the CGNAT. (The hunch that it's "a paid-for service on a server outside my CGNAT" is exactly right.) For it to do its job, three things must be true at once — and "the client" is who each one is about:

→ The address is the client's alone, not shared — so an inbound request lands on that client's endpoint, not on one address split across hundreds of customers. (CGNAT removes this.)
→ The address is stable, not changing — so whoever is connecting can still find the endpoint next week. (Dynamic leasing removes this.)
→ The endpoint can accept unsolicited inbound — so an outside-started connection isn't dropped. (NAT drops it by default; under CGNAT, port forwarding can't restore it.)

On a shared, dynamic connection a client has none of the three — and for streaming video that's fine, because they only ever start conversations outward. But the moment they need to be a direct destination — two offices linked, a server hosted in-country, equipment reached at a remote site without a vendor's cloud — they need that endpoint, and an ordinary CGNAT line can't give it.

In the parcel-delivery analogy: think of a rented PO box at the post office — a fixed, public address that's the client's alone, that the post office always delivers to, and that accepts mail from anyone. It isn't the client's home (behind the complex gatehouse, unreachable from outside); it's a separate, reachable point the client rents because home can't be reached directly — not a shared complex address, not a hotel room that changes next week, not a building that only ever sends mail out.

Trace it home: addresses are scarce → so they're shared (NAT, CGNAT) and leased (dynamic) → so by default a client is neither uniquely addressed, nor stable, nor inbound-capable → so when they genuinely need to be reached directly, it has to be arranged on purpose. How you arrange it is the last section.