One of the most effective ways to learn networking is to stop memorizing protocols and start investigating real problems.
Recently, I encountered a situation that seemed simple at first.
A newly deployed internal service was accessible from my work laptop but not from my personal laptop.
A month later, the exact same URL became accessible from both devices.
At first glance this looked like a permissions issue.
But the more I investigated, the more networking concepts started connecting together.
What began as a simple question eventually led me through:
- Cloud networking
- VPNs
- Public vs private IP addresses
- MAC addresses
- ARP
- Ethernet frames
- Packet captures in Wireshark
This article summarizes the mental models that finally helped these concepts click.
The Original Question
The observation was simple:
Work Laptop
↓
URL works
Personal Laptop
↓
URL does not work
Later:
Work Laptop
↓
URL works
Personal Laptop
↓
URL also works
The obvious question was:
How does a server know the difference between two laptops?
Both devices were connected to the same home network.
Both were using the same internet connection.
So what was different?
My First Hypothesis: Cloud Networking Rules
My first assumption was that the answer lived inside the cloud platform.
Regardless of whether a service runs on:
- AWS
- Azure
- GCP
all cloud providers offer mechanisms for controlling network access.
Examples include:
AWS
- Security Groups
- Network ACLs
Azure
- Network Security Groups (NSGs)
GCP
- Firewall Rules
The names differ.
The underlying goal is the same:
Allow traffic
Block traffic
Control who can reach a service
This led me to a hypothesis:
Perhaps the service was initially restricted and later opened to a broader audience.
That explanation seemed plausible.
But there was another possibility.
The VPN Realization
My work laptop regularly connects through a VPN.
Specifically:
GlobalProtect VPN
This changed how I thought about the problem.
Without a VPN, traffic follows a path similar to:
Laptop
↓
Home Router
↓
ISP
↓
Internet
↓
Destination Server
With a VPN:
Laptop
↓
Home Router
↓
ISP
↓
VPN Gateway
↓
Company Network
↓
Destination Server
This raised a new possibility.
The server might not care about:
Work Laptop
vs
Personal Laptop
Instead, it might care about:
Company Network
vs
Public Internet
That distinction made much more sense.
Understanding IP Addresses
This investigation also exposed a misunderstanding I had about IP addresses.
There isn't just one IP address involved.
There are several.
Local IP Address
Assigned by your router through DHCP.
Example:
192.168.1.10
This address exists only inside your home network.
Internet servers never see it directly.
Public IP Address
Assigned by your ISP.
Example:
103.x.x.x
This is the address most internet services see.
VPN Address
Assigned by the VPN infrastructure.
Example:
10.50.x.x
When connected to a VPN, company systems may see this address instead of your ISP-assigned address.
This was an important realization.
A server often identifies where a request is coming from based on IP addresses—not based on the physical laptop itself.
The MAC Address Misconception
Another misconception I had involved MAC addresses.
Initially I assumed that remote services might somehow see the MAC address of my network card.
That is not how networking works.
What Actually Happens
Imagine traffic moving toward GitHub:
Laptop
↓
Router
↓
ISP Router
↓
More Routers
↓
Datacenter Router
↓
GitHub
At every hop:
MAC Address
Changes
IP Address
Remains the same
This means:
GitHub never sees the MAC address of my Wi-Fi card.
GitHub sees my public IP address.
That single insight corrected a large part of my networking mental model.
Where ARP Fits In
This naturally led to another question:
If devices communicate using MAC addresses locally, how does a device discover a MAC address?
The answer is:
ARP
Address Resolution Protocol.
The Problem ARP Solves
Suppose a device knows:
192.168.1.10
but does not know:
2c:9c:58:8b:2d:7b
ARP exists to bridge that gap.
Its purpose is simple:
IP Address
↓
Find MAC Address
An ARP Request in Plain English
A typical ARP request looks like:
Who has 192.168.1.10?
Tell 192.168.1.1
Translated into normal language:
I am 192.168.1.1
I am looking for
192.168.1.10
Who owns that address?
ARP requests are broadcast to the entire local network.
The ARP Reply
The device that owns the address responds:
192.168.1.10 is at
2c:9c:58:8b:2d:7b
Meaning:
I own that IP address.
Here is my MAC address.
The router can now send Ethernet frames directly to the correct device.
A Discovery from Wireshark
While inspecting packets in Wireshark, I noticed something surprising.
The packet structure looked like:
Frame
↓
Ethernet II
↓
ARP
Notice what is missing.
There is no:
IP
layer between Ethernet and ARP.
This was unexpected.
I initially assumed ARP worked inside IP.
It does not.
ARP operates alongside IP.
Why ARP Has No TTL
Another misconception involved TTL.
I assumed every networking protocol contained fields such as:
- TTL
- Routing information
- IP headers
That assumption was wrong.
TTL exists because IP packets travel through routers.
Example:
Laptop
↓
Router
↓
ISP
↓
Internet
↓
Destination
Each router decreases the TTL value.
ARP packets never leave the local network.
They are not routed across the internet.
Because of that:
No Routing
↓
No TTL Needed
Once I understood this, ARP's design suddenly made much more sense.
The Mental Models That Finally Clicked
After all of this investigation, several concepts became much easier to remember.
Cloud Networking
Different names.
Same networking fundamentals.
VPN
Changes the route packets take.
IP Address
Identifies a device across networks.
MAC Address
Identifies a network interface on a local network.
ARP
Answers:
"I know the IP address. What is the MAC address?"
DHCP
Answers:
"I just joined the network. Which IP address should I use?"
DNS
Answers:
"I know the website name. Which IP address does it map to?"
Final Thoughts
What started as a simple access issue turned into a useful networking lesson.
The biggest takeaway wasn't a specific protocol.
It was a different way of learning.
Instead of memorizing definitions, I found it far more effective to observe actual packet exchanges and then ask:
Why did that happen?
Wireshark made invisible networking behavior visible.
And once the packets became visible, many concepts that previously felt disconnected finally started fitting together.
Top comments (0)