Read this as a study guide instead
How a packet crosses the internet and finds its way back.
These commands only read information — they change nothing. Run the block for your OS, then use the table to read your own numbers against the ideas above.
Get-NetRoute
Find-NetRoute -RemoteIPAddress 1.1.1.1What you should see Get-NetRoute lists the routing table including the 0.0.0.0/0 default entry and its NextHop; Find-NetRoute -RemoteIPAddress 1.1.1.1 reports the best local source address and the next hop chosen to reach that destination.
Note Run these in Windows PowerShell, not inside WSL: inside WSL you get the Linux network stack and the Linux commands apply instead.
netstat -rn
route -n get 1.1.1.1What you should see netstat -rn prints the routing table with a default row whose Gateway column names the router; route -n get 1.1.1.1 asks the kernel which route applies to that single address and prints the interface and gateway it would use, with -n leaving addresses numeric.
Note macOS route requires a subcommand and does not behave like Linux route; the get form only queries the kernel and changes nothing.
ip route
ip route get 1.1.1.1What you should see ip route lists the routing table, including a default via line that names the gateway your machine uses for everything off-subnet; ip route get 1.1.1.1 resolves and prints the exact route, source address, and gateway the kernel would use to reach that destination, without sending anything.
| Concept | Windows | macOS | Linux |
|---|---|---|---|
| default route (0.0.0.0/0) | Get-NetRoute (the 0.0.0.0/0 DestinationPrefix) | netstat -rn (the default row) | ip route (the default via line) |
| gateway for an internet destination | Find-NetRoute -RemoteIPAddress 1.1.1.1 (the NextHop) | route -n get 1.1.1.1 (the gateway field) | ip route get 1.1.1.1 (the via address) |
These are the exact fragments the model serves — also available as an ordered study guide.
A network-layer address gets a packet to the right machine, but knowing the address is not the same as delivering it. Between your laptop and a server on another continent sit dozens of separate networks, none of which was built to reach any of the others directly. Two mechanisms do the actual delivery, and they solve two different problems.
The first is routing: choosing, at every step, which network to hand the packet to next so it ends up closer to its destination. No single machine plots the whole trip; the path is assembled one hop at a time by routers that each know only a little. The second is NAT (network address translation), which lets a whole houseful of private machines share one public address, because the address your laptop uses at home is not an address the wider internet will carry.
Together they explain the two things that most often puzzle people about their own connection: why a packet visibly passes through so many unrelated hops, and why the address your machine sees for itself is not the address the rest of the world sees. Both are worth understanding before you try to make a machine at home reachable from outside it.
There is no master map of the internet, and no router holds one. When a packet arrives, a router does exactly one thing with it: it decides which neighbor to forward it to — the next hop that is one step closer to the destination — and passes it along. The full path is never planned in advance; it emerges, hop by hop, from a long chain of these local decisions.
This is easier to trust with a familiar picture, like a mail sorting center that never needs the whole route: it only reads the destination and hands each letter to the next center in the right direction. Each router needs to know only its own neighbors and roughly which direction each destination lies, not the entire route to the far end. A packet crossing the world may pass through your home router, an ISP router, a regional core router, and several more, and not one of them ever saw the whole journey — each just made a good next step and let go.
The payoff of this design is that it scales and it heals. Networks can be added, removed, or knocked offline, and routing simply re-forms around the change one hop at a time, because no central plan has to be rewritten. The cost is that the exact path a packet takes is emergent, not chosen, which is why the route to the same destination can quietly differ from one moment to the next.
A router's decision is not guesswork; it is a lookup. Every router keeps a routing table, a list of destination networks written as prefixes — an address plus how many leading bits count, like 10.0.0.0/8 or 192.168.1.0/24 — each paired with the next hop and interface to use for that network. When a packet arrives, the router compares its destination address against every prefix in the table to find the ones it falls inside.
Usually more than one prefix matches, and the tie-breaker is the rule worth remembering: longest-prefix match. Of all the matching routes, the router picks the most specific one — the prefix with the most leading bits fixed — and forwards the packet out that route's interface toward its next hop. A broad prefix like 10.0.0.0/8 and a narrow one like 10.4.0.0/16 can both match the same address, and the narrower route wins precisely because it describes the destination more exactly.
This single rule is what lets one table hold both sweeping catch-all routes and pinpoint exceptions without contradiction. The specific always overrides the general, so a router can send almost everything one way while quietly diverting one particular network somewhere else.
Your own machine makes a routing decision too, and it is a simple one. For any packet, it asks a single question: is the destination on my own subnet, or somewhere else? If the destination shares the local network, the machine delivers the packet directly, with no router involved at all. If it does not, the machine hands the packet to its default gateway — the local router whose job is to forward everything bound for the outside world.
The default gateway is just the destination of the least-specific route a host keeps, written 0.0.0.0/0: a catch-all that matches every address nothing more specific covers. By longest-prefix match, an on-subnet destination matches a narrower route and goes direct, while anything else falls through to that catch-all and is sent to the gateway. This is why a machine with a broken or missing gateway can still reach its neighbors but nothing beyond them.
That gateway is the first hop of every journey off your network, and on a home network it is almost always the same box that does NAT. Finding its address — the router your machine sends the rest of the world to — is the first thing worth checking when a connection reaches nearby machines but stalls on the way out.
The addresses on your home network are not addresses the internet will carry. Ranges like 192.168.x and 10.x are reserved as private space: they are meant to be reused freely inside any local network and, by agreement, are never routed on the public internet. A packet with a private source address would have nowhere to come back to, because millions of networks use the same private numbers at once.
So the router at the edge of your network performs a swap. As each outbound packet leaves, it rewrites the packet's private source address to the router's own single public address, and it does the reverse on the way back — this is network address translation. To the outside world, every machine behind the router appears to be that one public address, like an office where everyone shares one public phone number, and the outside world only ever sees that single number. Dozens of private machines reach the internet through a single routable address that the router owns.
This is the everyday reason your laptop believes its address is something like 192.168.x while a website sees you arriving from an entirely different number. The private address is real and local; the public one is what the wider internet is allowed to know. NAT is the seam between the two.
Rewriting the source address raises an obvious problem: if every machine behind the router shares one public address, how does a reply find its way back to the right one? A packet arriving from the internet is addressed to the public address alone, which by itself points at the whole network, not at any single machine on it.
NAT solves this by remembering, and it remembers by port. For each outbound connection the router notes which internal machine and port opened it, and it assigns that connection a port on the public address, storing the pair in a translation table — like a receptionist who notes which internal extension placed each outside call, so the reply can be put through to the right desk. When a reply comes back to the public address on that port, the router looks up the entry and rewrites the destination back to the original internal machine and port. Tracking connections by port this way is what lets many machines truly share one address at the same time, each conversation kept separate.
The consequence is that the table is built entirely from the inside out. Every entry exists because some machine on the network started a conversation; the router only ever learned where to send a reply because it watched the request leave.
Because NAT only ever learns about connections started from inside, it has a built-in asymmetry. A reply to an outbound request always finds a matching entry in the translation table and gets forwarded home. But a packet that arrives out of nowhere — an unsolicited inbound connection that no internal machine asked for — matches no entry at all, and the router has no idea which internal machine it could possibly be for. So it drops the packet.
The result is that a home network is, by default, closed to the outside. This is not a firewall decision so much as a side effect of how translation works: with no table entry, there is simply no address to translate the incoming packet to. It is why the machines on your network can freely reach out yet cannot be reached back into without something extra.
That something extra is a port forward: a static entry you configure on the router in advance, mapping a chosen public port to a specific internal machine and port. It fills in the row the router could not learn on its own, so inbound packets on that port finally have a known destination. Opening the door is a deliberate act, which is exactly why it does not happen by accident.
The moment routing and NAT stop being theory is the moment you try to host something. Run a game server on a machine at home and your friends cannot connect, no matter how correct the server is, because the router drops their unsolicited inbound packets. The fix is a port forward: tell the router that traffic arriving on the server's port belongs to that one internal machine. Knowing why the door was closed turns a baffling failure into a two-minute configuration.
The same knowledge makes a traceroute legible. A traceroute lists the routers a packet passes through on its way to a destination, one line per hop — which is only meaningful once you know a packet really does cross many separate networks, each router forwarding it to the next. The list is the hop-by-hop path made visible.
It also explains a certain kind of slowness. Every hop is a real machine in a real place, and distance and detours add up, so a connection that routes the long way around can feel sluggish even when nothing is broken. Routing decides the path, NAT decides who can start a conversation, and between them they account for a surprising share of the networking problems people actually hit.