Networking 101 for Hackers: NAT vs Bridged, Subnets, and Why Your VM Can’t See the Target

You Fire Up Kali… and Nothing Happens. Welcome to the Void.

You launch Kali, open up a terminal, run nmap -sV, full of hope—and then… crickets. No open ports. No ping response. No juicy web login page to poke at. Just a whole lot of digital silence.

Meanwhile, the OSCP write-up you’re following swears this box is “easy.” Easy? You’re starting to wonder if they were working in a different dimension.

Sound familiar? Yeah, you’re not alone. If your scanner feels like it’s screaming into the void, this guide’s for you.

We’re going to walk through what’s actually going on under the hood: NAT vs Bridged networking, why subnets matter (but not in a boring, textbook way), and that classic head-scratcher—“why can’t my VM see the target?”

No fluff, no acronym memorization marathons. Just a real-world mental model you can re-use in every lab from now until the exam (or your next gig).

Real Lab Layouts. Quick Fixes. Fewer Headaches.

I’ll show you actual lab setups that worked—and didn’t. Plus, you’ll get:

• A 60-second “connectivity sanity check” you can run right now
• Screenshot-worthy cheat cards for quick decision-making
• Fast, fix-it steps (because theory is great, but passing is better)

Let’s be honest: if you’re like most folks tackling OSCP or any pentesting lab, you’re probably juggling study time with work, family, sleep (optional), or side gigs. You don’t have hours to waste wondering if you broke the VM or the VM broke you.

By the end of this guide, your boxes won’t just boot up—they’ll actually see the targets you’re meant to break into.

Because no one wants to fail a scan because they forgot VMware defaults to NAT.

Let’s fix that.

---

---

1. Why Your VM Can’t See the Target (Even Though the Internet Works)

The cruel thing about virtual networking is that it fails silently. Your Kali VM happily browses YouTube, but the vulnerable machine on the same laptop might as well live on Mars.

When I first prepped for OSCP, I lost an entire Saturday because my VM could resolve google.com but not the “easy” box sitting inches away on my SSD. I tweaked nmap flags, changed wordlists, even rebooted three times before noticing the boring truth: my attacker and my target were on entirely different networks.

As attacks increase globally—some reports show weekly attacks per organization averaging over 1,600 in 2024 (Source, 2025-07)—solid lab hygiene isn’t just about passing an exam. It’s how you practice moving through real environments without sloppy mistakes.

Typical symptoms that scream “networking, not skill issue”:

• Your attacking VM has internet access but cannot ping the target VM.
• The target has an IP like 192.168.56.101, while your attacker shows 10.0.2.15.
• Hydra/Metasploit sessions time out, even though the same exploit works fine on other people’s write-ups.
• Host OS can reach the target, but the VM attacker cannot (or the reverse).

None of that means you’re bad at hacking. It usually means three things aren’t aligned:

1. Virtual network mode (NAT vs bridged vs host-only)
2. Subnets and IP ranges
3. Gateways and routes

Once you grasp those three, the question shifts from “Why is this box impossible?” to “Which of these two settings did I forget?”. That’s a much calmer place to work from.

2. Networking 101 vs Bridged vs Host-Only: The Simple Mental Model

Forget the fancy terms for a moment. Picture three types of neighborhoods for your VM:

• NAT: Your VM lives behind your host like a teenager borrowing the family Wi-Fi. It can reach the internet, but strangers can’t easily knock on its door.
• Bridged: Your VM is a full-blown neighbor on the same street as your physical machines. It gets its own IP from the router and can be reached like any other box.
• Host-Only / Isolated: A private cul-de-sac where only your host and certain VMs can talk. No direct internet, no outside traffic.

Most hypervisors reflect this model:

• VirtualBox calls them NAT, Bridged Adapter, Host-Only Adapter, and NAT Network.
• VMware Workstation / Fusion offer NAT, Bridged, and Host-Only configurations.
• Proxmox VE and libvirt on Linux expose similar ideas via virtual bridges and NATed networks.

Vendor docs describe NAT as the simplest way for a VM to access external networks, hiding it behind the host while bridged mode makes the VM directly visible on the physical network and reachable by other devices (Source, 2013-01; Source, 2024-10).

2.1 NAT vs Bridged vs Host-Only at a Glance

2.2 Money Block #1 – Decision Card: When Each Mode Makes Sense

Once you see these as “neighborhoods” instead of intimidating menu options, the question “Why can’t my VM see the target?” becomes “Which neighborhood did I accidentally put one of them in?” That’s solvable.

3. Subnets in 10 Minutes: Are You Even on the Same Network?

Modes decide who is allowed to talk. Subnets decide who even knows the other exists.

A subnet is just a slice of IP space that says, “All addresses from here to here are neighbors.” If your attacker is 10.0.2.15 and your target is 192.168.56.101, they are on different streets entirely. No amount of scan flags will change that.

The mask—things like /24 or 255.255.255.0—tells you how big that street is. In day-to-day hacker labs, you’ll mostly see:

• 10.0.2.0/24 – common for VirtualBox NAT defaults
• 192.168.56.0/24 – common for VirtualBox host-only networks
• 192.168.0.0/24 or 192.168.1.0/24 – many home routers

3.1 Quick Subnet Cheatsheet for Home Labs (2025)

CIDR	Usable host IPs	Typical use
/30	2	Point-to-point links, tiny VPN setups
/29	6	Small cloud lab segments
/24	254	Default for most home and VM networks
/16	65,534	Too big for most labs; noisy scans

One night, I accidentally pointed my scanner at a /16 lab range over a hotel Wi-Fi. The scan estimate jumped to “several hours,” my fan spun like a drone, and I learned very quickly why people talk about narrowing your scope.

3.2 Money Block #2 – Mini Subnet Size Calculator

Show me the nerdy details

Under the hood, that calculator uses the basic formula 2^(32 - mask) - 2 to estimate usable hosts in an IPv4 subnet. We subtract two for the network and broadcast addresses, which traditionally aren’t assigned to hosts. In many hacker labs, especially /24 ranges, remembering “about 250 hosts” is enough to decide whether to scan the whole thing or tighten your target. In larger corporate ranges, smart scoping and host discovery matter more than raw CIDR math.

4. Practical Hacker Lab Layouts in 2025 (Home, Laptop, Cloud)

Now that you have the mental model, let’s turn it into real-world lab layouts. In 2025, a lot of people mix local VMs, provider labs (Hack The Box, OffSec), and cloud VMs from AWS, Azure, or DigitalOcean. The trick is designing something reusable that doesn’t break every time you toggle a VPN.

4.1 Single-Laptop “Hotel Room” Lab

Imagine you’re traveling with only a laptop and spotty hotel Wi-Fi. A solid minimal setup looks like this:

• Kali / attacker VM on NAT for internet access.
• One or more target VMs on a Host-Only or isolated network.
• Optional router VM (like pfSense) with two NICs (NAT + host-only) to act as the gateway.

This keeps noisy scans away from the hotel network, while still letting you update tools and grab wordlists. I’ve done entire OSCP-style weekends like this with nothing but a laptop stand and a suspicious amount of coffee.

4.2 Home Lab with Realistic Bridged Targets

At home, you can push things closer to “real production”:

• Attacker VM: Host-Only + NAT (two NICs)
• Targets: Either Host-Only (for isolated labs) or Bridged (for realistic LAN scenarios)
• Optional hardware firewall or an old mini-PC running OpenWrt or pfSense

Using bridged mode, your targets get addresses from your home router, just like your phone and TV. Docs for enterprise virtualization note that bridged mode makes VMs appear directly on the same external network as the hypervisor, ideal when they must be easily accessible to existing physical machines (Source, 2024-10).

4.3 Localizing for Korea: KT/SKB/LGU+ Reality Check

If you’re in South Korea on a typical fiber line from KT, SKB, or LGU+, there’s a good chance you have:

• An ISP-provided modem/router doing NAT
• Your own Wi-Fi router chained behind it (sometimes another NAT)
• A laptop running VirtualBox or VMware on Wi-Fi

That’s at least one layer of NAT, sometimes two. If your VM is in NAT mode on top of this, you now have “NAT inside NAT”, which can make inbound connections awkward. Before you blame Kali, check whether your ISP box is in bridge mode or router mode, and whether your own router is the one handing out addresses. A five-minute look at the admin page can save you hours of “why does my port-forward never reach the lab?” frustration.

Short Story: The Night Before the Exam

Short Story: The night before a friend’s OSCP exam, he messaged me in full panic. “I can’t reach half my practice boxes. I think the VPN is broken.” For two hours he cycled through ticket responses, Reddit threads, and increasingly desperate traceroutes. When we finally screenshared, the issue jumped out in seconds: his Kali VM was in NAT mode, but his VPN client was on the host.

So the VPN tunnel and the scans lived on different planets. We flipped Kali to bridged, made sure it got an IP from the same subnet as the host, and suddenly every target lit up in his arp table. No exploit changed. Just the wiring. He passed a few days later, not because he became a better hacker overnight, but because his packets finally took the right path.

5. Fixing Your Setup: When to Switch NAT, Bridged, or Host-Only

Let’s turn this into a systematic repair process. The goal: decide which mode each VM should use based on the job it has today.

5.1 VirtualBox on Windows 11 (2025) – Common Patterns

In VirtualBox, the most common fixes for “can’t see target” are:

• Ensure both attacker and target share either the same Host-Only network or the same Bridged network.
• If you need both internet and an isolated lab, give the attacker two NICs: one NAT, one Host-Only.
• If your host must access a web app on the target, put target on Host-Only and bridge the host into that network using the VirtualBox host-only adapter.

5.2 VMware Workstation / Fusion – Performance and Control

VMware’s NAT vs bridged performance is usually fine for labs, but some users note upload speed drops on NAT in certain cases (one test saw roughly 40% slower uploads) (Source, 2021-01). For most OSCP-style work, that’s not your bottleneck. What matters more is:

• Use Bridged when you want the VM to behave like a physical host on your LAN.
• Use NAT for “contained” attacker boxes or where your VPN lives on the host.
• Reserve Host-Only for offline vulnerable boxes you never want exposed.

5.3 Proxmox / libvirt – Bridges and virbr0

On Linux, tools like libvirt often create a default NAT network via virbr0, which lets VMs use the host’s interface for outbound traffic but keeps them unreachable from outside systems by default (Source, 2024-10). To make a VM look like a real host on your LAN, you attach it to a bridge bound to a physical NIC.

5.4 Money Block #3 – Eligibility Checklist: Is It Safe to Use Bridged Mode?

6. Step-by-Step: Debugging “No Route to Target” Like an Adult

Here’s the part most people secretly want: a flowchart you can follow half-asleep at 3 a.m. to figure out why your VM can’t reach the target.

6.1 The 8-Step Connectivity Checklist

1. Grab IP info on both machines. On Linux, ip a; on Windows, ipconfig.
2. Compare subnets. Are the first three octets the same in a /24 lab (192.168.56.x)?
3. Check default gateways. Does each VM point to a gateway that can actually reach the other network?
4. Ping the target from attacker. If that fails, try pinging the gateway first.
5. Ping attacker from target. If only one direction fails, look for local firewalls.
6. Check host ↔ VMs. Can your host reach the target’s IP? The attacker’s?
7. Check the hypervisor’s mode. Confirm NAT vs bridged vs host-only for each NIC.
8. Trace the route. Use traceroute or tracert to see where packets die.

I once watched a student spend three days chasing a “strange IDS rule” that was “dropping packets.” Turned out his target and attacker were on different host-only networks inside VirtualBox. No exotic intrusion detection. Just two small clouds that never touched.

6.2 Simple ARP and Port Checks

• Use arp -a to see whether your attacker even knows the MAC address of the target.
• Run nc -vz target 80 or telnet target 80 to check connectivity to a specific port.
• Use ss -lntp or netstat -ano on the target to verify the service is actually listening.

7. Double NAT, VPN Clients, and Cloud Labs That Ghost Your Packets

The moment VPNs and cloud labs enter the story, routing gets more interesting. Many reports on recent cloud breaches point to misconfigurations and weak network segmentation as part of attackers’ playbooks (Source, 2025-07; Source, 2025-07). Getting this right in your lab builds muscle memory for avoiding the same mistakes in production.

7.1 Double NAT in the Wild

A common pattern:

• Home router: NAT to your ISP
• Your own router: another NAT to your devices
• Hypervisor: NAT for the VM

By the time your VM sends a packet, it’s wrapped in multiple private addresses. Outbound connections usually still work; inbound ones get messy. Port forwarding becomes a matryoshka doll situation.

7.2 VPN Client on Host vs VM

Decision time:

• VPN on host, attacker on NAT: VM traffic goes through host’s VPN. Simple, but your VM may see VPN IPs, not local ones.
• VPN on attacker VM itself: More realistic for exam labs like OSCP, where Kali runs the VPN client.

Some virtualization docs note that under certain client-to-site VPN setups, bridged mode can even stop working as expected, forcing creative NAT or routing workarounds (Source, 2024-10). So test this early—preferably before exam week.

7.3 Money Block #4 – Quote-Prep List for Cloud Lab Pricing

8. Misconfigurations, Ethics, and What Real Breaches Teach About Lab Design

It’s tempting to think of your lab as a toy universe with no consequences. But the skills you rehearse here are the same ones you’ll use when someone’s payroll system or patient data is on the line.

Recent threat reports show that global cyber attacks climbed significantly in 2024, with weekly attacks per organization averaging over 1,600 and a large majority of incidents still tied to human error (Source, 2025-07). Another 2025 review of major cloud incidents highlights how misconfigurations, exposed credentials, and poor segmentation let attackers move laterally once they’re in (Source, 2025-07).

Your lab is where you practice not being that misconfiguration.

• When you scatter bridged, NAT, and host-only networks at random, you train yourself to accept “mystery wiring.”
• When you document routes, subnets, and gateways carefully, you’re preparing for environments where regulators and auditors care about every hop.
• When you isolate truly dangerous tests (e.g., malware) into host-only or fully offline segments, you’re modeling responsible behavior.

Think of it like insurance: you wouldn’t ask for insurance quotes or compare coverage tiers after a fire. You design your network and your processes up front so that when something weird happens, you already know which subnet, which VM, and which log file to look at.

💡 See a practical VM networking walkthrough

FAQ

1. Should I use NAT or bridged networking for OSCP-style labs?

For most OSCP-style VPN labs, it’s simpler to run the VPN client inside your attacker VM and keep that VM on NAT or a lab-specific virtual network. Bridged mode is helpful when you need your VM to behave like a real host on your LAN, but it also expands your attack surface. Start with NAT for the attacker and host-only for local targets, then move to bridged only when the lab genuinely requires it. 60-second action: Check your exam provider’s setup guide and match their recommended pattern before experimenting.

2. Why can my VM reach the internet but not the vulnerable target?

This usually means your VM can reach its default gateway (and thus the internet), but the target lives on a different subnet or isolated network that your routes don’t cover. Common culprits include the attacker on NAT and the target on host-only, or the attacker using a VPN while the target does not. 60-second action: Write down both IPs and masks, confirm whether the first three octets match in a /24 setup, and adjust the network mode if they don’t.

3. I’m behind carrier-grade NAT. Can I still run a home hacking lab?

Yes. Carrier-grade NAT mainly affects inbound connections from the wider internet to you. For local labs where all machines live on your laptop or home router, you can use host-only and NAT networks without issue. If you want to expose a lab service to the internet (not generally recommended), you’ll need a VPS, port-forwarding-friendly provider, or a VPN tunnel. 60-second action: Decide whether your current lab really needs external inbound access; if not, keep everything on host-only or NAT and move on.

4. Does bridged mode make my home network less safe?

It can, if you drop intentionally vulnerable VMs directly into the same subnet as devices you care about. In bridged mode, your VM looks like any other LAN host, so malware or misconfigurations can potentially affect neighbors. Proper firewalls, guest VLANs, and limited exposure help, but the safest pattern is still to keep “broken on purpose” VMs on isolated networks wherever possible. 60-second action: List the devices on the same subnet as your bridged VM; if any are sensitive, consider moving the lab to host-only with a router VM.

5. How long should it take to debug a typical “no route to target” issue?

Once you’re comfortable with the checklist in Section 6, most connectivity problems should take 15–30 minutes or less to diagnose. If you’ve spent more than an hour without checking subnets, gateways, and network modes, you’re probably troubleshooting the wrong layer. 60-second action: Set a timer the next time you debug connectivity; if you hit 30 minutes without insight, restart from the eight-step checklist.

9. Conclusion: Your Next 15 Minutes of Networking Practice

We all start somewhere. For me, it began with a lonely little nmap scan and a VM that, no matter how hard it tried, just could not see its target. Classic case of “it works on my machine”—except it didn’t.

That kicked off a journey through the tangled mess of NAT, bridged, and host-only network settings. I learned (often the hard way) that your VM’s ability to reach anything at all depends less on the OS and more on the tiny dropdown buried three menus deep in your hypervisor. Subnets? Turns out they’re the bouncers at the club, deciding which IPs are “in the neighborhood” and which get denied at the door. And don’t even get me started on double NAT or the VPN client that silently re-routed my entire lab through Sweden.

But here’s the twist: the real skill isn’t memorizing where to click or what option to check. It’s learning to think in paths—visualizing how traffic flows from attacker to target, one hop at a time. Once you can trace those paths on a napkin (or the back of a receipt, or your hand in a pinch), the hypervisor UI just becomes another way to describe the architecture you already understand.

---

🧠 15-Minute Practice Plan

Want to solidify it? Try this quick session:

1. Sketch Your Lab: Draw your attacker, targets, router(s), and the internet (yes, stick figures are fine).
2. Label Everything: For each VM or device, note the IP address, subnet mask, gateway, and what network mode it’s in (NAT, bridged, host-only, etc).
3. Run the 8-Step Checklist: From Section 6—pick one target and walk through all eight connectivity checks.
4. Flip & Predict: Change one VM’s network mode (say, NAT to host-only) and write down what you expect to happen. Then test it and see if you were right. Bonus points if you scream “WHY?!” at your screen at least once.

---

Trust me: once you’ve broken your own lab five times in a row, you stop fearing the settings and start understanding them. That’s when real learning begins.

And yes, your VMs are conspiring against you. But at least now, you know how to fight back.

Last reviewed: 2025-11; sources: VirtualBox Manual, Red Hat virtualization guides, recent cyber threat and cloud-breach reports from 2024–2025.

networking 101 for hackers, virtualbox nat vs bridged, subnets for hacking labs, vm can’t see target troubleshooting, NAT vs bridged networking

🔗 Safe Hacking Lab at Home Posted 2025-11-20 🔗 Post OSCP Roadmap Posted 2025-11-19 🔗 24-Hour OSCP Exam Posted 2025-11-18 🔗 Free OSCP Prep Resources Posted 2025-11-18 🔗 OSCP vs CEH vs Security