Speeding up your OpenVPN tunnel

Here are some settings to speed up the transmission rate through your OpenVPN tunnel:

  • proto udp
  • mssfix 0
  • fragment 0

mssfix: Even though MSS itself is a TCP feature, this OpenVPN option targets encapsulated UDP packets. It will change the MSS value of the TCP protocol inside the tunnel in such a way that after UDP encryption/encapsulation, the resulting UDP packet size (minus IP/UDP headers), will not exceed the mssfix value.
By setting the value to 0, we disable this feature.

fragment: This will disable OpenVPN’s internal fragmentation routines (OpenVPN 2.x actually does this by default).

Another improvement is raising the MTU (Maximum Transmission Units), which is the maximum datagram size in bytes that can be sent unfragmented over a network path.

First make sure your OpenVPN server has set the same MTU size:

ip link set eth0 mtu 9000

Next, add this to your OpenVPN configuration:

tun-mtu 9000


A gateway to forward all traffic to a remote VPN server

Suppose you’ve setup a VM and configured it as a site-to-site VPN with OpenVPN, using iroute and staticclients. You are using this VM as a default gateway for other VMs and now want to forward all traffic from the VMs not through the default gateway‘s adapter, but through the VPN tunnel.

Why would you want to do this? One use-case might be because you want your VMs to have the same originating IP address as the VPN server.

To get started, make sure you add these commands in a terminal on your default gateway:

  • ip route add ip-address-of-vpn-server/32 via default-gateway-ip dev enp0s5 (providing enp0s5 is your current adapter)
  • ip route del default
  • ip route add default via dev tun0 (providing is the private IP you got from your VPN)

The commands above will make sure your gateway can still reach the VPN server. Once the default route is deleted, we add a new default route that goes through the tunnel.

On the other side of the tunnel, on your VPN server, you will need to add these commands:

  • iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
  • iptables -I FORWARD -i tun0 -o eth0 -s -m conntrack --ctstate NEW -j ACCEPT
  • iptables -t nat -I POSTROUTING -s -o eth0 -j MASQUERADE
  • iptables -t nat -I POSTROUTING -o tun0 -j MASQUERADE
  • iptables -I FORWARD -i eth0 -o tun0 -j ACCEPT
  • iptables -I FORWARD -i tun0 -o eth0 -j ACCEPT
  • iptables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

Now the VMs will be able to connect through the VPN tunnel and use the VPN server as default gateway.



If you’re running macOS with QEMU, you’ll notice that the UI might be slow. This is because, by default, QEMU will use a basic display adapter with low display memory (VRAM).

There’s two ways to fix this problem:

  • Pass-through your GPU with vfio
  • Use another display adapter, such as VMsvga2

This post will focus on VMsvga2, which is a macOS kext that enables you to use the vmvga video model with libvirt.

Unfortunately VMsvga2 is an old project that is no longer maintained, same goes for the vmvga QEMU driver. Currently there’s no QXL driver available for macOS so this is the only choice we have.

Simply replace your existing video XML with this:

  <model type='vmvga' vram='16384' heads='1'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> 

You can increase the vram to the amount you desire.
If you are using the Clover bootloader, you might have to add wmv_option_fb=0x06 to the arguments section in your config.plist

You will also need to make sure you have the VMsvga2 kext installed on your system.

Once you reboot, you’ll notice a more responsive UI.