Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I am trying to set up an internal network in Virtualbox in order to share an openvpn client tunnel with multiple VMs acting as clients that should be completely isolated from everything except for the VPN tunnel interface, so as to prevent all possibilities of the client VMs from revealing my real ip address.

My setup consists of 1 VM running Ubuntu Server, and multiple client VMs that connect to it to access the openvpn connection the server VM has. The server VM is connected with eth0 as NAT to access the internet connection. This VM also has an eth1 interface, which is connected to a Virtualbox internal network used by the other VM clients to connect to the internet. Dnsmasq is running over eth1 to serve ips to the clients, and iptables is configured to forward all the traffic from eth1 to tun0 which is the openvpn tun adapter on the server.

So far this has been successful partially. I can get my clients to communicate with the server over the internal network and access the internet through the openvpn tunnel configured on the server, but the clients experience severe connection and performance issues on the internet, while the server itself does not have issues with internet access through the vpn. I researched this problem, and I found there was issue with mtu timings, as the my host machine is already connected to a VPN, and the server VM is also connected to another VM, which add padding and can create fragmentation and performance issues. I need a solution that does not require modifying the vpn connection of the host, everything must be done within virtualbox and the VMs. I attempted to add the options tun-mtu 1400 and mssfix to the openvpn client config file on my server VM, but the openvpn then refuse to connect. I alternatively tried to fix this issue from my client VMs side by setting the mtu size lower to 1400, but the problem was not resolved despite restarting and resetting the networking adapter. However, the server VM itself has no issues keeping up normal performance over vpn, and only the clients over internal network experience problems with internet. After attempting these two solutions, I tested accessing my server VM over putty from a client and downloading a file over HTTP, which revealed that there were no performance issues between client VMs and the server VM over internal network. Currently I have no idea why LAN access from the clients has no issues, while internet access does. The clients are able to ping with icmp, download files (at a much slower speed than normal), and access some websites partially, which made me believe there is an mtu problem. However, I have no idea what to do next to go about solving this problem and I tried all solution I know.

Here is more info about my setup, I really hope that someone can help me get this up and running properly, as I have spent several hours over 2 days trying to get it to work with no luck so far and its really starting to piss me off and make me lose patience.

Basic Layout Image (help you understand): layout

Images Showing Client Problems with Connection: problems

Ifconfig on server VM showing all network interfaces:

root@server1:/var/www# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 08:00:27:8b:b4:cb
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::a00:27ff:fe8b:b4cb/64 Scope:Link
          RX packets:126546 errors:0 dropped:0 overruns:0 frame:0
          TX packets:75182 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:23817797 (23.8 MB)  TX bytes:9685507 (9.6 MB)

eth1      Link encap:Ethernet  HWaddr 08:00:27:37:98:0c
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::a00:27ff:fe37:980c/64 Scope:Link
          RX packets:46043 errors:0 dropped:0 overruns:0 frame:0
          TX packets:103573 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3105270 (3.1 MB)  TX bytes:550239993 (550.2 MB)

lo        Link encap:Local Loopback
          inet addr:  Mask:
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:247 errors:0 dropped:0 overruns:0 frame:0
          TX packets:247 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:19597 (19.5 KB)  TX bytes:19597 (19.5 KB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet  Mask:
          RX packets:37018 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20921 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:51937120 (51.9 MB)  TX bytes:1148212 (1.1 MB)

/etc/network/interfaces settings:

root@server1:/var/www# cat /etc/network/interfaces
# 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

# Virtualbox internal Network
auto eth1
iface eth1 inet static


root@server1:/var/www# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --       anywhere             ctstate NEW
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Openvpn config file:

dev tun
proto udp
remote 1194
resolv-retry infinite
ca ca.crt
remote-cert-tls server
verb 1
reneg-sec 0
auth-user-pass login.conf
share|improve this question
That first paragraph of your really need some improvements. Give us a carriage return or too. Right now it is really painful to read. – Zoredache Jan 9 '14 at 21:40
I tried to make paragraphs better, and Mark Henderson has already fixed it for me. – fsonic Jan 9 '14 at 21:46

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.