I have an Oracle Linux guest running a web server in VirtualBox on a Windows 7 Host. I need to set the networking up so that I can do 3 things:
- the host can connect to the guest through a browser and ssh
- the guest can talk to other servers on the internal network through the host's VPN
- the guest can reach the outside internet
I've read a few answers and tried a few configurations, and here's what happens:
Bridged
- host cannot reach guest
- guest cannot see through VPN
- guest can reach internet
NAT
- host cannot reach guest
- guest can see through VPN
- guest cannot reach internet
Host-Only
all 3 conditions fail.
NAT-Network
- host cannot reach guest
- guest can see through VPN
- guest cannot reach internet
I should also point out that sometimes the host is connected through a VPN while other times it is simply plugged directly into the corporate network. When it is plugged directly in, a bridged adapter satisfies all 3 conditions. Ideally, there would be a configuration that satisfies all 3 conditions regardless whether there's a VPN or a direct connection.
Best Answer
I had the exact same problem, and saw it through to resolution, so I'm happy to explain the problem and solution in detail.
Without Involving a VPN
It is important to understand the configuration that is required in order to meet your requirements without involving a VPN. Also, this information assumes that no software firewall is interfering, neither on the host nor the guest.
Without a VPN, this is normally solved by creating two network adapters in the virtual machine's configuration.
The first adapter must be set to
NAT
mode, which enables the guest to access network resources (including the Internet) through the host's network interface.The second adapter must be set to
Host-only
, which enables bidirectional communication between the host and the guest.This adapter is slightly more complex to setup than the first, because it requires modifying VirtualBox's global networking preferences in order to configure the host-only adapter (note: this requires Administrator privileges).
In VirtualBox, go to
File -> Preferences -> Network
. Click theHost-only Networks
tab and click the little+
icon to add a new adapter. You will be prompted to elevate VirtualBox's permissions.Filling-out the
Adapter
tab is mandatory; it should look something like this (ignore the adapter labeled#2
; that's used for something unrelated):The values on the
DHCP
server tab are optional. If you're intending to hard-code the IP address for this adapter within the guest's networking configuration, then these values are unnecessary. If, on the other hand, you intend to use DHCP, the values might look something like this:The last step with regard to configuring VirtualBox is to go back into the VM's network configuration and add the second adapter, which references the host-only adapter that we just created:
Now, in the guest operating system, the network must be configured to utilize these two network interfaces.
On Debian or Ubuntu GNU/Linux, the configuration is as simple as modifying
/etc/network/interfaces
to look like this:(the purist may prefer to utilize the
/etc/network/interfaces.d
directory instead, but that's beyond the scope of this explanation)Restart the guest's networking services, or more simply, restart the entire guest VM, and everything should "just work".
At this point, one should be able to ping the guest VM at
192.168.56.101
and receive a reply (provided a software firewall is not interfering).Likewise, one should be able to ping the host at
10.0.2.2
. This IP address seems to be "hard-coded" into VirtualBox's NAT implementation, or at least specified via some non-obvious configuration directive, and there is little information available as to its origin. But, alas, "it just works".Given this configuration, all three conditions outlined in your question are met.
Enter: the VPN
But, here's the rub. Introducing the VPN causes a show-stopping problem (well, depending on the specific VPN and its configuration).
Modern VPNs are capable of Split Tunneling, which is required for the aforementioned VirtualBox configuration to function per your three requirements. For (good) security reasons, split tunneling is often disabled, and this is precisely the problem in your case (and mine).
When you connect to the VPN, the VPN client (Cisco AnyConnect Secure Mobility Client, 3.1.02026, in my case) examines the host computer's routing tables, remembers them, and then paves-over them with values that typically come from some centrally-managed location (i.e., even with local Administrator privileges, it is impossible to override the settings).
You can examine the routing tables for yourself by opening
command.exe
(on Windows):Before connecting to the VPN, the routing table contains crucial entries that allow this VirtualBox configuration to function correctly. Connecting to the VPN causes these entries to be removed, which prevents communication between the host and the guest.
(There are many other entries, which I have omitted here, as they are irrelevant to the root cause for this behavior.)
Before connecting to the VPN:
After connecting to the VPN:
The VPN client removes the following lines:
Without those last two entries, the host and the guest cannot communicate, and this is precisely the intended behavior when split tunneling is disabled in the VPN configuration.
Normally, these two commands would restore those routes:
But the VPN client remains vigilant: it intercepts attempts to modify the routing table. My client seems to allow the second entry, but not the first one. (And it may pave-over both on some periodic basis; I didn't test for that.)
If your specific VPN and its attendant configuration allow for split tunneling to be enabled, it is typically switched-on like this:
Upon disconnecting from the VPN, well-behaved VPN clients will restore the routing tables that were in place prior to connecting. My VPN client seems to do this reliably, which is beneficial because it means that the guest VM does not need to be restarted when I connect to, or disconnect from, the VPN. In such cases, the VM's secondary adapter is reset, but it re-acquires its IP address automatically and transparently, restoring communication between the host and guest almost immediately. Better yet, NFS mounts between the host and guest (I'm using CIFS mounts) remain connected across VPN connect/disconnect operations.
In the unlikely event that your VPN allows split tunneling, it may be a simple matter of enabling it, in which case, I would love to hear from you as to whether or not "everything just works".