IPsec / L2TP VPN mit OpenSwan / xl2tpd unter Debian

Ich benutzte einen meiner Server um dort ein VPN zu betreiben. Dabei verwende ich die Kombination aus L2TP und IPSec. So ein IPSec/L2TP-VPN hat gegenüber z.B. OpenVPN den Vorteil, dass man keine Clientsoftware benötigt und es eigentlich auf allen meinen Betriebssystemen out of the Box läuft. Mac OS, iOS, Android und Windows können ohne Zusatzsoftware eine Verbindung mit dem VPN aufbauen. Implementiert habe ich das auf einem Debian-Linux mit Hilfe von Openswan (IPSec-Implementierung) und xl2tpd (L2TP-Implementierung).

[red_box]Achtung: Debian maintained Openswan nicht mehr! Entweder man baut sich die Pakete von der OpenSWAN-Projektseite selbst – oder man steigt auf StrongSWAN oder LibreSWAN um. Quelle: https://www.debian.org/security/2014/dsa-2893 [/red_box]

Mein Server steht in den USA um z.B die GeoIP-Sperren zu umgehen und so Dienste nutzen zu können die es in Deutschland nicht gibt oder Videos bei z.B. Youtube zu sehen die hier gesperrt sind. Desweitern kann so ein VPN auch benutzt werden um in unsicheren Netzwerken – klassisch das WLAN des Cafes oder Flughafens – sein Netzwerkverkehr verschlüsselt zu übertragen.

1) Voraussetzungen

Man braucht entweder einen Root-Server oder – so wie ich – einen Virtual Private Server (VPS). Hier zu beachten wäre das ein OpenVZ-VPS nicht funktioniert! Es sollte mindestens ein XEN-VPS sein – oder andere Virtualisierungsumgebungen die eine VM mit eigenem Kernel erlauben, wie z.B. VMWare. Allerdings findet man schon recht günstige XEN-VPS – deshalb geht meine Empfehlung hier zu dem XEN-VPS.

Es reicht für den VPN auch die kleinen Konfigurationen. 15 GB Festplatte und 256 MB RAM sind auch ausreichend. Mein Server hat für diesen Zweck 20 GB Festplatte und 512 MB Ram. Auslastung ist hier wirklich gering. Auf die monatliche Bandbreite sollte man noch schauen – bei mir sind es 500 GB im Monat. Ich bin bei ComfortVPS und zahle knapp 50 Euro im Jahr. Viel günstiger ist StrongVPN, etc auch nicht und man macht es selber 😉

Als Betriebssystem verwende ich hier Debian mit der Version 7.3 – das zu diesem Zeitpunk aktuellste Release. Andere Linux-Distributionen funktionieren genauso – Befehle, etc sind hierbei natürlich anzupassen….

Desweiteren verwende ich für IPSec das Pre Shared Keying (PSK) – Verfahren. Natürlich kann hier auch z.B ein Zertifikat (X.509) zur Absicherung verwendet werden – hier eine Anleitung. Für meine Verwendung is so ein Pre Shared Secret bei ausreichende Länge und Komplexität sicher genug.

2) Installation

Als erstes sollte der Server geupdatet werden:

apt-get update && apt-get upgrade

danach installiere ich noch den Editor VIM:

apt-get install vim

und danach kann man die eigentliche VPN-Software installieren:

apt-get install openswan xl2tpd

Nach der Installation kann mit der Konfiguration gestartet werden.

3) Konfiguration

Als erstes macht man ein Backup der ipsec.conf-Datei

cp /etc/ipsec.conf /etc/ipsec.conf.backup

danach kann man die Datei löschen

rm /etc/ipsec.conf

und mit

vim /etc/ipsec.conf
neu anlegen. Dort fügt man folgenden Inhalt ein:

version 2.0
config setup
    nat_traversal=yes
    virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
    oe=off
    protostack=netkey
conn L2TP-PSK-NAT
    rightsubnet=vhost:%priv
    also=L2TP-PSK-noNAT
conn L2TP-PSK-noNAT
    authby=secret
    pfs=no
    auto=add
    keyingtries=3
    rekey=no
    ikelifetime=8h
    keylife=1h
    type=transport
    left=PUBLIC.IP.DES.SERVERS
    leftprotoport=17/1701
    right=%any
    rightprotoport=17/%any
 

Dabei ist PUBLIC.IP.DES.SERVERS mit der externen IP des Servers zu ersetzten. Diese Konfiguration funktioniert bei mir wunderbar – kann natürlich nach belieben angepasst werden – hier der Wiki des Projekts. Eine leere Zeile am Ende der Datei ist notwendig, sonst startet später der Dienst nicht.

Danach muss der PSK – der Secret – konfiguriert werden:

cp /etc/ipsec.secrets /etc/ipsec.secrets.backup
rm /etc/ipsec.secrets
vim /etc/ipsec.secrets

Hier wird folgendes eingetragen:

PUBLIC.IP.DES.SERVERS %any: PSK "DerSicherePSK1234"

Nicht vergessen wieder die externe IP des Servers zu ersetzen und einen sicheren Schlüssel zu setzen.

Weiter geht es zur Konfiguration des xl2tpd:

cp /etc/xl2tpd/xl2tpd.conf /etc/xl2tpd/xl2tpd.conf.backup
rm /etc/xl2tpd/xl2tpd.conf
vim /etc/xl2tpd/xl2tpd.conf

und dort

[global]
ipsec saref = yes

[lns default]
ip range = 192.168.138.50-192.168.138.149
local ip = 192.168.138.1
refuse chap = yes
refuse pap = yes
require authentication = yes
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes

einfügen.
IP Range definiert den Bereich der IP-Adressen die die Clients bekommen, die sich auf den Server connecten. Dieses sollte ein Privates Netzwerk sein und nicht das gleiche Netz sein von dem man sich verbindet. Deshalb wäre 192.168.178.X, 192.168.1.x oder 192.168.2.x nicht zu empfehlen, da diese Netze meistens für Heim-Router verwendet werden. Kann natürlich auch aus dem 10.x.x.x-Bereich sein, etc.
Local IP definiert die private IP-Adress des Servers.

Jetzt erstellt man noch die options.xl2tpd-Datei:

vim /etc/ppp/options.xl2tpd

und fügt folgendes ein:

require-mschap-v2
ms-dns 8.8.8.8
ms-dns 8.8.4.4
asyncmap 0
auth
crtscts
lock
hide-password
modem
debug
name l2tpd
proxyarp
lcp-echo-interval 30
lcp-echo-failure 4

Jetzt fehlen noch die Benutzer. Diese konfiguriert man mittels:

vim /etc/ppp/chap-secrets

Dort trägt man die Benutzer folgendermaßen ein:

# Secrets for authentication using CHAP
# client server secret IP addresses
UserA l2tpd SuperSicheresPasswort *
UserB l2tpd SuperSicheresPasswort 192.168.138.15

Kurze Erklärung: Der UserA bekommt irgendeien IP aus dem Range der in /etc/xl2tpd/xl2tpd.conf konfiguriert wurde. UserB bekommt fest die 192.168.138.15. Zu beachten ist hierbei das feste IPs nicht in dem IP Range liegen sollten, da es sonst zu Adresskonflikten kommen kann. Auch ist es nicht unbedingt notwendig für z.B. Laptop und iPhone unterschiedliche User zu erstellen – beide können sich mit dem selben User anmelden.

Jetzt muss nur noch iptables und der Netzwerk-Stack konfiguriert werden. Am einfachsten geht dies über die rc.local-Datei.

vim /etc/rc.local

dort muss

for each in /proc/sys/net/ipv4/conf/*
do
echo 0 > $each/accept_redirects
echo 0 > $each/send_redirects
done
iptables -t nat -A POSTROUTING -s 192.168.138.0/24 -o eth0 -j MASQUERADE
/etc/init.d/ipsec restart

vor exit 0 eingefügt werden. Achtung: Das Netz dass unter /etc/xl2tpd/xl2tpd.conf konfiguriert wurde hier bei der iptables Zeile anpassen.

So sieht meine rc.local aus:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

test -e /etc/ssh/ssh_host_dsa_key || dpkg-reconfigure openssh-server
blkid | grep -q /dev/vda && test ! -e /boot/grub/device.map && echo "(hd0) /dev/vda" > /boot/grub/device.map

for each in /proc/sys/net/ipv4/conf/*
do
echo 0 > $each/accept_redirects
echo 0 > $each/send_redirects
done
iptables -t nat -A POSTROUTING -s 192.168.138.0/24 -o eth0 -j MASQUERADE
/etc/init.d/ipsec restart

exit 0

danach sollte neugestartet werden

reboot

und nach dem Neustart kann mit

ipsec verify

die Konfiguration überprüft werden. Dann sollte es so aussehen:

ipsec-verify

Wenn es so aussieht sollte alles soweit funktionieren.

Unter iOS sieht die Konfigurtion so aus:

vpn-ios

Server ist die Public-IP des VPN-Servers. Account und Kennwort ist unter /etc/ppp/chap-secrets konfiguriert. Der Shared Secret ist der PSK unter /etc/ipsec.secrets. Durch „Für alle Daten“ wird wirklich aller Datenverkehr über den VPN geschickt.

Andere Betriebssystem sind entpsrechend ähnlich zu konfigurieren.

Dann viel Spaß mit dem VPN 🙂

13 Kommentare

  1. In der /etc/ipsec.conf muss alles außer conn, version und config um 1 tab eingerückt werden, sonst gibs eine fehlermeldung bei ipsec verify.

    Ich versuch derzeit via NAT auf meinem server zu verbinden, gelingt aber leider nicht. Welche Ports muss man forwarden?

    1. Ich muss mich mal um eine anständige Formatierung für Code kümmern… Wegen dem NAT: bisher hab ich es immer ohne NAT implementiert – direkt den Server am Internet, in der DMZ oder als exposed Host. Welcher Router wäre es denn?

  2. Hi,

    trotz einrückung bekomme ich immer noch fehler:

    root@dasei:~# ipsec verify
    Checking your system to see if IPsec got installed and started correctly:
    Version check and ipsec on-path [OK]
    Linux Openswan U2.6.37-g955aaafb-dirty/K(no kernel code presently loaded)
    Checking for IPsec support in kernel [FAILED]
    SAref kernel support [N/A]
    Checking that pluto is running [FAILED]
    whack: Pluto is not running (no „/var/run/pluto/pluto.ctl“)
    Two or more interfaces found, checking IP forwarding [FAILED]
    whack: Pluto is not running (no „/var/run/pluto/pluto.ctl“)
    Checking for ‚ip‘ command [OK]
    Checking /bin/sh is not /bin/dash [WARNING]
    Checking for ‚iptables‘ command [OK]
    Opportunistic Encryption Support [DISABLED]

    Habe in meiner Config das alles eingerückt aber leider kein erfolg ….

    Jemand eine Idee?

  3. Hi,

    Ist KVM – nach etwas herumspielen bin ich nun auf diese Fehler gekommen

    root@dasei:/etc# ipsec verify
    Checking your system to see if IPsec got installed and started correctly:
    Version check and ipsec on-path [OK]
    Linux Openswan U2.6.37-g955aaafb-dirty/K3.2.0-4-amd64 (netkey)
    Checking for IPsec support in kernel [OK]
    SAref kernel support [N/A]
    NETKEY: Testing XFRM related proc values [FAILED]

    Please disable /proc/sys/net/ipv4/conf/*/send_redirects
    or NETKEY will cause the sending of bogus ICMP redirects!

    [FAILED]

    Please disable /proc/sys/net/ipv4/conf/*/accept_redirects
    or NETKEY will accept bogus ICMP redirects!

    [OK]
    Checking that pluto is running [OK]
    Pluto listening for IKE on udp 500 [OK]
    Pluto listening for NAT-T on udp 4500 [OK]
    Two or more interfaces found, checking IP forwarding [FAILED]
    Checking for ‚ip‘ command [OK]
    Checking /bin/sh is not /bin/dash [WARNING]
    Checking for ‚iptables‘ command [OK]
    Opportunistic Encryption Support [DISABLED]

  4. Irgendwie will es bei mir nicht laufen 🙁
    „ipsec verify“ zeigt exakt das gleiche wie auf deinem Screenshot.
    Habe die Konfiguration jetzt 2x neu gemacht -> ich bekomme aber keine Verbindung von OSX zu meinem Server.
    Leider finde ich auch keine Log Files auf meinem debian system wo man irgendwo sehen könnte „warum“ es nicht geht.
    Dachte auch schon es liegt an den Sonderzeichen in den Benutzer Passwörtern, aber selbst wenn ich diese auf nur Buchstaben & Zahlen ändere, geht es nicht.
    PS: am Ende der /etc/ipsec.conf muss eine leere Zeile kommen, ohne startet der Dienst bei mir nicht.

    Ich bräuchte nur einen Tip wo man sehen kann ob überhaupt eine Verbindung zu Stande kommt und/oder was noch in den iptables eingestellt werden muss.

    1. Im syslog hab ich dazu leider nichts gefunden, aber in /var/log/auth, da war eine Fehlermeldung bzgl. eines unvollständigen Payloads, das wiederum kam durch eine neuere Version von openswan in Verbindung mit dem Heartbleed-Bug (einfach mal googeln). Ein openswan Downgrade auf Version 2.6.37-3 war dann die Lösung und alles lief sofort mit allen Geräten (Android, OSX, Win8.1)

        1. Nebenbei, ich hab das gebraucht weil Kabel Deutschland hier im Norden von Dienstag Vormittag bis Mittwoch Nacht ein routing Problem hatte so das kaum was funktionierte – ich hab dann alles über meinen VPS von netcup geroutet, für 4 Benutzer (mit jeweils 2-3 Geräten), das ging tatsächlich ohne irgendwelche Probleme und selbst Spiele wie Titanfall liefen mit einem 50er Ping reibungslos.
          Jetzt überlege ich mir tatsächlich einen weiteren mini VPS in den USA zu holen – für die gleichen Zwecke wie bei dir, Andreas.
          Der Anbieter den du oben verlinkt ist -> wie ist da die Ausfallsicherheit bzw. merkst du das dass Host-System wo du mit deinem VPS drauf bist stark überbucht ist? Also z.b. Traffic Probleme, langsamer Seitenaufbau oder ähnliches? Da das oben ein Ref-Link ist bin ich natürlich geneigt diesen zu nehmen 😉

          1. Freue mich dass dir der Artikel geholfen hat und über dein Feedback 🙂

            Zu meinem Anbieter: Ich benutze den VPS alleine und hatte damit noch keine Probleme. Youtube und andere Protale gingen in HD abzuspielen – Websurfing war okay.
            Hautpsächlich war für mich der Umstand entscheidend dass sie einen guten Preis haben und mit Paypal zu bezahlen sind. Mit dem Support hatte ich zu tun und kann den in meinem Fall nur loben. Du kannst ja einfach mal einen Testen -> sie haben neben der Möglichkeit den Server nur einen Monat zu bezahlen auch eine 3-Tage-Geldzurück-Garantie 🙂

  5. Hallo miteinander!
    Bekomme nach nunmehr mehreren Tagen dieselbe Fehler wie Fehlermeldung wie „PIET“

    Checking your system to see if IPsec got installed and started correctly:
    Version check and ipsec on-path [OK]
    Linux Openswan U2.6.37-g955aaafb-dirty/K(no kernel code presently loaded)
    Checking for IPsec support in kernel [FAILED]
    SAref kernel support [N/A]
    Checking that pluto is running [FAILED]
    whack: Pluto is not running (no “/var/run/pluto/pluto.ctl”)
    Two or more interfaces found, checking IP forwarding [FAILED]
    whack: Pluto is not running (no “/var/run/pluto/pluto.ctl”)
    Checking for ‘ip’ command [OK]
    Checking /bin/sh is not /bin/dash [WARNING]
    Checking for ‘iptables’ command [OK]
    Opportunistic Encryption Support [DISABLED]

    Ich weiß mir keinen Rat mehr – bin auch nicht wirklich Linux Sattelfest (lerne das Ganze erst…)
    Was ist zu tun, wenn anstelle Openswan Libreswan genutzt wird?
    Fragen über Fragen…

Kommentar verfassen