BLog

Imprint	Impressum
Privacy	Datenschutz
Disclaimer	Haftung
Downloads

L2TP/IPsec-VPN-Einwahl auf den FreeBSD-Home-Server

Mit einem VPN - Virtual Private Network - lassen sich entfernte Clients (Computer, Smart-Phones, Tablets, usw.) aus dem Internet heraus in das private Heim-Netzwerk schalten, und zwar effektiv so, als ob sie tatsächlich zu Hause wären. Bei modernen Systemen ist die VPN-Leitung zwischen dem externen Client und dem Server abhör- und manipulationssicher verschlüsselt, und damit kann man VPN-Clients einen Zugriff auch auf solche Daten und Dienste im Heim-Netzwerk gewähren, die ansonsten aus Sicherheitsgründen nicht vom Internet aus zugänglich sind:

Datei-Dienste - FTP, AFP, SMB, NFS,
Interne Clients, wie PC’s, Netzwerk-Drucker, WLAN-Access-Points und evtl. Hausgeräte,
Name-Server, Time-Server,
etc.

Weitere Einsatzgebiete und die Benutzung von externen VPN-Diensten erklärt ein ausführlicher Fachartikel mit mehreren Videos und Infografiken auf PrivacyTutor: Alles was du über VPNs wissen musst – einfach erklärt

Wir hatten unseren FreeBSD-Home-Server als Gateway in das Internet eingerichtet, und diese Funktion kann er ohne weiteres auch für VPN-Clients einnehmen, so daß externe Clients auch in fremden Netzen, z.B. in öffentlichen WLAN’s, im Internet-Café, im Hotel oder am Flughafen, sicher vor Man-in-the-Middle-Angriffen und anderen Fährnissen sind.

Jedenfalls spielt das VPN eine wichtige Rolle in unserer Umsetzung der Castle-Doctrin. Unsere Clients, auch wenn sie unterwegs sind, werden mit VPN in unsere Burg, d.h. hinter die Zugbrücke (Firewall) gebracht, und nicht-autorisierte Eingriffe (mit Ausnahme von Bagatellen) stellen eine Straftat nach § 303b Computersabotage dar - auch der Versuch ist strafbar. Ein Abfangen einer ungeschützten HTTP-Übertragung mag vielleicht als quasi versehentliche Bagatelle noch soeben durchgehen, dagegen setzt ein aufwendiger kryptographischer Angriff auf eine maximal gesicherte VPN-Verbindung eine besondere kriminelle Energie voraus, und die Anwälte, die das noch als Bagatelle durchzubringen vermögen, müssen schon von einer besonderen Klasse sein.

Es gibt ene Reihe von Verfahren und Verfahrensvarianten zum Aufbau von VPN-Verbindungen. Die meistgenutzten Client-Betriebssysteme, nämlich Windows, Mac OS X, iOS, Android, kommen von Haus aus mit der notwendigen Einwahlsoftware zum Aufbau von IPsec-basierten VPN’s. Das ältere PPTP-VPN-System in der Microsoft-Variante ist zwar ähnlich weit verbreitet, aber dessen Anmeldeverfahren ist kompromittiert, und PPTP soll deshalb nicht mehr benutzt werden. Ansonsten kommt noch OpenVPN, das zum Aufbau des VPN die asymmetrische TLS-Verschlüsselung mittels X.509-Zertifikaten einsetzt, in Frage. Dazu muß man allerdings sowohl auf dem Server als auch auf allen Clients die entsprechende Software installieren.

In diesem Artikel wird die Einrichtung der zweistufigen Verfahrensvariante L2TP/IPsec auf dem FreeBSD-Home-Server beschrieben. Dabei wird zunächst eine verschlüsselte VPN-Verbindung via IPsec zwischen zwei Computern aufgebaut, über die dann durch L2TP gesteuert die Benutzeranmeldung und der eigentliche Zugriff laufen.

Die eingebauten L2TP/IPsec-Clients sind unter Mac OS X und iOS besonders gut gelungen, und sie funktionieren (die richtigen Anmeldedaten einmal vorausgesetzt) in allen Lebenslagen, d.h. mit und ohne NAT - Network Address Translation - sei es auf Server- und/oder Client-Seite. An den beteiligten Firewalls müssen nur die UDP-Ports 500 und 4500 in beiden Richtungen durchgängig sein.

Der in Windows eingebaute L2TP/IPsec-Client funktioniert von Haus aus nicht einwandfrei mit NAT. Man kann ihn aber mit einer von Microsoft beschriebenen Registry-Einstellung zu gutem Benehmen überreden. Dazu muß in der Windows-Registry unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent die neue DWORD-Variable AssumeUDPEncapsulationContextOnSendRule angelegt und der Wert 2 eingetragen werden.

L2TP/IPsec-Installation auf dem FreeBSD-Home-Server

Seit FreeBSD 11 ist IPsec Bestandteil des Standard-Kernels GENERIC und seit 11.2 ist auch NAT-T(raversal) im Kernel aktiviert. Bei früheren FreeBSD-Versionen muß man das IPsec-Modul in der Kernel-Konfiguration aktivieren und dann den Kernel neu kompilieren. Dazu erstellt man mit dem Kommandozeilen-Editor nano(1) unter /usr/src/sys/amd64/conf/GENERIC_IPsec ein Kernel-Konfigurations-Deckblatt, das als erstes über die include-Direktive die Standardkonfiguration - GENERIC - dazulädt, und dannach die zusätzlichen die IPsec-Optionen enthält.

nano /usr/src/sys/amd64/conf/GENERIC_IPsec

include GENERIC
ident   GENERIC_IPsec    

# Options for IPsec
options IPSEC
options IPSEC_NAT_T
device  crypto

Im obigen Fall wird ein FreeBSD-Kernel für ein 64bit-x86-System eingerichtet, das Synonym für diese Architektur ist amd64. Im Falle anderer Server-Hardware, ist im Pfad-Namen das Kürzel amd64 durch dasjenige der tatsächlichen Architektur auszutauschen. Hierfür kommen in Frage: amd64, i386, arm, aarch64, ia64, mips, powerpc, pc98, sparc64. Mit dem Befehl make buildkernel würde im Verzeichnis /usr/src der neue Kernel kompiliert und mit make installkernel installiert. Je nach System-Leistung kann das 30-90 min in Anspruch nehmen.

Wie gesagt, bei den neuen FreeBSD-Versionen kann man einfach den Standardkernel benutzen, und FreeBSD ab 11.2 enthält auch wichtige Verbesserungen beim IPsec-NAT-T(raversal), und damit kommen nunmehr auch zickige Clients mit FreeBSD-IPsec-VPN und NAT klar.

Bitte einfach immer die aktuelle FreeBSD-Version benutzen - die ist heute FreeBSD 12.0-RELASE-p2

Einwahl-Software installieren

Ein L2TP/IPsec-System besteht vom Prinzip her aus zwei Teilen, nämlich aus L2TP - Layer 2 Tunneling Protocol und IPsec - Internet Protocol Security. Die L2TP-Einwahl wird durch die Software net/mpd5 abgedeckt, und über das Paket security/strongswan kann man den IPsec-Endpunkt konfigurieren.

Beide Software-Pakete können als binäre Pakete über das pkg(8)-System installiert werden:

pkg install mpd5
pkg install strongswan

L2TP/IPsec-VPN-Konfiguration

IPsec-Server-Einrichtung

Zur Einrichtung von strongSwan müssen 3 Konfigurationsdateien im Verzeichnis /usr/local/etc bearbeitet werden, nämlich strongswan.conf(5), ipsec.conf(5) und ipsec.secrets(5). Der Kommandozeilen-Editor nano(1) wird zur Bearbeitung der jeweiligen Konfigurations-Datei aufgerufen. Die Beispiel-Einstellungen werden jeweils entfernt und an deren Stelle die in der Folge gezeigten Inhalte in das jeweilige Eingabefenster kopiert:

nano /usr/local/etc/strongswan.conf

charon
{
   load_modular = yes
   plugins
   {
      include strongswan.d/charon/*.conf
   }

   install_routes = no
   process_route = no

   syslog
   {
      identifier = ipsec
      daemon
      {
         ike_name = yes
      }
   }
}

nano /usr/local/etc/ipsec.conf

conn L2TP/IPsec-PSK
   keyexchange = ikev1
   type = transport
   ike = aes256-sha1-modp1024

   leftauth = psk
   left = %defaultroute
   leftprotoport = 17/1701

   rightauth = psk
   right = %any
   rightprotoport = 17/%any

   auto = add

nano /usr/local/etc/ipsec.secrets

: PSK "Dp5GU42F7omBhMVLiJi5V6Em3JWTyJ1"

Die Dateien werden jeweils mit <ctrl>-<o> gespeichert und mit <ctrl>-<x> wird auch nano jeweils beendet. Die zuletzt bearbeitete Datei enthält den Pre-shared Key, kurz PSK, und im vorliegenden Fall wurde er mit dem unter Mac OS X im Schlüsselbund-Programm integrierten Kennwortassistenten erzeugt:

Jeder denke sich bitte einen eigenen PSK aus. Der Pre-shared Key darf auch Leerzeichen, Umlaute und Sonderzeichen enthalten, man muß allerdings auf mögliche unterschiedliche Zeichenkodierungen achten.

Hier wurde ein sogenannter Wildcard-PSK angelegt, d.h. jeder VPN-Client, der diesen PSK kennt, darf sich von einer beliebigen IP-Adresse aus am VPN-Server anmelden. Es soll nicht unerwähnt bleiben, daß IPsec-Puristen kategorisch die Wildcard-PSK-Methode ablehnen - Stichwort Gruppen-Paßwort - soll heißen, wenn der shared Key (gemeinsamer Schlüssel) kompromittiert ist, dann ist der VPN-Zugriff offen. In großen Organisationen ist das tatsächlich problematisch, denn je mehr Kollegen und Kolleginnen sich den gemeinsamen Schlüssel unter ihre Tastatur oder neben den Bildschirm kleben, umso wahrscheinlicher ist es, daß sich irgendwann die halbe interessierte Welt per VPN in besagte Organisation einwählen kann. Bei meinem FreeBSD-Home-Server-L2TP/IPsec stellt sich die Situation allerdings ein wenig anders dar. Die Anzahl der User ist überschaubar, alle sind vertrauenswürdig, und niemand außer mir kennt den Pre-shared Key. Damit das so bleibt, ist es sinnvoll dessen Zugriffsberechtigungen drastisch einzuschränken:

chmod 0000 /usr/local/etc/ipsec.secrets

L2TP-Server-Einrichtung

Das Konfigurations-Verzeichnis /usr/local/etc/mpd5 wurde automatisch mit der Installation von mpd5(8) erzeugt. Darin wird mit dem Kommandozeilen-Editor nano(1) die Datei mpd.conf erzeugt:

nano /usr/local/etc/mpd5/mpd.conf

Der folgende Inhalt wird in das Eingabefenster kopiert, wobei das admin-Paßwort und die IP-Adressen in blau durch ein gültiges Paßwort und die tatsächlichen Adressen ersetzt werden müssen:

startup:
# configure mpd users
	set user admin PASSWORD admin
# configure the console
	set console self 127.0.0.1 5005
	set console open
# configure the web server
	set web self 192.168.1.35 5006
	set web open

default:
	load l2tp_server

l2tp_server:
# Define dynamic IP address pool -- 192.168.1.128/26
	set ippool add pool_l2tp 192.168.1.128 192.168.1.191

# Create clonable bundle template named B_l2tp
	create bundle template B_l2tp
	set bundle enable compression
	set iface enable proxy-arp
	set iface enable tcpmssfix
	set iface mtu 1280

# Specify IP address pool for dynamic assigment
	set ipcp yes vjcomp
	set ipcp ranges 192.168.1.35/32 ippool pool_l2tp
	set ipcp dns 192.168.1.35

# Create clonable link template named L_l2tp
	create link template L_l2tp l2tp
	set link action bundle B_l2tp
	set link keep-alive 0 0
	set link yes acfcomp protocomp
	set link no pap chap eap
	set link enable chap-msv2

# Configure L2TP
	set l2tp self 0.0.0.0
	set l2tp disable dataseq

# Allow to accept calls
	set link enable incoming

In einem vorausgegangenen Artikel wurden bereits Überlegungen zu sinnvollen IP-Adressbereichen angestellt, und diese haben nun in der obigen Einstellung, ippool pool_l2tp 192.168.1.128 192.168.1.191, eine weitere Anwendung gefunden. Selbstverständlich stellen wir unseren Clients auch unseren entspamten DNS-Server bereit, nämlich ipcp dns 192.168.1.35.

Nun muß noch die Datei mit den L2TP-Benutzern und Paßwörtern /usr/local/etc/mpd5/mpd.secret angelegt werden:

nano /usr/local/etc/mpd5/mpd.secret

Beispielsweise enthält diese Datei auf meinem FreeBSD-Home-Server folgendes:

# User    Password
andreia   TnVpmPVI1MJc
nikolas   yOEs1qixy1Rk
rolf      BqD5IMrKfoyu

Bitte die obigen Einträge durch sinnvolle Benutzernamen und Paßworte ersetzen. Ausserdem müssen noch die Zugriffsberechtigungen eingeschränkt werden:

chmod 0000 /usr/local/etc/mpd5/mpd.secret

Logging via Syslog

In /usr/local/etc/strongswan.conf wurde, eingestellt, daß die Protokollierung über syslogd(8) und dessen daemon-Facility erfolgen soll. mpd5 nutzt von Haus aus diese Facility, so wie andere Netzwerkdienste, darunter dhcpd, netatalk, samba, etc. auch. Mit den folgenden zusätzlichen Einträgen in den beiden relevante Konfigurations-Dateien syslog.conf(5) und newsyslog.conf(5) leitet man das gesamte Net-Services-Logging in eine Log-Datei hinein, nämlich /var/log/etc/net-services.log, und zwar inklusive Log-Rolling alle 24 h. Die neuen Eintragungen sind unten in violett gehalten:

nano /etc/syslog.conf

...
auth.info;authpriv.info                         /var/log/auth.log
daemon.*                                        /var/log/net-services.log
mail.info                                       /var/log/maillog
...

nano /etc/newsyslog.conf

...
/var/log/lpd-errs                       644  7     100  *     JC
/var/log/net-services.log               640  7     *    @T00  JC
/var/log/maillog                        640  7     *    @T00  JC
...

Zusätzliche Firewall-Einstellungen

Die im Vergleich zu den bisherigen Firewall-Einstellungen im ipfw(8)-Script /root/config/ipfw.conf vorzunehmenden Änderungen sind unten in violett eingetragen:

#!/bin/sh

for iface in `/sbin/ifconfig -l` ; do
   desc=`/sbin/ifconfig $iface | /usr/bin/sed -n '/.description: /{s///;s/ .*//;p;}'`
   if [ "$desc" == "LAN" ] ; then
      LAN="$iface"
   elif [ "$desc" == "WAN" ] ; then
      WAN="$iface"
   fi
done

/sbin/ipfw -q flush
/sbin/ipfw -q table all destroy
/sbin/ipfw -q nat 1 config if $WAN unreg_only reset

# There can be only one (DHCP Server in the local net),
# and that's me - so kill the others.
/sbin/ipfw -q add 5 deny udp from not me 67 to any 68 via $LAN

# Allow anything else within the LAN - interfaces with heavy traffic shall come first
/sbin/ipfw -q add 10 allow ip from any to any via $LAN
/sbin/ipfw -q add 20 allow ip from any to any via lo0
/sbin/ipfw -q add 30 allow ip from any to any via ng*

# Don't trust 3rd party network devices (Printer, Router, House Devices, etc.),
# which we have put into the upper network range 192.168.1.192-255
/sbin/ipfw -q add 60 deny ip from 192.168.1.192/26 to any via $WAN

# Catch spoofing of incomming packets
/sbin/ipfw -q add 70 deny ip from any to any not antispoof in recv $WAN

# NAT rule for incomming packets
/sbin/ipfw -q add 100 nat 1 ip4 from any to any in recv $WAN
/sbin/ipfw -q add 101 check-state

# Rules for outgoing traffic - allow everything that is not explicitely denied
# Prohibit access to external SMTP and DNS servers (ports 25, 53, 1701 and 5353)
/sbin/ipfw -q add 1000 deny ip from not me to any 25,53 out xmit $WAN
/sbin/ipfw -q add 1010 deny ip from any to any 1701,5353 out xmit $WAN

# Allow all other outgoing connections
/sbin/ipfw -q add 2000 skipto 10000 tcp from any to any out xmit $WAN setup keep-state
/sbin/ipfw -q add 2010 skipto 10000 udp from any to any out xmit $WAN keep-state

# Rules for incomming traffic - deny everything that is not explicitely allowed
/sbin/ipfw -q add 5000 allow tcp from any to me 11 in recv $WAN setup keep-state
/sbin/ipfw -q add 5010 allow udp from any to me 500,4500 in recv $WAN keep-state
/sbin/ipfw -q add 5020 allow udp from any to me in recv $WAN frag

# Catch tcp/udp packets, but don't touch gre, esp, icmp traffic.
# Catch tcp/udp packets, but don't touch gre, esp, icmp traffic
/sbin/ipfw -q add 9998 deny tcp from any to any via $WAN
/sbin/ipfw -q add 9999 deny udp from any to any via $WAN

# NAT rule for outgoing packets
/sbin/ipfw -q add 10000 nat 1 ip4 from any to any out xmit $WAN

# Allow anything else - just in case ipfw has not been configured as open firewall
/sbin/ipfw -q add 65534 allow ip from any to any

Für jede aufgebaute VPN-Verbindung stellt das L2TP-Modul von MPD5 ein eigenes internes Netzwerk-Interface bereit, wobei die Gerätekennungen dieser Interfaces fortlaufend durchnummeriert sind und auf ng0, ng1, ng2, ... ngN lauten. Jedenfalls muß die Firewall den gesamten Datenverkehr über diese internen VPN-Interfaces erlauben - Regel 30.

Der IPsec-Service wartet auf den Ports 500 und 4500 auf Verbindungen von externen VPN-Clients, und die Firewall muß diese Verbindungen freigeben - Regel 5010. Microsofts IPsec-Clients übertragen jede Menge UDP-Paket-Fragmente, die ohne Port-Nummer daherkommen, und hierfür muß eine zusätzliche Regel eingetragen werden, damit die genannten Fragmente passieren können - Regel 5020.

Um den L2TP/IPsec-Server in Betrieb nehmen zu können, müssen vorher folgende Eintragungen zu /etc/rc.conf hinzugefügt werden:

nano /etc/rc.conf

...

### L2TP/IPsec VPN Service
strongswan_enable="YES"
strongswan_interface="stroke"
mpd_enable="YES"

Der FreeBSD-Home-Server wird nun neu gestartet:

shutdown -r now

Nach dem Neustart sollten externe Clients L2TP/IPsec-VPN-Einwahlverbindungen aufbauen können.

L2TP/IPsec-VPN-Aufbau mit Mac OS X

Die VPN-Server-Adresse und der Benutzername wird in den Systemeinstellungen unter Netzwerk/VPN eingetragen (ggf. muß zuvor ein L2TP-VPN-Anschluß mit einem Klick auf das Plus-Zeichen zur Liste hinzugefügt werden):

Das Benutzer-Kennwort, und der Pre-shared Key (= „Shared Secret“) werden unter den „Authentifizierungseinstellungen …“ eingetragen, und die Einstellungen werden mit OK bestätigt:

Durch einen Klick auf die Tasten „Anwenden“ und dann „Verbinden“ wird die L2TP/IPsec-Verbindung zu unserem FreeBSD-Home-Server aufgebaut:

Die VPN-Verbindung kann ab jetzt auch einfach über das VPN-System-Menü aufgebaut bzw. abgebrochen werden:

Unter „Weitere Optionen …“ kann u.a. eingestellt werden, ob der gesamte Internet-Verkehr über die VPN-Verbindung gehen soll, und genau diese Einstellung wird benötigt, damit wir, wenn wir z.B. mit dem MacBook unterwegs sind, nicht in fremden Netzwerken ungeschützten Verkehr betreiben müssen, den der gemeine Spion und andere Kleinkriminelle abfangen könnten:

L2TP/IPsec-VPN-Aufbau mit iOS

Unter iOS befinden sich alle wichtigen VPN-Einstellungen auf einer Seite:

Die L2TP/IPsec-VPN-Verbindung wird einfach mit dem VPN-Schalter in den Einstellungen aufgebaut bzw. abgebrochen. Wenn sich das iOS-Gerät in den Ruhezustand schaltet, dann wird allerdings auch eine bestehende VPN-Verbindung unterbrochen, und man muß sie ggf. neu aufbauen.

L2TP/IPsec-VPN-Aufbau mit Windows 7 bis 10

Unter Windows 7 bis 10 legt man zunächst einen neuen Netzwerkadapter für VPN an und stellt diesen auf L2TP/IPsec ein:

Die L2TP/IPsec-VPN-Verbindung kann man dann durch Doppelklick auf den neuen VPN-Netzwerkadapter herstellen:

Verbindungs-Management

In MPD5 ist ein Web-Server integriert, über den sich der Status der L2TP-Verbindungen anzeigen läßt. Einzelne Verbindungen können zudem abgebrochen werden:

Diskussion auf Twitter: 1088811926371684353