Schlagwort: IPSec

IPSec/L2TP VPN mit OpenWRT

Raptor 21014 Comments

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.