Ubuntu – How to make VirtualBox guests share the host’s VPN connection

networkingrouterroutingtunnelvpn

Question

When I start my VPN on my ubuntu desktop computer which acts as a router, the attached subnet loses internet connectivity, but is still accessible (LAN). Ideally, I would like to know how to enable the attached subnet to re-gain internet access by routing through the VPN tunnel when the VPN is active.

Context

I have the following network layout:

subnet 172.16.0.0/20 on eth0 for my VirtualBox virtual machines.

subnet 192.168.0.0/24 on eth0:0 which connects to gateway 192.168.0.1 which has internet access.

This is shown in the /etc/network/interfaces file:

auto lo
iface lo inet loopback

# This is the subnet dedicated to VB
auto eth0
iface eth0 inet static
    address 172.16.0.1
    netmask 255.255.0.0
    gateway 192.168.0.164
    dns-nameservers 8.8.8.8

# normal DHCP internet
auto eth0:0
iface eth0:0 inet static
    address 192.168.0.164
    netmask 255.255.255.0
    dns-nameservers 8.8.8.8
    gateway 192.168.0.1

The packets on the eth0 are forwarded through eth0:0 with masquerading and normal internet connectivity is fine. However when I start my VPN tunnel on this router, internet connectivity is lost for the VMs on the eth0 subnet (yet remains for the router).

Below is the output of ifconfig when the tunnel is active:

eth0      Link encap:Ethernet  HWaddr 00:1f:bc:01:c3:ab  
          inet addr:172.16.0.1  Bcast:172.16.255.255  Mask:255.255.0.0
          inet6 addr: fe80::21f:bcff:fe01:c3ab/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:165426 errors:0 dropped:0 overruns:0 frame:0
          TX packets:182601 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:208264321 (208.2 MB)  TX bytes:16660945 (16.6 MB)
          Interrupt:16 

eth0:0    Link encap:Ethernet  HWaddr 00:1f:bc:01:c3:ab  
          inet addr:192.168.0.164  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:16 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:381963 errors:0 dropped:0 overruns:0 frame:0
          TX packets:381963 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:22755054 (22.7 MB)  TX bytes:22755054 (22.7 MB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.10  P-t-P:10.8.0.9  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

I suspect that the solution will have something to do with the routing table. It shows the following when the tunnel is active:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.8.0.9        128.0.0.0       UG    0      0        0 tun0
default         192.168.0.1     0.0.0.0         UG    100    0        0 eth0
10.8.0.0        10.8.0.9        255.255.255.0   UG    0      0        0 tun0
10.8.0.9        *               255.255.255.255 UH    0      0        0 tun0
37.139.23.49    192.168.0.1     255.255.255.255 UGH   0      0        0 eth0
128.0.0.0       10.8.0.9        128.0.0.0       UG    0      0        0 tun0
link-local      *               255.255.0.0     U     1000   0        0 eth0
172.16.0.0      *               255.255.0.0     U     0      0        0 eth0
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0

and the following when the tunnel inactive:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    100    0        0 eth0
link-local      *               255.255.0.0     U     1000   0        0 eth0
172.16.0.0      *               255.255.0.0     U     0      0        0 eth0
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0

Virtualbox configuration for Vms:

enter image description here

One of the VMs /etc/network/interfaces file:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
        address 172.16.0.3
        netmask 255.255.0.0
        network 172.16.0.0
        broadcast 172.16.255.255
        gateway 172.16.0.1
        dns-nameservers 8.8.8.8

Best Answer

This will not work in a Bridged Networking setup. From the VirtualBox documentation:

Bridged networking

This is for more advanced networking needs such as network simulations and running servers in a guest. When enabled, VirtualBox connects to one of your installed network cards and exchanges network packets directly, circumventing your host operating system's network stack.

Since your virtual machines are using eth0 directly, they are unaware of the tun0 interface to the tunnel running over it. You will need to use a different virtual networking configuration.

You have (among others) these options:

  • Network Address Translation (NAT) is by far the simplest solution. VirtualBox will NAT the VMs across whatever internet connection is available to the host. This is fully transparent to the VMs. However this precludes connections from the host to the VMs or connections between the VMs.

  • Use Host-only Networking to create a proper subnet containing the VMs and the host. This will require no changes in the interface configuration you now have in the VMs, but you will need to set up the host to be the gateway and router, and make it NAT the VMs to the outside (whether across its eth0 or tun0).

  • Combine the above: give each VM two interfaces, one gatewaying to the outside world (across VirtualBox's NAT) and the other attached to the Host-Only LAN.

  • Try VirtualBox's experimental NAT Networking configuration. Update 2019: this feature has since matured: attach to the host's NAT and choose the Paravirtualized network (virtio-net) adapter type.

Related Question