[FF-Düsseldorf] L2TP-VPN Gluon Version

Speed ist nicht alles. Für den einen oder anderen Knotenaufsteller ist es essentiell das die Daten welche von seinem Freifunk Knoten übertragen werden bis zum Gateway/Supernode verschlüsselt sind. Auch die meisten unserer Erklärungen und Grafiken die zeigen wie Freifunk funktioniert, sind genau so angelegt.

2 „Gefällt mir“

Die Verschlüsselung bietet auch bei Fastd kaum Anonymität da das Mesh selbst unverschlüsselt ist, die Störerhaftung ist mit L2TP-VPN genau so auf Seiten des FFRL als Provider wie es bei Fastd der Fall ist.
Nach außen hin ist man nach wie vor aus dem FFRL Netz unterwegs. Der Payload ist weiterhin enkapsuliert.

Außerdem kann ein Angreifer der Daten abgreifen möchte dies über L2TP genau wie bei Fastd ziemlich einfach erreichen.
Man in the Middle Angriffe sind z.b. jederzeit möglich indem der Angreifer MAC oder IP-Adressen der Gateways spoofed. Oder er betreibt selbst einen Fake-Gateway um Clients abzufischen. Freifunk ist kein sicheres Medium, egal ob die Uplinks verschlüsselt sind.

Was du sicher meinst sind Firewalls die die Daten auf Layer 7 analysieren, dies ist aber äußerst kostspielig für Provider und wenn der Elan schon da ist dies zu tun dann kann man auch einfach den Betreiber hinter einem Fastd VPN herausfinden. Anhand der Remote-Adresse lässt sich z.b. herausfinden zu welchem Supernode die Fastd Daten fließen. Zu dem Zeitpunkt weiß der Angreifer schon das es sich um einen Freifunk Node handelt und von welchem DSL-Anschluss diese Daten kommen.

Dies ist aber ein Szenario welches nur angewendet werden würde wenn der DSL-Anschluss schon identifiziert wurde. Irgendwoher muss man ja wissen das genau von diesem Anschluss illegale Downloads initiiert wurden.
Dies wird aber dadurch unterbunden das der Traffic über das FFRL Backbone ins Internet gelangt, dies macht das Szenario also noch unwahrscheinlicher :slight_smile:

Die Sicherheit ist in beiden Fällen relativ dazu wie viel Aufwand ein Provider / Geheimdienst / Whatever betreibt.
Und wie gesagt, dann muss man selbst schon irgendwie mit seinem Surfverhalten (ohne Freifunk) irgendwie ins Fadenkreuz einer Ermittlung geraten sein. Solche Pakete analysiert man zumindest bei Providern nicht einfach so.

Die technischen Gegebenheiten kenne ich. Trotzdem wird in vielen Communitys damit geworben das zwischen Freifunk Knoten und dem Gateway/Supernode die Verbindung verschlüsselt ist. Es wird schwer zu erklären wieso der Verzicht auf Verschlüsselung auf einmal besser sein soll. Einerseits wird seit Snowden verlangt das so viel wie möglich verschlüsselt sein soll und gerade der Freifunk Düsseldorf macht die Rolle Rückwärts.

Der Vorteil vom FastD ist ja auch das ich das Gateway mit dem sich der Knoten verbindet authentifziere. Denn mal eben ein anderes Gateway hinzustellen funktioniert nur, wenn in meinem Knoten dessen Public Key hinterlegt ist. Über welches Gateway dann letztendlich nach BATMAN Metrik die Daten wirklich raus gehen ist erstmal unerheblich.

Bei den Knotenaufstellern haben wir mit dem VPN zwischen Knoten und Gateway durch den FastD ein gewisses Sicherheitsgefühl kommuniziert und aufgebaut. Dieses sollte man nicht leichtfertig für etwas mehr Performance opfern. Ein Angreifer der zwischen meinem Anschluss und dem Supernode und Gateway sitzt, sieht beim FastD VPN halt nur Datenmüll. Aus L2TP kann er jedoch mit weniger Aufwand Dinge abgreifen.

bei uns macht das durchaus sinn. wir betreiben extra DSL Ports nur fuer den Freifunk und gerade da ist durchsatz sehr wichtig. Erste Tests haben fast 50Mbit ergeben auf einen 3600er.

Der Vorteil vom FastD ist ja auch das ich das Gateway mit dem sich der Knoten verbindet authentifziere. Denn mal eben ein anderes Gateway hinzustellen funktioniert nur, wenn in meinem Knoten dessen Public Key hinterlegt ist. Über welches Gateway dann letztendlich nach BATMAN Metrik die Daten wirklich raus gehen ist erstmal unerheblich.

Nicht ganz, jeder kann mit einer VM auf das Fastd Netzwerk zugreifen und im Mesh die Mac-Adresse spoofen.
Nach dem Aufbau der Verbindung findet keinerlei Authentifizierung des Gateways statt. Solange also der Rest des Meshes offen ist, ist auch die authentifizierte Verbindung nicht viel wert.

Bei den Knotenaufstellern haben wir mit dem VPN zwischen Knoten und Gateway durch den FastD ein gewisses Sicherheitsgefühl kommuniziert und aufgebaut. Dieses sollte man nicht leichtfertig für etwas mehr Performance opfern. Ein Angreifer der zwischen meinem Anschluss und dem Supernode und Gateway sitzt, sieht beim FastD VPN halt nur Datenmüll. Aus L2TP kann er jedoch mit weniger Aufwand Dinge abgreifen.

Dieses Argument ist ziemlich gefährlich da man so ein falsches Sicherheitsgefühl vermittelt, lieber sollte man die Betreiber aufklären.
Falls ein Angreifer zwischen dir und dem Supernode sitzt dann bekommt er die selben Daten die er auch im Mesh via spoofing abfangen könnte. Was daran jetzt so viel gefährlicher ist musst du mir erst erklären :wink:
Klar lässt sich damit die Verbindung schaffen das ein gewisser Traffic über deine Freifunk Node lief, aber was dies einem Angreifer (Ich rede hier nicht von Vorratsdatenspeicherung oder ähnlichem) in dem Moment bringen soll ist mir schleierhaft. Zudem die Position der meisten Router auf der Karte ist, dadurch erübrigt sich dies auch.

Davon ab möchte ich dich bitten dieses Thema wo anders weiterzuführen :wink: Hier gehts darum die Version zu testen.

1 „Gefällt mir“

2 Beiträge wurden in ein neues Thema verschoben: Verschlüsselung von Datenverkehr zwischen Node und Backbone

Ein paar Fragen zu der ganzen Geschichte:

  • Ist das L2TP-Package kleiner, gleichgroß oder größer als fastd? (um die Firmwaregröße zu optimieren)
  • Wie sieht es mit der Serverseitigen Load aus? Gibt es da Vorteile? Bzw. Erfahrungen? (im vergleich zu fastd mit null encryption)
  • Bezüglich MTU habe ich irgendwo mitgelesen, wird automatisch ermittelt und die niedrigste genommen?

Hi Sheogorath,

Also das Image was nachher rausfällt ist etwa genau so groß da man noch zusätzlich 3 kernel module braucht.
Der Load auf der Serverseite ist wesentlich geringer da der Server natürlich auch keine Context-Switches mehr benötigt.
Dies trifft auch uaf die Nodes zu, wo Fastd vorher je nach Modell bis zu 15% CPU durchgehend zieht, sind es mit L2TP maximal 1-2%.

Diese Werte sind natürlich immer relativ zur Anzahl der Nodes in der Domäne etc.
Jedoch lässt sich sagen dass das Netz nicht nur mehr Durchsatz hat sondern auch weniger CPU-Resourcen benötigt.
Außerdem lässt sich jeder VPN Link als eigenes Interface konfigurieren, so können wir auf beiden Seiten des Links Splithorizon aktivieren (No_rebroadcast bei Batman) da wir ja nicht mehr nur ein virtuell großes Interface haben worüber wir die Batman OGM’s quasi noch mal „zurück“ schicken müssen damit sie beim Rest der Nodes ankommen.
Dadurch sollten wir das Grundrauschen noch etwas reduzieren können sobald wir einen großteil mit L2TP versorgen.

6 „Gefällt mir“

Gibt’s schon ein HowTo für die serverseitige Konfiguration auf Seiten der Supernodes?

Weitere Frage:
Wie würde sich denn die Performance von IPsec verhalten, wenn man zwingend Verschlüsselung haben möchte?
Sollte ja auch im Kernelspace stattfinden und vll. wird sogar Hardware-Crypto verwendet, falls vorhanden.

1 „Gefällt mir“

Die Server Konfiguration haben wir via Ansible gelöst.
Aber im grunde habe ich mich an die folgende Anleitung gehalten:
https://tunneldigger.readthedocs.org/en/latest/

Dafür nutzen wir folgendes Script für session.Up:

#!/bin/bash
# {{ ansible_managed }}
INTERFACE="$3"

ip link set dev $INTERFACE up mtu {{ tunneldigger.mtu }}
/usr/sbin/batctl if add $INTERFACE
echo "enabled" > /sys/devices/virtual/net/$INTERFACE/batman_adv/no_rebroadcast

Die MTU die wir verwenden ist statisch, dafür haben wir die Path-MTU discovery abgeschaltet die der Tunnelbroker bietet. Leider kommt Batman wohl nicht damit klar wenn sich die MTU der Interfaces ändert wenn diese schon im bat0 Interface sitzen. Zwar gibt es einen session.mtu_changed hook aber leider müssten wir dafür das Interface aus bat0 entfernen und neu hinzufügen. Dann gehen jedes mal alle Pfade über das VPN verloren.

Wir nutzen hier 1312 als MTU: 1280 (Ipv6 Minimum) + 32 (Bat15 Overhead)

Hier das session.down script:

#!/bin/bash
# {{ ansible_managed }}
INTERFACE="$3"

/usr/sbin/batctl if del $INTERFACE

Was IPSec angeht:
Tunneldigger verwendet L2TPv3 Pseudowire welche per definition unmanaged sind. Daher wird IPsec hier wohl nicht nutzbar sein. Für Düsseldorf werden wir aber weiterhin zumindest eine Fastd-Instanz betreiben.

Die Sourcen zu Tunneldigger findest du hier:

2 „Gefällt mir“

Habe die Installation entsprechen einmal druchgearbeitet.
Das Session up / down Script liegt nun bei mir im /srv/tunneldigger/session.up / session.down

Wenn ich die MTU statisch setzen möchte, einfach { tunneldigger.mtu } damit ersetzen oder?
To Last: Wie starte ich das teil überhaupt :smiley:

{ tunneldigger.mtu } ersetzt du einfach gegen die MTU :slight_smile: z.b. 1312

Starten kannst du das Ganze so:

#!/bin/bash
# Ansible managed!

WDIR=/srv/tunneldigger
VIRTUALENV_DIR=/srv/tunneldigger

cd $WDIR
source $VIRTUALENV_DIR/bin/activate

bin/python broker/l2tp_broker.py l2tp_broker.cfg

Irgendwie grade alles böhmische Dörfer :smiley:
Gestartet ist das Ganze, nur SSH gibt nichts mehr aus.
Wir prüfe ich denn ob es noch Fehler gibt?

Im selben Ordner wo du das Script gestartet hast liegt auch eine log datei :wink:

Wie bewertet ihr, dass die Verbindung unauthenticated ist?

1 „Gefällt mir“

Bis auf das Startsript läuft anscheinend alles.
Hast du mal eine broker conf von euch zum vergleichen?

Hi Stefan

hier eine Beispiel Config:

[broker]
; IP address the broker will listen and accept tunnels on
address=89.163.150.94
; Ports where the broker will listen on
port=10050
; Interface with that IP address
interface=eth0
; Maximum number of cached cookies, required for establishing a
; session with the broker
max_cookies=1024
; Maximum number of tunnels that will be allowed by the broker
max_tunnels=100
; Tunnel port base
port_base=15000
; Tunnel id base
tunnel_id_base=100
; Tunnel timeout interval in seconds
tunnel_timeout=60
; Should PMTU discovery be enabled
pmtu_discovery=false
; Namespace (for running multiple brokers); note that you must also
; configure disjunct ports, and tunnel identifiers in order for
; namespacing to work
namespace=duesseldorf

[log]
; Log filename
filename=tunneldigger-broker.log
; Verbosity
verbosity=DEBUG
; Should IP addresses be logged or not
log_ip_addresses=false

[hooks]
; Arguments to the session.{up,pre-down,down} hooks are as follows:
;
;    <tunnel_id> <session_id> <interface> <mtu> <endpoint_ip> <endpoint_port> <local_port>
;
; Arguments to the session.mtu-changed hook are as follows:
;
;    <tunnel_id> <session_id> <interface> <old_mtu> <new_mtu>
;

; Called after the tunnel interface goes up
session.up=/srv/tunneldigger/scripts/bataddif.sh
; Called just before the tunnel interface goes down
session.pre-down=/srv/tunneldigger/scripts/batdelif.sh
; Called after the tunnel interface goes down
session.down=
; Called after the tunnel MTU gets changed because of PMTU discovery
session.mtu-changed=

Ah, danke!
Habe die Fw mal mit euren tuneldigger Paketen gebaut. Habt ihr diese in dem Package die Config angefasst?
Der Tunnel wird wohl nicht aufgebaut.

config broker

    	list address 'x.y.z.w:8942'
  
  
    
    	list address 'x.y.z.w:53'
  
  
    
    	list address 'x.y.z.w:123'
  
  
    
    	option uuid 'abcd'
  
  
    
    	option group 'root'
  
  
    
    	option interface 'l2tp0'
  
  
    
    	option limit_bw_down '1024'
  
  
    
    	option enabled '0'

Die Original Config wird nicht verwendet, bitte schaue in den ersten Beitrag. Alles wird via Site.conf konfiguriert, wenn du nichts einstellst wird die Default-Config verwendet :wink:

    tunneldigger_mesh_vpn = {
        mtu = 1312,
        brokers = {'ddorf1.ffrl.de:10050','ddorf2.ffrl.de:10050'},
    },