DEV Community

Cover image for How Traffic Actually Moves Between Your Host and Virtual Machines
Arashad Dodhiya
Arashad Dodhiya

Posted on

How Traffic Actually Moves Between Your Host and Virtual Machines

#cybersecurity #network #linux #devops

Most cybersecurity beginners can build a lab.

They install:

  • Windows
  • VirtualBox
  • Kali Linux
  • Metasploitable

Everything works.

But then a question appears:

When I open http://192.168.56.10 from Windows, how does the traffic actually reach Kali?

Most tutorials stop at configuration.

Very few explain what happens behind the scenes.

Let's follow a real packet from start to finish.

The Lab Setup

My lab looks like this:

Windows Host
192.168.56.1

Kali Linux VM
192.168.56.10
Enter fullscreen mode Exit fullscreen mode

Inside Kali, Apache is running.

sudo systemctl start apache2
Enter fullscreen mode Exit fullscreen mode

Now from Windows I open:

http://192.168.56.10
Enter fullscreen mode Exit fullscreen mode

A webpage appears.

Simple.

But a lot happens in the background.

Step 1: The Browser Creates a Request

The journey begins inside the browser.

When you press Enter:

http://192.168.56.10
Enter fullscreen mode Exit fullscreen mode

the browser creates an HTTP request.

Something similar to:

GET / HTTP/1.1
Host: 192.168.56.10
Enter fullscreen mode Exit fullscreen mode

At this point, the browser has a question:

Where should I send this request?

Step 2: Windows Checks the Destination

Windows sees:

Destination:
192.168.56.10
Enter fullscreen mode Exit fullscreen mode

Now Windows checks its routing table.

Think of a routing table as a GPS system.

It answers:

Which network interface should carry this packet?

Windows notices:

192.168.56.10
Enter fullscreen mode Exit fullscreen mode

belongs to:

192.168.56.0/24
Enter fullscreen mode Exit fullscreen mode

which is the Host-Only network.

So Windows chooses the VirtualBox Host-Only Adapter.

Step 3: The Packet Leaves Windows

Now the packet leaves the browser.

Visual:

Browser
   │
   ▼
Windows TCP/IP Stack
   │
   ▼
Host-Only Adapter
Enter fullscreen mode Exit fullscreen mode

At this moment the packet has left the application and entered the networking layer.

Step 4: VirtualBox Acts Like a Switch

This is where many beginners get confused.

VirtualBox doesn't simply "connect" machines.

It behaves much like a network switch.

Visual:

Windows
192.168.56.1
      │
      ▼
VirtualBox Network
      │
      ▼
Kali
192.168.56.10
Enter fullscreen mode Exit fullscreen mode

The packet enters the virtual network created by VirtualBox.

VirtualBox examines the destination.

It sees:

192.168.56.10
Enter fullscreen mode Exit fullscreen mode

belongs to the Kali VM.

The packet is forwarded.

Step 5: Kali Receives the Packet

The packet arrives at:

eth1
192.168.56.10
Enter fullscreen mode Exit fullscreen mode

Remember:

ip a
Enter fullscreen mode Exit fullscreen mode

showed:

eth1
192.168.56.10
Enter fullscreen mode Exit fullscreen mode

This is Kali's Host-Only interface.

Visual:

Windows
      │
      ▼
VirtualBox
      │
      ▼
Kali eth1
Enter fullscreen mode Exit fullscreen mode

Now Kali knows:

Someone is trying to communicate with me.

Step 6: The Operating System Processes the Request

Kali receives the packet.

The Linux kernel examines it.

It notices:

Port 80
Enter fullscreen mode Exit fullscreen mode

Port 80 is commonly used by web servers.

Linux checks:

Which process is listening on Port 80?

The answer:

Apache
Enter fullscreen mode Exit fullscreen mode

The packet is handed over to Apache.

Step 7: Apache Generates a Response

Apache processes the request:

GET /
Enter fullscreen mode Exit fullscreen mode

and finds:

/var/www/html/index.html
Enter fullscreen mode Exit fullscreen mode

It reads the file and prepares a response.

Example:

HTTP/1.1 200 OK
Enter fullscreen mode Exit fullscreen mode

along with the webpage content.

The Return Journey

Most people only think about the request.

But responses travel too.

Now the path reverses.

Apache
   │
   ▼
Linux TCP/IP Stack
   │
   ▼
eth1
   │
   ▼
VirtualBox Network
   │
   ▼
Windows Host-Only Adapter
   │
   ▼
Browser
Enter fullscreen mode Exit fullscreen mode

The browser receives the HTML and renders the webpage.

You see the result instantly.

The Entire Packet Journey

Visualized from beginning to end:

Browser
   │
   ▼
Windows TCP/IP Stack
   │
   ▼
Host-Only Adapter
   │
   ▼
VirtualBox Virtual Switch
   │
   ▼
Kali eth1
   │
   ▼
Linux Kernel
   │
   ▼
Apache
   │
   ▼
index.html
Enter fullscreen mode Exit fullscreen mode

Response:

index.html
   │
   ▼
Apache
   │
   ▼
Linux Kernel
   │
   ▼
Kali eth1
   │
   ▼
VirtualBox Virtual Switch
   │
   ▼
Windows Host-Only Adapter
   │
   ▼
Browser
Enter fullscreen mode Exit fullscreen mode

Why This Matters in Cybersecurity

The exact same journey happens when using:

  • Burp Suite
  • Nmap
  • Metasploit
  • Nikto
  • Gobuster
  • SQLMap

For example:

nmap 192.168.56.10
Enter fullscreen mode Exit fullscreen mode

The packets follow the same path.

Only the payload changes.

Understanding packet flow helps you understand:

  • Network scanning
  • Exploitation
  • Reverse shells
  • Web application testing
  • Firewall behavior
  • Intrusion detection

Everything starts with packets moving between systems.

The Biggest Realization

Many beginners think:

Windows is opening Kali.

That's not what happens.

Windows and Kali are behaving like two separate computers connected by a network.

The fact that both systems happen to live on the same physical laptop is almost irrelevant.

The packet doesn't care.

It simply follows the network path.

Final Thoughts

When you open a webpage hosted inside a virtual machine, the request doesn't magically appear there.

It travels through multiple layers:

Application
↓
Operating System
↓
Network Interface
↓
Virtual Network
↓
Guest Operating System
↓
Target Service
Enter fullscreen mode Exit fullscreen mode

Once you understand this journey, virtualization becomes much easier to visualize.

And more importantly, you'll begin to understand what cybersecurity tools are actually doing behind the scenes.

Because whether you're browsing a webpage, scanning a host, or exploiting a vulnerability, everything ultimately comes down to packets moving from one machine to another.

Top comments (0)