37

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:

  1. the host can connect to the guest through a browser and ssh
  2. the guest can talk to other servers on the internal network through the host's VPN
  3. the guest can reach the outside internet

I've read a few answers and tried a few configurations, and here's what happens:

Bridged

  1. host cannot reach guest
  2. guest cannot see through VPN
  3. guest can reach internet

NAT

  1. host cannot reach guest
  2. guest can see through VPN
  3. guest cannot reach internet

Host-Only

all 3 conditions fail.

NAT-Network

  1. host cannot reach guest
  2. guest can see through VPN
  3. 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.

  • A VPN connection usually has its own adapter, so my first thought is that you'd have to bridge it to the VPN adapter (when attached to the VPN). – Ƭᴇcʜιᴇ007 Oct 15 '15 at 15:46
  • I bridged the VM to the VPN adapter and it doesn't get an IP address – ewok Oct 15 '15 at 16:11
  • Can you say whether this is a layer2 or layer3 adapter? – MariusMatutiae Oct 15 '15 at 16:46
  • @MariusMatutiae sorry, not sure what you mean. – ewok Oct 15 '15 at 16:47
  • Which kind of VPN is it? – MariusMatutiae Oct 15 '15 at 16:53
56

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.

Adapter 1: NAT

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 the Host-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):

Networking Preferences 1

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:

Networking Preferences 2

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:

Adapter 2: Host-only

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:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp

# The secondary network interface
auto eth1
iface eth1 inet static
     address 192.168.56.101
     netmask 255.255.255.0

(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):

C:\>route print

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:

     192.168.56.0    255.255.255.0         On-link      192.168.56.1    266
     192.168.56.1  255.255.255.255         On-link      192.168.56.1    266
   192.168.56.255  255.255.255.255         On-link      192.168.56.1    266
        224.0.0.0        240.0.0.0         On-link      192.168.56.1    266
  255.255.255.255  255.255.255.255         On-link      192.168.56.1    266

After connecting to the VPN:

     192.168.56.1  255.255.255.255         On-link      192.168.56.1    266
        224.0.0.0        240.0.0.0         On-link      192.168.56.1    266
  255.255.255.255  255.255.255.255         On-link      192.168.56.1    266

The VPN client removes the following lines:

     192.168.56.0    255.255.255.0         On-link      192.168.56.1    266
   192.168.56.255  255.255.255.255         On-link      192.168.56.1    266

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:

C:\>route ADD 192.168.56.0 MASK 255.255.255.0 192.168.56.1 METRIC 266
C:\>route ADD 192.168.56.255 MASK 255.255.255.255 192.168.56.1 METRIC 266

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:

Cisco VPN client: allow access to LAN resources

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".

  • 5
    Thank you very much for all the effort in this answer (images and all). It helped a lot your explanation! – Edenshaw May 27 '16 at 14:52
  • Well done, Ben! This helped me understand my problems with VPN and helped me articulate my case clearly in my incident report to IT! – Mark Maglana Sep 23 '17 at 13:36
  • 1
    FYI, I have access to the "Allow local (LAN) access" feature on AnyConnect and I can confirm that ticking this checkbox does not prevent the routes from being deleted. – Lqueryvg Nov 24 '17 at 15:29

protected by Community Mar 6 '18 at 19:16

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.