DEV Community

alok-38
alok-38

Posted on

Rocky Linux VirtualBox VM Networking Setup & SSH Access Using Windows 11 with Smartphone Hotspot

#ssh #linux #hotspot #virtualmachine

SSH into Rocky Linux VM on VirtualBox (Windows 11 + Mobile Hotspot Setup)

When experimenting with Linux in a virtual machine, one of the most useful skills to learn is how to access the system remotely using SSH. If you're running a Rocky Linux VM inside VirtualBox on a Windows 11 host, things can feel a bit confusing—especially when your computer is connected to the internet through a smartphone hotspot instead of a traditional router. In this guide, I’ll walk through a simple and practical setup that allows you to configure networking for your Rocky Linux virtual machine and successfully SSH into it from your Windows 11 host. By the end, you’ll have a working setup that’s perfect for learning, testing, and managing your VM just like a real remote Linux server.

Set up

  • Host: Windows 11
  • Internet Source: Smartphone Hotspot
  • Guest: Rocky Linux (Headless – No GUI)
  • Virtualization: VirtualBox

Initial Objective

The goal was to:

  • Create a headless Rocky Linux VM

  • Ensure the VM has Internet access

  • Allow SSH access from Windows PowerShell

  • Verify networking using systematic diagnostic tests

VirtualBox Network Architecture

I configured two network adapters for this setup. At the time, I didn’t fully understand the reasoning behind it, but since the configuration worked, I proceeded with it. I plan to revisit this later and spend some time understanding the finer details of how the networking works.

Adapter 1 — NAT (Internet access)

Purpose:

  • Allows the VM to share the host's Internet connection.

Configuration:

Adapter 1 → NAT
Enter fullscreen mode Exit fullscreen mode

Inside the Rocky Linux VM, the network interface typically receives an address similar to:

10.0.2.15
Enter fullscreen mode Exit fullscreen mode

VirtualBox also provides a default gateway for this internal network:

10.0.2.2
Enter fullscreen mode Exit fullscreen mode

This setup ensures that the VM can download packages, update the system, and access the internet without needing any additional network configuration.

Adapter 2 — Host-Only Adapter (VM ↔ Host communication)

While the NAT adapter provides internet connectivity to the virtual machine, it does not allow the host system to directly initiate connections to the VM. This is where the Host-Only Adapter becomes useful.

The Host-Only Adapter creates a private network between the Windows host and the virtual machine. This network exists only within VirtualBox and does not depend on the external network or internet connection. In my setup, this private network is what enables me to SSH from the Windows host into the Rocky Linux VM.

Purpose:

  • Direct communication between Windows host and VM

  • Enables SSH access

Configuration:

Adapter 2 → Host-Only Adapter
Enter fullscreen mode Exit fullscreen mode

When this adapter is enabled, VirtualBox automatically creates a host-only network. The default network typically looks like this:

192.168.56.0/24
Enter fullscreen mode Exit fullscreen mode

Both the Windows host and the VM receive IP addresses within this network range. For example:

Windows host: 192.168.56.1
VM:           192.168.56.102
Enter fullscreen mode Exit fullscreen mode

This means the host machine can directly reach the VM using the assigned address, which makes SSH access simple and reliable.

Architecture Diagram

The following diagram illustrates how the different components in this setup are connected. The Windows host receives internet access through a smartphone hotspot, while the virtual machine uses two adapters — one for internet access and another for direct communication with the host.

                Internet
                    │
            Smartphone Hotspot
                    │
               Windows Host
            WiFi: 10.139.205.51
                    │
        ┌───────────┴───────────┐
        │                       │
    VirtualBox NAT        Host-Only Adapter
     (Internet)            (Local Access)
      10.0.2.x              192.168.56.x
        │                       │
        └────── Rocky Linux VM ──────┘
                 10.0.2.15
               192.168.56.102
Enter fullscreen mode Exit fullscreen mode

In simple terms:

  • Adapter 1 (NAT) allows the VM to access the internet.

  • Adapter 2 (Host-only) allows the Windows host to directly connect to the VM.

This dual-adapter setup is commonly used when you want a VM to behave like a real server that is both internet-enabled and locally accessible.

Network Verification Commands

Once the VM is running, it's useful to verify that both network adapters are active and correctly assigned IP addresses.

Check interfaces

Command:

ip a
Enter fullscreen mode Exit fullscreen mode

Purpose:

  • Lists all network interfaces

  • Shows assigned IP addresses

Result (truncated):

lo
enp0s3 → 10.0.2.15
enp0s8 → 192.168.56.102
Enter fullscreen mode Exit fullscreen mode

Meaning:

Interface Purpose
lo loopback
enp0s3 NAT adapter
enp0s8 Host-only adapter

From this output, we can confirm that both network adapters are active:

  • enp0s3 is connected to the NAT network, providing internet access.

  • enp0s8 is connected to the Host-only network, enabling communication with the Windows host.

This host-only IP address is the one that will be used when connecting to the VM via SSH.

Verify Routing Table

After confirming that both network interfaces are active, the next step is to verify how the system routes network traffic. In Linux, the routing table determines where outgoing network packets should be sent depending on their destination.

To view the routing table, run the following command inside the Rocky Linux VM:

ip route
Enter fullscreen mode Exit fullscreen mode

Truncated result:

default via 10.0.2.2 dev enp0s3
192.168.56.0/24 dev enp0s8
Enter fullscreen mode Exit fullscreen mode

This output shows the key routing rules that the system uses to decide how traffic should flow.

Route Purpose
default via 10.0.2.2 Internet gateway
192.168.56.0 host-only network

Connectivity Tests (Layer-by-layer)

Once the network interfaces and routing table are confirmed, the next step is to verify connectivity step by step. A good troubleshooting approach is to test the network layer by layer, starting from the closest network component and gradually moving outward.

The first component to test is the VirtualBox NAT gateway, which acts as the router that connects the VM to the outside network.

Test NAT Gateway 

ping -c 3 10.0.2.2
Enter fullscreen mode Exit fullscreen mode

Purpose:

  • Verify connection to VirtualBox NAT router

This command sends three ICMP packets to the NAT gateway. If the gateway responds, it confirms that the VM can successfully communicate with the VirtualBox networking layer.

A successful response indicates that the NAT adapter is functioning correctly and that the VM can reach its default gateway. This is an important first step because all external network traffic from the VM must pass through this gateway.

Test Host-only Network

After confirming that the NAT network is functioning correctly, the next step is to test connectivity between the Rocky Linux VM and the Windows host. This communication happens through the Host-only Adapter, which is responsible for enabling direct interaction between the host and the virtual machine.

Command:

ping -c 3 192.168.56.1
Enter fullscreen mode Exit fullscreen mode

Purpose:

  • Verify VM ↔ Windows host connectivity

This command attempts to send three ICMP packets to the host-only interface on the Windows machine (192.168.56.1). If the network is configured correctly, the host should respond to these requests.

Result:

100% packet loss
Enter fullscreen mode Exit fullscreen mode

This result indicates that the VM is unable to reach the Windows host over the host-only network.

At this point, we know that while the VM has internet connectivity through the NAT adapter, communication with the host system is not yet functioning as expected. This is an important discovery because SSH access relies on this host-only network, so resolving this connectivity issue will be necessary before proceeding further.

Diagnosing the Issue

Checking the interface state

Since the host-only ping test failed, the next step is to verify whether the corresponding network interface inside the VM is actually active. In this setup, the host-only adapter is mapped to the interface enp0s8.

To check the status of the interface, run:

ip link show enp0s8
Enter fullscreen mode Exit fullscreen mode

Result:

state UP
Enter fullscreen mode Exit fullscreen mode

Meaning:

  • The interface is active.

This confirms that the network interface itself is enabled and operational inside the VM. In other words, the failure of the previous ping test is not caused by the interface being down, which means the issue likely lies elsewhere in the network path—possibly at the host side or within the host-only network configuration.

Checking the Host-Side Network Configuration

Since the VM interface was confirmed to be active, the next step was to verify whether the Windows host actually had the host-only network adapter configured. If the host-side adapter was missing or misconfigured, the VM would have no endpoint to communicate with.

To check this on Windows, I opened the command prompt and ran:

ipconfig
Enter fullscreen mode Exit fullscreen mode

Found:

Ethernet adapter Ethernet 4
IPv4 Address: 192.168.56.1
Enter fullscreen mode Exit fullscreen mode

This output confirms that Windows has a VirtualBox Host-Only Ethernet Adapter configured and assigned the expected IP address within the host-only network range.

At this point, both sides of the network appeared to be configured properly:

  • The VM interface (enp0s8) was active

  • The Windows host adapter had the correct IP address

However, the earlier ping test still failed. This suggested that the problem was not with the network configuration itself, but likely related to something else — such as Windows firewall rules blocking ICMP traffic.

Real Connectivity Test — SSH

While the earlier ping test suggested that host-only connectivity might not be working, the real objective of this setup was SSH access. Therefore, the most reliable way to verify the network was to attempt an actual SSH connection from the Windows host to the Rocky Linux VM.

From Windows PowerShell, I executed the following command:

ssh alok@192.168.56.102`
Enter fullscreen mode Exit fullscreen mode

If the network and SSH service were functioning correctly, this command should establish a remote shell session with the virtual machine.

[alok@localhost ~]$
Enter fullscreen mode Exit fullscreen mode

This prompt indicates that the SSH connection was successfully established and that the terminal session is now running on the Rocky Linux virtual machine.

Meaning:

✅ SSH server running
✅ Host-only network working
✅ Authentication successful

Despite the earlier ICMP ping failure, the SSH test confirms that the host-only network is functioning correctly for actual application traffic. This means the VM can now be accessed just like any other remote Linux server.

The system behaves like a real remote Linux server.

Real Connectivity Test — SSH

Although earlier ping tests suggested a possible issue with host-only connectivity, the ultimate goal of this setup was to access the VM via SSH. The most practical way to verify that everything is working is therefore to attempt an actual SSH login from the Windows host.

From Windows PowerShell, the following command was executed to connect to the Rocky Linux virtual machine:

Command executed from Windows PowerShell:

ssh alok@192.168.56.102
Enter fullscreen mode Exit fullscreen mode

If the network configuration and SSH service are functioning correctly, this command should establish a remote shell session with the VM.

[alok@localhost ~]$
Enter fullscreen mode Exit fullscreen mode

This prompt confirms that the SSH connection was successfully established and that the session is now running on the Rocky Linux system inside the VirtualBox VM.

Meaning:

✅ SSH server running
✅ Host-only network working
✅ Authentication successful

Even though the earlier ICMP ping test failed, the successful SSH connection demonstrates that the host-only network is operational for real application traffic.

The system behaves like a real remote Linux server.

Final Working Network State

Component Status
VirtualBox NAT ✅ Working
Host-only adapter ✅ Working
VM networking ✅ Correct
Routing ✅ Correct
SSH access ✅ Working
Internet access ✅ Available

Lessons Learned

NAT vs Bridged vs Host-only

Mode Purpose
NAT Internet access
Host-only VM ↔ host communication
Bridged VM appears as separate device on LAN

For hotspot connections, NAT is the most reliable.

Key Commands Used

Linux

ip a
ip route
ip link show enp0s8
ping -c 3 <ip>
systemctl status sshd
Enter fullscreen mode Exit fullscreen mode

Windows

ipconfig
ssh user@vm-ip`
Enter fullscreen mode Exit fullscreen mode

Recommended next steps

Connecting three VM's together and practice:

  • SSH key authentication

  • Linux networking

  • Ansible automation

  • Docker

  • Kubernetes clusters

When ready!

Top comments (0)