IPSec/L2TP VPN mit OpenWRT

Da ich mehrere Android Geräte in Benutzung habe die ich nicht „rooten“ darf und dennoch einen VPN Tunnel in mein Heimnetzwerk brauche, hatte ich das „Vergnügen“ mich mit IPSec/L2TP – Tunneln auseinander zu setzten. Android bietet native aktuell vier VPN-Varianten an: PPP, L2TP, IPSec/L2TP (PSK), IPSec/L2TP (Certificate)

PPTP fällt aus, da der Android-Client nur primitive Authentifizierungen anbietet, welche als leicht angreifbar gelten. L2TP ist nur ein Layer2-Tunnel-Protokoll um darüber wiederum ein PPP-Tunnel aufzubauen. Da L2TP selber nicht Verschlüsselt ist das ganze nur so sicher wie der PPP Tunnel. Bei welchem wieder nur primitive Authentifizierungen angeboten wird. Bleibt als letzte Alternative nur den L2TP-Tunnel via eines IPSec Tunnel zu sichern. Sowohl die PSK (PreSharedKey) als auch zertifikatsbasierte Lösung sollten hinreichend sicher sein.

Damit beginnt aber auch schon der Ärger.  IPSec-Gateways findet man nur in wenigen SOHO Geräten vorkonfiguriert (z.b. einigen Fritzboxen) und das aus gutem Grund. Das Zusammenspiel Clients, Netze, Netzanbieter und IPSec läuft nicht so reibungslos wie es sollte. Dazu gleich mehr.

OpenWRT bietet gleich mehrere IPSec und L2TP Dienste an. Ich hab mich für den StrongSwan4 – Daemon als IPSec Dienst entschieden. Da dieser auch IKEv2 anbietet, in der Hoffnung dass dies vom auf Android eingesetzten Racoon-Daemon auch mal genutzt wird.

Des weiteren komm der xl2tp-Daemon oder der standardmäßig installierte ppp-Daemon zum Einsatz.

Bevor man die Sache angeht sollte man folgendes beachten um sich viel Zeit und Ärger zu ersparen: Das fehleranfälligste an einem IPSec/L2TP-VPN ist der IPSec-Anteil. Man sollte diesen also getrennt testen. Als sinnvoll hat es sich gezeigt, den Zielrouter mal vom Netz ab zu klemmen, die Firewall abzuschalten und plain den xl2tp-Daemon im Zusammenspiel mit dem PPP-Daemon zu testen. Das ganze geht einfach von der Hand und ist robust und stressfrei.

Danach kann man den IPSec Tunnel via PSK hochziehen und im internen Netz testen. Anschließend kann man ggf noch Zertifikate zur Authorisierung nutzen. Erst wenn das alles im internen Netz klappt sollte man Versuchen von „Außen“ auf das VPN zuzugreifen. Es empfiehlt sich an dieser Stelle für die Mobilen Devices einen LogReader zu installieren. Für Android ist das die App aLogcat. Leider gibt der racoon-Daemon nur in die Logfiles aus warum er einen Tunnel wieder zu macht oder warum er erst gar keinen aufbauen will.

Wie eingangs erwähnt gibt es mehrere Stolpersteine. Es war mir z.b. nicht möglich eines meiner Geräte dazu zu bewegen, den IPSec Tunnel aufzubauen. Das lies sich aber zweifelsfrei auf das Netzsegment zurückführen. Eine SIM-Karte des gleichen Netzanbieters aus einem anderen Gerät (anderes Netzsegment) eingewechselt und schon konnte der Tunnel aufgebaut werden. Es scheint Probleme beim Zusammenspiel Racoon – open/strong-Swan zu geben wenn mehrfaches „NAT“ing zum Einsatz kommt.[1. Quelle: http://www.mail-archive.com/users@lists.strongswan.org/msg02787.html]

Diesen Widrigkeiten zum Trotz kann man das ganze relativ leicht auf OpenWRT oder Ubuntu wie folgt einrichten:

Man benötigt  als Pakete den PPP-Daemon, XL2TP-Daemon und StrongSwan.

Configuration – /etc/ppp/options.xl2tpd

#Das wird nur gebraucht für radius-anbindung
plugin radius.so 
radius-config-file /etc/ppp/radius.conf
avpair NAS-Identifier=l2tp-vpn 
avpair NAS-Port=1

auth
#ggf für testzwecke noauth
#für debugging dump

lock
noccp
novj
novjccomp
nopcomp
noaccomp

ms-dns DNS-Server-IP

refuse-chap
require-pap

Hinweis ich erzwinge das unsichere PAP weil der IPSec-Tunnel via Zertifikaten gesichert ist (sehr schwer zu brechen, eigene CA) und FreeRadius für alles andere Klartextpasswörter im Zugriff braucht. Das muss man ggf. an seine Anforderungen anpassen!

Configuration xl2tp – Achtung hier verwende ich keine Authentifizierung. Das überlasse ich IPSec und PPPd
/etc/xl2tpd/xl2tpd.conf

[global]
port = 1701
;auth file = /etc/xl2tpd/xl2tp-secrets
access control = no
ipsec saref = no ;wichtig SAREF funktioniert nicht mit StrongSwan
;folgende zielen für debuggin einkommentieren
;debug avp = yes
;debug network = yes
;debug packet = yes
;debug state = yes
;debug tunnel = yes

[lns default]
exclusive = yes
ip range = 10.0.100.5-10.0.100.50
hidden bit = no
local ip = 10.0.100.1
length bit = yes
refuse authentication = yes
name = IpSec-Tunnel
ppp debug = no
pppoptfile = /etc/ppp/options.xl2tpd

Nun zu IPSec

config setup
        strictcrlpolicy=no #Für ein kleines Setup wird keine RevokationList verwaltet...
        plutodebug=none
        nat_traversal=yes #anschalten wenn man mit NAT(ted) Clients rechnet.
        virtual_private=%v4:10.0.0.0/8,%v4:192.168.99.0/24,%v4:!192.168.100.0/24
        charonstart=no #noch brauchen wir kein IKEv2
        #protostack=netkey
conn NAT-Tunnel
    authby=rsasig #Authentisierung via Zertifikaten
    pfs=no
    compress=no
    rekey=no 
    keyingtries=3
    type=transport
    auto=add
    left=%defaultroute
    leftcert=mycert.pem
    leftid=@mydomain
    leftrsasigkey=%cert
    leftsendcert=always
    leftprotoport=17/1701
    right=%any
    rightsubnet=vhost:%no,%priv
    rightprotoport=17/%any 
    rightrsasigkey=%cert
    rightca=%same #Wichtig das sorgt dafür dass alle Zertifikate die von der gleichen CA unterschrieben wurden wie das LeftCert angenommen wurden.
    keyexchange=ikev1 #ikev2 ist Standard auf ikev1 downgraden, da Android mit ikev1 reinkommt.

Anschließend sollte man sich noch vor der Dummheit der Nutzer und Clients schützen. Wenn der Racoon unter Andoid die Verbindung abbricht, versucht es der L2TP-Daemon dennoch aufzubauen. Die Verbindungsverwaltung bemerkt das zwar und beendet die Verbindung sofort, dummerweise wurden schon die Authentisierungs-Daten im Klartext gesendet. (Nein auch MS-Chap-v2 zählt als Klartext). Ein Angreifer kann so gezielt (über NAT) ein kurzes Downgrade erzwingen, die Daten abgreifen und dann selber ohne IPSec einen L2TP-Tunnel aufbauen.
Um das zu verhindern muss man IPTables dazu bringen Verbindungen für Port 1701(L2TP) nur dann anzunehmen, wenn diese über IPSec reingekommen sind. Früher war das einfach, da gab es ein ipsec-Device, heute muss man über die mangle-Table rann. Das ganze sieht dann wie folgt aus

iptables -A INPUT -p udp --dport 500 -j ACCEPT #IPSec kommt immer über port 500 rein
iptables -A INPUT -p esp             -j ACCEPT # Encapsulated Security Payload - IPSec Protokoll
iptables -A INPUT -p ah              -j ACCEPT #Authentication Header - IPSec Protokoll

iptables -t mangle -A PREROUTING -p esp -j MARK --set-mark 1 # Der eigendliche Paylod kommt über das ESP protokol, alle Pakete markieren.
iptables -A INPUT -m mark --mark 1 -p udp --dport 1701 -j ACCEPT #alle Pakete die markiert wurden und an 1701 gehen werden akzeptiert.

Mittels dieser Regel lehnt der Gateway alle L2TP Pakete ab, die nicht über IPSec gesichert wurden.

4 thoughts on “IPSec/L2TP VPN mit OpenWRT”

  1. Hallo,

    hast du auch schon mal versucht, eine IpSec/L2TP-VPN zwischen 2 OpenWrt-Geräten aufzubauen?

    Schöne Grüße,
    Daniel

  2. Nein

    Wenn ich zwei OpenWRT Geräte verbinden will mach ich das über ipsec to ipsec (ohne l2tp) oder OpenVPN tunnel. Das ist einfacher und nicht ganz so „oversized“.

  3. Geht die Anleitung davon aus, dass der VPN-Server auf dem gleichen Router läuft wie das Internet?

    Mein Wunsch ist es, das auf einen separaten OpenWRT-Router zu packen.
    Was muss ich dabei beachten?

    Habe 2 TP-Link WR1043ND, der eine mit Originalfirmware (stellt Internet zur verfügung) und der 2. soll mit OpenWRT die VPN bereitstellen.

  4. Ich muss leider gestehen, dass ich befürchte, das die Anleitung nicht mehr aktuell ist. Bei meinem letzten Aktualisierung wurde der IKEv1 Daemon nicht mehr mit ausgeliefert oder ich war zu blöd ihn zu aktivieren.

    Folglich kommt es auf dein Setup an. Wenn du eine Strong/Open-SWAN Verbindung aufbauen willst (reines IPSEC) sollte NAT keine Rolle spielen. Beide Implementierungen konnten bei mir erkennen, dass sie „genatet“ wurden und haben entsprechen reagiert.

    Problematischer ist das „RoadWarrior“-Setup mit IOS/Andoid usw Geräten. Hier kommt (zu mindestens bei Android) die Racoon Implementierung zum Einsatz. Diese „harmoniert“ nicht so gut mit den beiden SWAN-Implementierungen. Dann kommt es zu den erwähnten Problemen. Das Einzige Setup das ich teilweise zum laufen bekommen habe (auf 3 von 4 Geräten) war, dass der IPSEC Zugang direkt auf dem Gateway lief (nicht genated) und dann intern den L2TP Traffic an den TunnelServer weitergeleitet hat.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

I accept that my given data and my IP address is sent to a server in the USA only for the purpose of spam prevention through the Akismet program.More information on Akismet and GDPR.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.