I'm Switching Careers Into IT — And This Is What I Learned This Week
VMware confused me. Three network adapters, a bunch of IP addresses I didn't assign, and zero explanation of why any of it worked. So I sat down, figured it out, and documented everything.
I'll be honest with you.
A few weeks ago, I opened VMware Workstation and stared at three options — Host-Only, NAT, Bridged — and had absolutely no idea what any of them meant. I clicked NAT because it sounded familiar. The VM got internet. I moved on.
That bothered me.
I'm switching careers into IT. I can't afford to just click things and hope. I need to understand what's happening under the hood — because one day, someone is going to ask me to troubleshoot a network issue, and "I clicked NAT because it sounded right" is not going to cut it.
So I stopped. I went back. And I spent real time learning how VMware networking actually works.
This is what I found out.
The Problem Nobody Explains Clearly
When you set up a virtual machine in VMware, you have to choose a network adapter type. Most tutorials say something like:
"Use NAT if you want internet access, Bridged if you want to be on the same network, Host-Only if you want isolation."
That's fine. But it leaves about fifteen questions unanswered. Questions like:
- Where do these IP addresses come from? I never configured a DHCP server.
- Why does my host machine have an adapter called VMnet1 with an IP I didn't set?
- Why is the NAT gateway
.2and not.1? - What actually happens to my traffic when it leaves the VM?
These are the questions I went and answered. One by one.
Host-Only (VMnet1): The Isolated Bubble
Host-Only creates a completely private network. Your VMs can talk to each other and to the host machine — and that's it. No internet. No home router. Nothing outside.
When you look at your host machine's network adapters, you'll see VMnet1 sitting there with an IP like 192.168.15.1/24. I used to wonder where that came from. The answer: VMware assigned it automatically and reserved it for the host. The .1 address is always the host. Everything else in the pool goes to your VMs.
The moment this clicked for me was when I pinged the host machine from inside the VM. It worked — and I understood why it worked. Both devices are on the same virtual switch, with IPs from the same subnet, and VMware's internal DHCP handed them out. No magic. Just a well-designed virtual network.
Key thing I learned: Always ping 192.168.15.1 (the VMnet1 IP) — not your home router IP. Those are two completely different networks, and one has no idea the other exists.
NAT (VMnet8): The Internet Through a Middleman
NAT was the one that confused me the most — and turned out to be the most interesting once I understood it.
NAT stands for Network Address Translation. The idea is simple: your VM doesn't connect to the internet directly. It sends its traffic to a virtual router that VMware creates, and that router forwards the traffic through your host machine's real internet connection. To the outside world, everything looks like it's coming from your host — not your VM.
Here's the detail that tripped me up for a while: the host machine's VMnet8 adapter gets the .1 address (192.168.113.1), just like with Host-Only. But the default gateway that VMs use is .2 (192.168.113.2). Why?
Because VMware's internal NAT router lives at .2. The .1 is taken by the host. So the virtual router had to go one address higher.
I confirmed this was actually working by running tracert from inside the VM. When I traced to the host machine, it completed in one hop. When I traced to an external internet address, the intermediate hops were hidden — masked by the NAT translation. That hidden information isn't an error. It's proof that NAT is doing its job.
Bridged (VMnet0): Just Another Device on the Network
Bridged is conceptually the simplest — but it has the most gotchas.
With Bridged mode, your VM bypasses all of VMware's internal networking completely. It connects directly to your physical network, exactly like plugging a new laptop into your router. Your home router's DHCP server hands out the IP address. Your VM appears as a real device on the LAN.
The practical consequence: VM-to-VM traffic doesn't stay inside VMware. It travels from VM1 → home router → VM2. The router is always in the middle.
The gotcha I ran into: the Automatic setting in VMware's bridged configuration can pick the wrong physical adapter. I switched it to manually select my Wi-Fi adapter, and connectivity immediately worked. If you're ever stuck on Bridged with no IP, that's the first thing to check.
And when it worked? I opened the router admin page (192.168.0.1) from inside the VM — the same page I can open from my host machine. That was genuinely satisfying. The VM was a real citizen of my network.
What I Actually Took Away From This
Here's the honest summary:
| Adapter | DHCP Source | Internet? | Traffic stays in VMware? |
|---|---|---|---|
| Host-Only | VMware internal | No | Yes |
| NAT | VMware internal | Yes (via host) | Yes (until NAT) |
| Bridged | Home router | Yes (direct) | No |
But more than the table, I took away a way of thinking. When something doesn't work, ask:
- Who assigned this IP address?
- What is the default gateway, and does it make sense?
- Where is the traffic actually going?
Those three questions will get you surprisingly far in networking troubleshooting.
Why I Documented All of This
I took 23 screenshots. I wrote up every setting in the Virtual Network Editor. I built a full Word document with tables, callout boxes, and figure captions. Then I put it on GitHub.
Some people might read that and think — that's overkill for a beginner topic.
Maybe. But here's my thinking: I'm switching careers. I don't have years of experience to show. What I can show is that I learn deliberately, I don't just click through things, and I take the time to understand and communicate what I've learned. That's a skill too.
If you're also switching into IT — or just starting out — I'd encourage you to document your learning, even when it feels small. Especially when it feels small. The habit of writing things down forces you to actually understand them, and the collection of what you've written becomes something you're genuinely proud of over time.
The Full Documentation
If you want to go deeper, I've published everything on GitHub — the full Word document with all 23 screenshots, the network diagrams, and the README.
🔗 https://github.com/Er-Lovepreetsingh/vmware_networking.git
And if you're on a similar journey — switching careers, learning on your own, figuring things out one lab at a time — I'd love to connect. Drop a comment or reach out.
We're all building from somewhere.
Top comments (0)