OpenVPN Error: Linux route add command failed

OpenVPN Logo

Image source: openvpn.net

Everbody knows OpenVPN. A powerful and easy to configure VPN client, which is cross-platform available for BSD, Linux, MAC and Windows.
A lot of my Linux boxes are OpenVPN clients, starting with Virtual Machines as well as physical boxes. If I use my OpenVPN server as a default gateway, some machines having trouble to create the necessarily route. The output in the most cases is something like this:

Sun Jun 19 14:03:20 2016 /bin/ip route add 1.2.3.4/32 via 0.0.0.0
RTNETLINK answers: No such device
Sun Jun 19 14:03:20 2016 ERROR: Linux route add command failed: external program exited with error status: 2

So this means that the OpenVPN tried to create a new route with the help of the ip command which failed (error code 2). But how to fix this?

Add the route by your own

I’ve searched around the internet and nobody really had an answer to this. Well, the solution is rather simple. Directly after the successful connection to your OpenVPN server, add the route by your own. The following example would do this for the shown error above:

sudo route add -host 1.2.3.4 dev enp4s0

As you can see, there is no gateway address to reach the host. It’s simply the Ethernet device which is stated here (enp4s0 is the name of the first wired Ethernet device under openSUSE when using Network Manager (formerly known as eth0)).

This error also occurs, if you want to use a OpenVZ container as a OpenVPN client. By default, the first virtual network device of a OpenVZ container is called venet0. So you would have to enter the following command to get this error fixed:

sudo route add -host 1.2.3.4 dev venet0

After you added the host to your routing table with the correct outgoing network device, you’re ready to go to use the VPN as your default gateway.

Permanent Fix

To be honest, until now I wasn’t able to find a permanent fix for this. So this also means that you have to redo the route add command every time, when you have connected to your VPN.
If you know a permanent fix for this problem, just let me know in the comments below. Your help is appreciated 🙂

Convert IMG (raw) to QCOW2

KVM Logo

Most of you will know the Kernel-based virtual machine. It’s already included with the latest Linux kernels and it gives you full virtualization under Linux which provides the capability to run almost every x86 OS you want inside a virtual machine.

Some versions ago, if you created a new virtual machine in KVM, the virtual hard disk was a RAW .img container. The new container type is QCOW2 and one of it’s main features is to enable the snapshot functionality of KVM.
So this means, if you have virtual machines which have a IMG HDD attached, than you will not be able to create snapshots of this virtual machine. Luckily the KVM developers are providing tools, which helps you to convert existing IMG HDDs to QCOW2 HDDs.

The convert process

First of all, this will take some time and it depends of course on the size of the HDD. Also, you should shutdown the virtual machine so that the convert process has the standalone access on the HDD while converting. The following example would convert a .img HDD to a .qcow2 HDD:

qemu-img convert -f raw -O qcow2 /path/to/your/hdd/vm01.img /path/to/your/hdd/vm01.qcow2

To explain the command a litte bit more:

  • qemu-img is the command which should be executed
  • convert says qemu-img that we want to convert an existing HDD
  • the switch -f raw lets qemu-img know, that the existing format of the HDD is RAW (in this case with .img filename ending)
  • the -O qcow2 switch tells the qemu-img command that the destination HDD should be QCOW2
  • the first file is the exisiting raw HDD, the second one is the filename of the new QCOW2 type HDD

So, let us say we want to convert a raw HDD which is located in /var/lib/libvirt/images (standard path for new KVM machines) to a QCOW2 HDD:

qemu-img convert -f raw -O qcow2 /var/lib/libvirt/images/machine01.img /var/lib/libvirt/images/machine01.qcow2

After you have done this, you just have to change the path from your HDD in your virtual machine from the raw .img to the .qcow2 file. NOTE: The .img file is not deleted after the successful convert process. You have to do this on your own.

At the end, you should be able to create snapshots for your virtual machine. One of the best features while using virtual machines at all 😉

Unitymedia, Amazon Fire TV und Netflix …

Netflix Logo

Bildquelle: wikipedia.org

NOTE: This post is exceptionally in german. This has to do with the content because it’s only relevant for people who live in Germany.

Update, 13.02.2017: Mittlerweile habe ich mir eine FritzBox zugelegt und Erfahrungswerte dazu in Verbindung mit Unitymedia gesammelt: Unitymedia: Endlich gutes und schnelles Internet

Unitymedia, Amazon Fire TV und Netflix … was hab ich mich nicht die letzten Tage mit diesen drei Komponenten herumgeärgert. Aber warum eigentlich?

Um das zu erläutern, muss ich erst einmal ein wenig ausholen. Ich bin seit geraumer Zeit Unitymedia Kunde. Um genau zu sein seit ca. einem halben Jahr. Vor etwa einem Monat muss ein “stilles Update” von Seitens Unitymedia auf meinem Router durchgeführt worden sein. Nun ist das ja nichts Neues, seit einem Zwangsrouter von Seitens der Provider verordnet werden. Das Schlimme an diesem Update jedoch ist, dass ich als Netflix Kunde und Amazon Fire TV Nutzer seither keinerlei Konnektivität mehr zu den Netflix Servern über die offizielle Netflix App auf dem Amazon Fire TV mehr herstellen kann. Es erscheint lediglich bei jedem Starten der App der Fehler “ui-113” mit der Information, dass keine Verbindung zu den Netflix Servern hergestellt werden konnte.

Der Workaround als Lösung

Ich habe etliche Stunden damit verbracht das Netz zu durchforsten. Das Problem wird nämlich immer wieder auch in diversen Foren besprochen.
Eine sehr hilfreiche Diskussion fand dabei im computerbase.de Forum statt. Hier konnte ich entnehmen, dass wohl das Anpassen der MTU hilft. In vielen Fällen wird von 1450 Byte anstelle von den standardmäßigen 1500 Byte gesprochen. Ich selbst habe mittlerweile meine MTU auf 1400 angepasst und seither funktioniert Netflix bei mir auch wieder auf dem Amazon Fire TV.

Viele im Forum haben geschrieben, dass es ihnen auf Grund ihres Routers, den sie von Unitymedia gestellt bekommen haben, nicht möglich sei die MTU zu ändern. Der Wert sei fest von Unitymedia vorgegeben.
Ich selbst habe ein “Connect Box” von Unitymedia. Leider kann ich nicht sagen, um welches Gerät es sich genauer handelt, jedoch steht mir die Schaltfläche zum Ändern der MTU zu Verfügung:

router

Alternativ hab ich auch zwei weitere Methoden versucht, welche ebenfalls beide dazu geführt haben, dass Netflix über den Amazon Fire TV wieder funktioniert, auch wenn die MTU auf dem Router von Unitymedia immer noch auf 1500 steht:

  1. Weiterleiten des Datenverkehrs über einen Home Server: Dies funktioniert natürlich nur, wenn ihr einen Homeserver zu Hause habt. In diesem Fall kann dieser Server als Gateway für den Fire TV genutzt werden. Eine entsprechende Konfiguration des Servers im Vorfeld versteht sich natürlich.
    Durch das Anpassen der MTU auf dem Netzwerkinterface des Servers, hat dies auch entsprechend Einfluss auf die MTU des Fire TVs. Dem Fire TV muss die IP Adresse des Servers als Gateway hinterlegt werden.
  2. Kauf eines Routers, welche hinter die Unitymedia Box geschalten wird: In diesem Fall kauft ihr euch bspw. eine kleine Variante der FritzBox von AVM. Alternativ gibt es natürlich auch noch andere Router wie z. B. von TP-Link, von denen viele Modelle ebenfalls das Anpassen der MTU unterstützen. In diesem Fall muss der (neue) Router jedoch so konfiguriert werden, dass dieser kein DHCP Server mehr anbietet (das macht nämlich bereits die Box von Unitymedia). Außerdem muss die IP Adresse entweder ermittelt werden, sofern der Router über DHCP von der Unitymedia Box eine IP Adresse zugewiesen bekommt, oder diese manuell gesetzt werden (empfohlen). Sofern diese Punkte beachtet werden, kann abschließend die MTU im (neuen) Router gesetzt, und anschließend die IP Adresse eben dieses Routers im Amazon Fire TV als Gateway hinterlegt werden.

Gibt es mit der Umstellung der MTU irgendwelche Nachteile?

Im Grunde nicht. Es werden mehr Pakete verschickt wie bisher, da die maximale Paketgröße nun 1400 Bytes anstelle von 1500 Bytes ist, jedoch konnte ich in keinem Fall feststellen, dass darunter bspw. mein Ping oder meine Downloadrate zu leiden hatte. Insofern ist das alles “in Ordnung” und in gewisser ein Workaround, der auch getrost permanent genutzt werden kann.

Was sagen eigentlich Unitymedia, Amazon und Netflix zu diesem Problem?

Wie man im Netz an verschiedenen Stellen liest, machen die drei keinen großen Hehl daraus, dass es derzeit Probleme gibt. Jedoch schieben diese sich gegenseitig den schwarzen Peter zu. Immerhin liest man in einem Forum, dass sich alle drei zusammensetzen um das Problem zu lösen.

Das Ganze erinnert einen auch an die Vorkommnisse im Playstation Network, als der Login einfach nicht mehr möglich war. Damals hatte man sich ebenfalls damint beholfen, dass man die MTU in der PS4 von 1500 auf 1450 herabsetzt und schon war der Login wieder möglich … schon komisch, was manchmal 50 Byte hin oder her ausmachen können 🙂

How to tunnel with SSH (Port forwarding)

Tunneling with SSH is a real good combo to encrypt every network communication you want. You are also be able to access other network services which are only availble to the destination which you trying to ssh to.
As you can see, these two reasons are just two of a bunch more why tunneling with SSH is something you should definitly consider. Also tunneling with SSH is really simple. The following pictues I created tries to show you how easy it really is:

ssh_blog

So as you can see in the picture, the first number after the -L parameter (marked red) states the local port on your local machine where you execute the ssh command. So this means that the remote service will be available locally on your machine with this port. NOTE: You should only use ports above the “System Ports” which are regulated in RFC 6335. This means ports > 1023 (in the picture we use port 5000 which is fine).
The second value (the one between the two colons, yellow marked) states the remote address. The remote address can be of course localhost but in this case localhost does not mean your local machine. It means the remote machine you are ssh-ing to. It is possible that you also insert here a machine name or IP behind the destination machine you trying to ssh to. The destination tries to establish the connection to the remote address then.
The third value after the -L parameter (marked blue) is the port of the destination address which is given in the step before (yellow marked). So this means, if you want to connect for e.g. to a running Webserver on, then you have to enter 80 here (80 is the standard port for a HTTP connection).
The last value (marked green) is of course your username and the server you’re going to ssh to.

Another good example would be something like this:

ssh -L5000:www.google.de:443 myserver.my.domain

This example will open a SSH connection to the server myserver.my.domain and will tunnel (or forward) the Port 443 on the destination address (in this example “www.google.de”) to the local port 5000 on your local machine. After this you will be able to enter https://localhost:5000 in your webbrowser on your local machine and you should see the google start page. This means all the traffic via localhost:5000 is routed over your server (myserver.my.domain in this example) to Googles webservers.

A more practical example:
Everbody knows VNC … it’s easy to use and especially easy to install under Linux. I tried a lot of other solutions for remote access like X2Go or NXNomachine. These solutions are good, no doubt about that, but nothing comes close to easyness and portability as VNC did.
For my personal purposes I use the TigerVNC Client and Server implementation. Actually I didn’t found a possibility to encrypt the traffic which was created from VNC. To do this, we could just use an SSH Tunnel. Useing an SSH tunnel while useing VNC gives you some great benefits:

  1. The VNC traffic between your local machine and the destination (VNC Server) is encrypted.
  2. As a home server user, you can just open the SSH port in your routers firewall for external access. All other ports can remain closed because you can port forward them with the help of SSH.
  3. Due to the SSH user authentication you have something like a “low-level” user authentication.

The following example opens a SSH connection to the server myserver.my.domain and forwards the VNC Server port on this server so that the VNC Server is reachable locally under the port 5000:

ssh -L5000:localhost:5900 myserver.my.domain

After the connection is established the VNC Server on the server myserver.my.domain can now be reached under the address localhost port 5000. If your server does listen on another port than the standard port of SSH (22) you can add the -p parameter to ssh to your server with the port you want:

ssh -p1234 -L5000:localhost:5900 myserver.my.domain

Happy tunneling!