Ubuntu – Route all Ubuntu traffic to Windows 7 Virtualbox with Juniper VPN

If your VPN gateway only advertises routes to specific networks, openconnect communicates this information to your vpnc-script by setting the CISCO_SPLIT_INC environment variables:

#* CISCO_SPLIT_INC              -- number of networks in split-network-list
#* CISCO_SPLIT_INC_%d_ADDR      -- network address
#* CISCO_SPLIT_INC_%d_MASK      -- subnet mask (for example: 255.255.255.0)
#* CISCO_SPLIT_INC_%d_MASKLEN   -- subnet masklen (for example: 24)

On Ubuntu, you can edit /etc/vpnc/vpnc-script and try overriding CISCO_SPLIT_INC to an empty string so that vpnc-script sets up tun0 as the system's default route:

# =========== script (variable) setup ====================================

# >>>INSERT THIS LINE:
CISCO_SPLIT_INC=

PATH=/sbin:/usr/sbin:$PATH

OS="`uname -s`"

The gateway has separate settings for its split tunnel includes and for routing. It is possible that the gateway's routing rules were only set up to allow traffic destined for the networks listed in the split tunnel setting, even if you add other routes (or a default route) on the client side. You'll have to try it and see.

On OpenConnect for Android, there is a per-VPN profile option to override the split tunnel setting. Set Split Tunnel Mode to "On - DNS uses VPN" and set Split Tunnel Networks to "0.0.0.0/0". This is equivalent to the vpnc-script change on Ubuntu.

If none of this works using your company's existing AnyConnect gateway, you might consider setting up a cheap VPS and running your own private ocserv installation.

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

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:

# 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:

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