Einen Router bauen
arrow.gif Entwicklungsumgebung
arrow.gif Hardware Plattformen
arrow.gif Slackware Router
arrow.gif Downloads
   
Weiterentwicklung
arrow.gif Tasks pending
arrow.gif Bugs
   
Informationen
arrow.gif Security
arrow.gif FAQ
arrow.gif Links
 
Slackware Linux Router
Prev Next

13. L2TP/IPSec Server und Android Tablets

13.1 Hintergrund

OpenVPN-Implementierungen für Android Tablets sind verfügbar − aber die Installation von OpenVPN auf Android beinhaltet einige Herausforderungen, beispielsweise muss die Version des «tun.ko» Kernelmoduls zur Build Version des Android Kernels passen. Zu erwarten, dass alle notwendigen Software Komponenten jederzeit in gegenseitig kompatiblen Versionen verfügbar sind scheint unrealistisch.

Da Android Geräte (und Geräte die iPhone OS verwenden) offenbar standardmässig mit L2TP/IPSec Peers ausgestattet sind, führt der einfachste Weg zum mobilen VPN-Zugriff auf das Heimnetzwerk über einen eigenen L2TP/IPSec Server im LAN oder in der DMZ .

Die vorgeschlagene Architektur lehnt sich an die Lösung an, die bereits für die OpenVPN Installation skizziert wurde. Der VPN Server befindet sich in einer DMZ, die Nutzdaten, auf die zugegriffen wird, befinden sich im LAN.

Natürlich ist es möglich, den VPN Server direkt im LAN, beispielsweise auf dem Fileserver, zu installieren. Die DMZ-Lösung beschert ihrem Owner aber einen etwas ruhigeren Schlaf.

Selbstverständlich kann der L2TP/IPSec Server auf der gleichen Host Maschine betrieben werden, wie der OpenVPN Server. Da die Server unterschiedliche Ports verwenden, stören sie sich gegenseitig nicht.

(Eventuell wäre auch der gleichzeitige Betrieb eines L2TP/IPSec Servers in einer DMZ oder im LAN zugleich mit einer Site-to-Site IPSec Lösung des Linuxrouters möglich. Bei einer Site-to-Site Installation sind die Endpunkte des Tunnels fix und bekannt. Der Router könnte somit Pakete, die von seinem Peer am anderen Tunnelende kommen anders behandeln als Pakete, die von einem mobilen Client gesendet werden. Oder es ist möglich, die IPSec Ports umzukonfigurieren, womit das Problem ebenfalls gelöst wäre. Diese Lösungen wurde jedoch nicht getestet.)

13.2 Übersicht

Die nachstehende Skizze zeigt den Aufbau der oben diskutierten Lösung. Die Architektur geht von der Annahme aus, dass mobile Clients via VPN auf einen File-, Mail- und Imapserver im LAN zugreifen sollen.

  +------------------+
  |                  |
  | File-Mail-Imap-  |
  |           Server |
  |                  |
  |------------------|
  |   10.10.10.20    |
  +------------------+
          |
          |
          |   LAN  10.10.10.0/24
    ----------------------------	
             |
             |
           eth0
    +------------------+
    |    10.10.10.1    |
    |------------------|                      +------------------+
    |              |   |                      |  Android Client  |
    |              |   |                      |------------------|
    | Linuxrouter  |eth1------/INTERNET/------| ppp0:10.10.15.81 |
    |              |   |                      |------------------|
    |              |   |                      |     a.b.c.d      |
    |------------------|                      +------------------+
    |    10.10.15.1    |
    +------------------+
           eth2
             |
             |  DMZ  10.10.15.0/24
    -------------------------------
           |
           |
         eth0
  +-------------------+
  |    10.10.15.20    |
  |-------------------|
  | ppp0: 10.10.15.80 |
  |-------------------|
  |                   |
  |L2TP/IPSec Gateway |
  |                   |
  +-------------------+
		
 

L2TP over IPSec verwendet L2TP (Layer 2 Tunneling Protocol), um einen Tunnel zwischen Mobil Client und VPN-Server bereitzustellen, PPP erzeugt die Tunnel Interfaces, IPSec sorgt für die Security.

Für die Bereitstellung der hier diskutierten Installation werden die folgenden Geräte und Software Komponenten verwendet:

  • Beim Host System der Gateway Maschine bleiben wir selbstverständlich (!) bei Slackware, in diesem Fall bei Slackware 13.0 mit Kernel 2.6.29.6.
  • Die Kernel Headers sind in Slackware 13.0 enthalten.
  • Openssl ist als openssl-0.9.8k in Slackware 13.0 enthalten.
  • Der PPP Daemon ist als ppp-2.4.4 in Slackware 13.0 enthalten.
  • IPSec wird mit Hilfe des NETKEY IPSec Kernel Stacks bereitgestellt, der standardmässig im 2.6er Kernel enthalten ist.
  • Als IPSec Key Exchange Server (IKE) wird Racoon verwendet. Racoon ist Teil des Pakets ipsec-tools-0.7.3. Download: Links.
  • Als L2TP Daemon dient xl2tpd-1.2.4. Download: Links.
  • Das Client Gerät ist Google Nexus 7 mit Android 4.3 und Android Kernel 3.4.0.

13.3 Installation des L2TP/IPSec Servers auf der Gateway Maschine

ipsec-tools-0.7.3.tar.bz2 entpacken, kompilieren und installieren.

$ tar -xjvf ipsec-tools-0.7.3.tar.bz2
$ cd /ipsec-tools-directory-tree

 

$ ./configure --disable-security-context --enable-natt --enable-dpd
$ make
# make install
 

Überprüfen, ob der pppd (Point to Point Protocol) Daemon auf dem Host System installiert ist. Wenn nicht, das entsprechende Paket nachinstallieren.

# installpkg ppp-2.4.4-i486-1.txz
 

Das Slackware Paket xl2tpd erzeugen und installieren. Dazu:

Von Links xl2tpd.tar.gz und xl2tpd-1.2.4.tar.gz herunterladen.

xl2tpd.tar.gz an geeigneter Stelle entpacken, beispielsweis in /home/myuser/

xl2tpd-1.2.4.tar.gz ins Verzeichnis /home/myuser/xl2tpd/ kopieren.

Das Script xl2tpd.SlackBuild ausführen.

Damit wird das Slackware Paket /tmp/xl2tpd-1.2.4-i486-1_SBo.tgz erzeugt. Dieses kann mit Hilfe von installpkg installiert werden.

$ tar -xzvf xl2tpd.tar.gz
$ cp xl2tpd-1.2.4.tar.gz /home/myuser/xl2tpd/
$ cd /home/myuser/xl2tpd/
# ./xl2tpd.SlackBuild

 

# mkdir /var/run/xl2tpd
# installpkg /tmp/xl2tpd-1.2.4-i486-1_SBo.tgz
 

13.4 Konfiguration von L2TP over IPSec auf der Gateway Maschine

Systemkonfiguration: Auf der Gateway Maschine muss IP-Forwarding aktiviert werden. Damit die Einstellung den nächsten Reboot übersteht, kann sie in /etc/rc.d/rc.local eingetragen werden.

# /etc/rc.d/rc.local
#
# On a VPN server machine IP forwarding must be enabled.
echo "Enable IP packet forwarding..."
echo 1 > /proc/sys/net/ipv4/ip_forward
 

VPN Installationen, insbesondere VPN Installationen, die mobile Clients mit unbekannten IP-Adressen beinhalten, sollten ihre Peers mittels RSA Zertifikaten authentisieren.

Für die nötigen Funktionstests anlässlich einer Neuinstallation bietet sich aber die Authentisierung mittels PSK (Pre Shared Key) an. Auf die Einrichtung einer zertifikatsbasierten Authentisierung wird weiter unten eingegangen.

Konfiguration von racoon

Das racoon und das setkey Binary werden defaultmässig nach /usr/local/sbin installiert. Weiterhin sind die folgenden Files anzulegen und Permissions zu setzen:

# mkdir /etc/racoon
# mkdir /etc/racoon/certs
# touch /etc/racoon/racoon.conf
# touch /etc/racoon/psk.txt
# touch /etc/setkey.conf
# touch /var/log/racoon.log
# chmod 0700 /etc/racoon
# chmod 0600 /etc/racoon/racoon.conf
# chmod 0600 /etc/racoon/psk.txt
# chmod 0600 /var/log/racoon.log
 

Die IPSec Konfigurationsfiles
/etc/racoon/racoon.conf
/etc/racoon/psk.txt
/etc/setkey.conf
wie folgt editieren.

# /etc/racoon/racoon.conf
# Configuration file for racoon on gateway 10.10.15.20
#
# NOTE: This file must be owned by root, permissions 
# must be set to 0600, else, racoon will refuse to start.
#
#
path pre_shared_key "/etc/racoon/psk.txt";

##path certificate "/etc/racoon/certs";

listen {
        isakmp 10.10.15.20[500];
        isakmp_natt 10.10.15.20[4500];
}

timer {
        natt_keepalive 12 second;       # Send keepalive packets to preseve the firewall's NAT.
}

# Remote client is roadwarrior client.
remote anonymous {
        exchange_mode aggressive,main;  # Work mode for IKE first phase.
        
##        my_identifier asn1dn;
##        certificate_type x509   "server.crt"  "server.key";
##        ca_type x509            "cacert.crt";
        
        passive on;                     # Passive on - useful for a server.
        generate_policy on;             # Generate SPs from the initial connection request.
        nat_traversal on;               # Enable NAT-T.
        dpd_delay 40;                   # DeadPeerDetection, drop tunnel if the client is dead.
        proposal_check claim;           # Chose initiator or server time settings.
        ike_frag on;                    # IKE fragmentation enabled, helpful behind firewalls.
        lifetime time 28800 sec;        # Lifetime of IKE-SA.

        # Agreement proposal in IKE first phase.
        proposal {
                encryption_algorithm 3des; # des | 3des | aes | blowfish
                hash_algorithm sha1; # md5 | sha1 | sha256
                authentication_method pre_shared_key;
##                authentication_method rsasig;
                dh_group modp1024; # modp768 | modp1024 | modp1536
        }
}

# Define parameters for the Security Association for IKE second phase.
sainfo anonymous {
        lifetime time 1800 sec;        # Lifetime of IPSec-SA.
        #pfs_group modp1024;            # Mac and Android peers appear not to like this setting.
        encryption_algorithm aes,3des;
        authentication_algorithm hmac_sha1, hmac_md5;
        compression_algorithm deflate;
}
 
# /etc/racoon/psk.txt
# File for pre-shared keys for IKE authentication on gateway 10.10.15.20
#
#
# Format for clients with known IP is: 'IP' 'key'
a.b.c.d     greatSecret

# Format for Android clients is: 'IPSec Identifier' 'key
myString    topSecret
 
# /etc/setkey.conf
# Configuration file for setkey on 10.10.15.20
#
# 
# Flush your SAD and SPD.
flush;
spdflush;

# Create policies for racoon.
# All tunnels to this host shall use ESP transport mode.

spdadd 0.0.0.0/0 10.10.15.20[l2tp] udp -P in  ipsec esp/transport//require;
spdadd 10.10.15.20[l2tp] 0.0.0.0/0 udp -P out ipsec esp/transport//require;
 

racoon im Debug Modus im Vordergrund starten.

# /usr/local/sbin/racoon -d -F -f /etc/racoon/racoon.conf -l /var/log/racoon.log
 

Wenn racoon ohne Fehlermeldungen startet, kann mit /etc/rc.d/rc.racoon ein Script angelegt werden, das den Daemon in die Bootsequenz des Hosts einbindet. Siehe racoon.conf. (Achtung Pfade!)

Konfiguration von xl2tpd

Das xl2tpd Binary wird nach /usr/sbin installiert. Die Konfigurationsfiles sind:
/etc/xl2tpd/xl2tpd.conf
/etc/ppp/options.xl2tpd
/etc/ppp/options
/etc/ppp/chap-secrets
Die Konfigurationsfiles müssen mit den folgenden Einträgen versehen werden:

; /etc/xl2tpd/xl2tpd.conf
; Configuration file for L2TP server.
;
; NOTE: xl2tpd will refuse to start if this file   
; contains lines of more than about 80 characters.

[global]
listen-addr = 10.10.15.20
port = 1701
; Disable the built in access control.
access control = no

; LNS = L2TP Network Server, i.e. the server side configuration of L2TP.
[lns default]
; Set the range of addresses the server will assign    
; to the remote endpoints of the connecting PPP tunnels.
ip range = 10.10.15.81-10.10.15.89
; Set the local endpoint of the tunnel.
local ip = 10.10.15.80
; Set the name of the server as far as L2TP is concerned,  
; this may also be used for authentication.
name = l2tpd
length bit = yes
require authentication = yes
unix authentication = no
require chap = yes
refuse pap = yes
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
 
# /etc/ppp/options.xl2tpd
# Config file used by xl2tpd when calling pppd.
# The following commands are LCP (Link Control Protocol) options used by pppd.
#
#
debug                   # Debug via syslog. 
mtu 1350
name l2tp
lock                    # Use UUCP-style device locking.
noccp                   # CCP seems to confuse Android clients, better turn it off.
proxyarp                # Add an entry to the ARP table giving the IP of the remote peer.
auth                    # Require the peer to authenticate itself using PAP or CHAP.
require-chap
require-mschap-v2
#lcp-echo-interval 60   # Send an LCP echo-request frame to the peer every n sec.
#lcp-echo-failure  100  # Presume the peer is dead after n failed replies. 
noipdefault             # Local IP will have to be supplied.
nodefaultroute
 
# /etc/ppp/chap-secrets
# Secrets for authentication using CHAP
# USERNAME: Name of the client (username in the Android auth dialogue)
# SERVER: Name of the l2tp server ( as defined in /etc/xl2tpd/xl2tpd.conf )
# SECRET: Pw of the user
# IP ADDRESS: IP address of the client
#
# USERNAME     SERVER       SECRET      IP ADDRESSES
myuser            *       "topsecret"         *
 

Die lcp-echo Einträge in /etc/ppp/options scheinen die Einträge in /etc/ppp/options.xl2tpd zu übersteuern, sie werden daher auskommentiert.

# /etc/ppp/options
...
#lcp-echo-interval 30
#lcp-echo-failure  200
...
 

xl2tpd im Vordergrund starten und auf Fehlereldungen achten.

# /usr/sbin/xl2tpd -D -c /etc/xl2tpd/xl2tpd.conf
 

Wenn die debug Option in /etc/ppp/options.xl2tpd aktiviert ist, schickt pppd seine Log Meldungen an syslog. Damit syslog die Pakete zeigt, ist der folgende Eintrag in /etc/syslog.conf nötig:

daemon.* -/var/log/ppp.log

Danach das File /var/log/ppp.log anlegen und syslog neu starten.

Wenn der L2TP Server korrekt started, das zugehörige Boot Script /etc/rc.d/rc.xlt2tpd erstellen und installieren.

#!/bin/sh
#
# /etc/rc.d/rc.xl2tpd
# Start/stop/restart xl2tpd
#
# To start xl2tpd automatically at boot, make this file   
# executable: chmod 755 /etc/rc.d/rc.xl2tpd
#
# Adapt /etc/rc.d/rc.M  (start)
# Adapt /etc/rc.d/rc.K  (runlevel 1)
# Adapt /etc/rc.d/rc.6  (system shutdown)

XL2TP_DIR="/usr/sbin"
XL2TP_CONF="/etc/xl2tpd"

xl2tpd_start() {
  # Sanity checks. Exit if there are no config files for xl2tpd.
  if [ ! -r ${XL2TP_CONF}/xl2tpd.conf ]; then # no config file, exit:
    exit
  fi

  if ! /bin/netstat -naup | grep xl2tpd 1> /dev/null 2> /dev/null; then 
    echo "Starting xl2tpd"
    sleep 1

    if [ -x ${XL2TP_DIR}/xl2tpd ]; then
      echo "  ${XL2TP_DIR}/xl2tpd -c ${XL2TP_CONF}/xl2tpd.conf"
      ${XL2TP_DIR}/xl2tpd -c ${XL2TP_CONF}/xl2tpd.conf 
    fi

    else
     echo "xl2tpd is already running."
  fi
}

xl2tpd_stop() {
  killall -3 ${XL2TP_DIR}/xl2tpd 2> /dev/null
}

xl2tpd_restart() {
  xl2tpd_stop
  sleep 1
  xl2tpd_start
}

xl2tpd_debug() {
  if [ -x ${XL2TP_DIR}/xl2tpd ]; then
    echo "  running xl2tpd in the foreground"
    ${XL2TP_DIR}/xl2tpd -D  -c ${XL2TP_CONF}/xl2tpd.conf 
  fi
}
# -D = run in foreground, not as a daemon.

case "$1" in
'start')
  xl2tpd_start
  ;;
'stop')
  xl2tpd_stop
  ;;
'restart')
  xl2tpd_restart
  ;;
'l2tpdebug')
  xl2tpd_debug
  ;;
*)
  echo "usage $0 start|stop|restart|l2tpdebug"
  exit 1
  ;;
esac
exit 0
 

13.5 Firewall Regeln

Um die Server auf dem Gateway zu erreichen, müssen die Firewall Regeln auf Linuxrouter so angepasst werden, dass Pakete des mobilen Clients an die internen Server weitergeleitet werden. Also müssen neue, aus dem Internet stammende Pakete für die Ports 500 (p_ike) und 4500 (p_nat_t), erlaubt werden.

${IPTABLES} -A FORWARD -i ${EXT} -o ${INT} -d ${IPSEC_VPN_SERVER} -p UDP \    
	  --dport ${p_ike} -j ACCEPT
${IPTABLES} -A FORWARD -i ${EXT} -o ${INT} -d ${IPSEC_VPN_SERVER} -p UDP \
	  --dport ${p_nat_t} -j ACCEPT
 

Ausserdem muss das Port Forwarding der Pakete zur Gateway Maschine eingerichtet werden.

${IPTABLES} -t nat -A PREROUTING  -p UDP  \
    --dport ${p_ike} -i ${EXT} -j DNAT --to-destination ${IPSEC_VPN_SERVER}:${p_ike}
${IPTABLES} -t nat -A PREROUTING  -p UDP  \
    --dport ${p_nat_t} -i ${EXT} -j DNAT --to-destination ${IPSEC_VPN_SERVER}:${p_nat_t}
 

Weiterhin müssen Verbindungen vom DMZ Gateway 10.10.15.20 zum Fileserver 10.10.10.20 im LAN erlaubt werden.

13.6 Android Client Konfiguration

Für die Authentisierung des Clients mittels PSK muss auf dem Android Tablet das folgende Profil erstellt werden:

Settings -> Wireless & Networks -> More -> VPN -> +

Name: MyVPN_PSK
Type: L2TP/IPSec PSK
Server address: my.server.address
L2TP secret: (not used)
IPSec identifier: myString
IPSec preshared key: topSecret
Save
 

Anschliessend das neu erstellte Profil antippen, bei Username und Password die Werte eingeben, die in /etc/ppp/chap-secrets definiert wurden und Connect drücken.

Im Erfolgsfall wird Android die Meldung ausgeben: Connected To 10.10.15.80.

Sollte sich der Erfolgsfall nicht sogleich einstellen ;-(, das Debugging Level von racoon erhöhen, um den Fehler einzugrenzen.

HINWEIS ZUM DEBUGGING: Eine racoon Meldung von der folgenden Art ist kein Fehler, sondern der Hinweis, dass keine vordefinierte Policy vorhanden ist.

ERROR: such policy does not already exist: "p.q.r.s/32[49223]  \
       a.b.c.d/32[1701] proto=udp dir=in"
 

HINWEIS ZU PSK: Falls die Authentisierung mittels PSK im Produktivbetrieb beibehalten wird, dann sollten unbedingt starke Schlüssel verwendet werden. 128 beziehungsweise 192 Bit Schlüssel lassen sich mit den folgenden Kommandos generieren:

$ dd if=/dev/random count=16 bs=1| xxd -ps
$ dd if=/dev/random count=24 bs=1| xxd -ps
 

Für die Authentisierung der Peers mittels Zertifikaten, müssen die entsprechenden Einträge in /etc/racoon/racoon.conf aktiviert werden.

# /etc/racoon/racoon.conf
...
##path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";
...
        my_identifier asn1dn;
        certificate_type x509   "server.crt"  "server.key";
        ca_type x509            "cacert.crt";
...
##                authentication_method pre_shared_key;
                authentication_method rsasig;
 

Anschliessend können die Zertifikate für Server und Client erzeugt werden. Siehe: http://www.openssl.org/docs/apps/CA.pl.html.

( Beachten, dass der CN des Server Zertifikats den FQDN des Servers enthalten muss. Im vorliegenden Beispiel also my.server.address. )

Die Zertifikatsfiles des L2TP/IPSec Servers, also server.crt, server.key und cacert.crt, können direkt ins Verzeichnis /etc/racoon/certs der Host Maschine kopiert und mit den nötigen Ownerships und Permissions versehen werden.

# chown root:root /etc/racoon/certs/server.crt
# chown root:root /etc/racoon/certs/server.key
# chown root:root /etc/racoon/certs/cacert.crt
# chmod 0444 /etc/racoon/certs/server.crt
# chmod 0400 /etc/racoon/certs/server.key
# chmod 0444 /etc/racoon/certs/cacert.crt
 

Für den Import in den Android Client müssen das Zertifikat und der Private Key des Clients, sowie das zugehörige CA-Zertifikat, mittels openssl in ein p12-Container-File integriert werden.

BEACHTEN: Das p12-File muss passwortgeschützt sein, sonst lässt es sich auf dem Client nicht installieren.

Dann muss das p12-File mit der Endung .pfx versehen und ins Root-Verzeichnis (/sdcard/) des Android Geräts kopiert werden. Die Installation erfolgt mittels «Install from storage».

ACHTUNG: Das Gerät muss mit einem «Screen Lock» geschützt sein, damit sich die Zertifikate installieren lassen.

Settings -> Personal -> Security -> Install from storage

Anschliessend kann das Profil für den Zugriff auf den L2TP/IPSec Server angelegt werden.

Settings -> Wireless & Networks -> More -> VPN -> +

Name: MyVPN_RSA
Type: L2TP/IPSec RSA
Server address: my.server.address
L2TP secret: (not used)
IPSec user certificate: name_of_pfx_bundle
IPSec CA certificate: name_of_pfx_bundle
IPSec server certificate: (received from server)
Save
 

HINWEIS: Nach einem Android System Update muss der p12-Container u.U. neu installiert werden!

13.7 Services im LAN via L2TP/IPSec Tunnel aufrufen

Vergl: Links.

13.8 Weitere Host Konfigurationen

Logfiles wachsen ohne Grenzen - wenn sie nicht daran gehindert werden. /var/log/racoon.log und /var/log/ppp.log
sollten also via logrotate regelmässig überwacht werden.

Forwarding Regeln auf Linuxrouter und weiteren Hosts?

 


Prev Home Next
OpenVPN Content VPN Zugriff auf OS X