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:


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


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


all 3 conditions fail.


  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

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

(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 and receive a reply (provided a software firewall is not interfering).

Likewise, one should be able to ping the host at 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:         On-link    266         On-link    266         On-link    266         On-link    266         On-link    266

After connecting to the VPN:         On-link    266         On-link    266         On-link    266

The VPN client removes the following lines:         On-link    266         On-link    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 MASK METRIC 266
C:\>route ADD MASK 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".

  • 6
    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
  • 3
    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
  • Yup, both checking the "Allow local (LAN) access" and the adding route table are required. – Mine Feb 21 '20 at 5:31
  • There is actually a simpler way to bypass VPN, and it doesn't require any priviledges over VPN, either. When creating the Host Adapter (File/Host Network Manager...), use an IP range outside private network range (as per superuser.com/a/838622/415177), e.g.: Adapter / IPv4 Address:, Adapter / IPv4 Network Mask:, DHCP Server / Server Address:, DHCP Server / Server Mask:, DHCP Server / Lower Address Bound:, DHCP Server / Upper Address Bound: – yannick1976 Apr 4 '20 at 21:29

How i use my Windows host VPN in guest Linux machine

1-) Open up your VPN settings. Specify some local port numbers.

vpn settings

2-) Open up your virtual machine settings. Make sure nertwork is attached to NAT. Then click advenced and port fowarding

enter image description here

3-) Click to add rule and enter the same port numbers you have specified in your VPN

port fowarding

4-) Start your Virtual Machine. Go to your Network Settings. Select manual and enter (Default virtualbox NAT Gateway) on ip adress and the ports we have specified before.

linux network settings

5-) Open up firefox and go to whoer.net and check if your VPN works. ALL DONE


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