[Frage] Layer 2 Traffic übers VPN leiten?

[justin123]

Hallo,

ich würde gerne meine Fritzbox 7580 als VPN-Server einrichten, um Geräte in meinem Heimnetz mit einem anderen Netzwerk zu verbinden.

Bisher habe ich den integrierten IPSec-Server (IKEv1) von AVM genutzt, der auch gut funktioniert. Allerdings gibt es ein Problem: Er kann keinen Layer 2-Verkehr über das VPN leiten.

Ich hatte überlegt, ein GRETAP-Interface zu erstellen und es in der ar7.cfg der Fritzbox der LAN-Bridge hinzuzufügen, aber leider unterstützt die Fritzbox keine GRETAP-Interfaces.

IPsec und WireGuard scheiden daher aus, da beide kein Layer-2-Traffic nativ unterstützen. Beide benötigen ein zusätzliches Interface, das dann gebridged werden muss.

Die einzige Möglichkeit, die ich sehe, wäre OpenVPN, da es Layer-2 nativ unterstützt. Ich müsste lediglich das tun0-Interface zur LAN-Bridge hinzufügen, was kein großer Aufwand wäre.

Was mich allerdings zögern lässt, sind meine eher schlechten Erfahrungen mit OpenVPN. Aus meiner Erfahrung kommt es weder bei der Geschwindigkeit (was nicht so kritisch ist, da ich bei meiner aktuellen IPSec-Verbindung aktuell eine maximal Datenrate von 0,10MB/s benutzte (es geht nstürlich mehr)) noch bei der Latenz an IPSec oder WireGuard heran.

Übersehe ich hier etwas, oder ist OpenVPN tatsächlich meine einzige Option?

 

[jde07]

Hi

Layer-2 Osi? TCP?
If TCP you can get into network by editing VPN.cfg
Cat /var/flash/vpn.cfg > /var/tmp/VPN.cfg

Vi /var/tmp/VPN.cfg

You can find p2p mask

}
phase2remoteid {
ipaddr = 192.168.178.203;
}
phase2ss = "LT8h/esp-all-all/ah-none/comp-all/pfs";
accesslist =
"permit ip 0.0.0.0 0.0.0.0 192.168.178.203 255.255.255.255";
app_

And open whole network

192.168.178.203 255.255.255.0"

Or all networks you have

192.168.178.203 0.0.0.0"

Than save changes
Cat /tmp/flash/vpn.cfg > /var/flash/VPN.cfg

Reboot

You can do those changes in imported cfg file before uploading to Fritz/freetz VPN

Be careful during changes faults causing factory settings

Kind regards

 

[PeterPawn]

Autsch - abgesehen davon, daß TCP Layer4 ist (IP als Obermenge von TCP, UDP, ICMP und noch einigen anderen Protokollen aus höheren Schichten liegt selbst auf Layer3), stimmen auch einige Angaben in #2, wie IP-Adressen geändert werden sollen, nicht wirklich.

Abgesehen davon könnte man einzelne IPSec-Verbindungen auch aus passenden "Schnipseln" importieren (und dabei bestehende Verbindungen gleichen Namens ersetzen), anstatt die vpn.cfg insgesamt von Hand zu editieren. Das wäre auch deutlich weniger fehlerträchtig, denn eine falsche Datei wird dann einfach abgelehnt (aka "nicht importiert"), während eine ungültige Änderung tatsächlich (wie in #2 auch geschrieben) das komplette VPN aushebeln kann (und das dann auch inkl. Wireguard®).

Zum Tunneln von Layer2-Traffic bietet sich tatsächlich am ehesten OpenVPN an, solange man nicht auf externe Dienstleister, die dann "networking as a service" anbieten (z. B. ZeroTier), angewiesen sein will oder man greift auf die "offizielle" Möglichkeit L2TPv3 (https://datatracker.ietf.org/doc/html/rfc3931) zurück, was AVM beim FRITZ!OS auch selbst verwendet, um Traffic von anderen Accesspoints so durch das LAN zu transportieren, daß im Gastnetz aktive Clients keinen Zugriff auf LAN-Ressourcen erlangen können.

Damit ist dieses Protokoll i.d.R. im Kernel enthalten oder als LKM verfügbar - was man da jetzt genau konfigurieren müßte, um das auch für die Verbindung zweier, örtlich getrennter Netze verwenden zu können, weiß ich auch nicht (zumindest nicht genau genug, um das sicher behaupten zu können). Vor allem ist dieser L2-Traffic dabei per se erst mal unverschlüsselt und man müßte zusätzliche Vorkehrungen treffen (L2TP-IPSec). Nachdem die IPSec-Implementierung von AVM per se schon ziemlich "wierd" ist, würde ich sogar bezweifeln, daß man damit die Verschlüsselung hinbekommt, auch wenn die mittlerweile ganz normal über XFRM-Rules für den Kernel arbeitet (was Voraussetzung für die Nutzung der Hardware-Unterstützung einiger Chipsets war).

Aber bei solchen Konstrukten gibt es eigentlich immer weitere Probleme (siehe auch die Ausführungen im RFC), denn da zu den Daten der zu tunnelnden Pakete ja jeweils noch der Overhead durch das Tunnelprotokoll hinzukommt, muß/müßte man bereits auf den beteiligten Netzwerk-Clients dafür sorgen, daß diese ihrerseits die Pakete nur so groß werden lassen, daß man da die Daten des Tunnelprotokolls noch in die max. mögliche Datenmenge eines Pakets hineinquetschen kann und dann hängt diese "MTU size" zusätzlich noch von weiteren Faktoren ab (IPv6-Header sind deutlich größer als IPv4-Header, PPP(oE) braucht auch zusätzlichen Platz, wenn der Provider es nutzt, etc.), was eine allgemeingültige Konfiguration zusätzlich erschwert.

Bei allem, wo die ursprünglichen Pakete erst noch gesplittet werden müssen, damit sie übertragen werden können, kommt eben ganz automatisch eine geringere Geschwindigkeit und eine höhere Latenz heraus, denn die ZWEI Pakete, in denen das ursprüngliche Paket dann übertragen werden muß, müssen auf der Gegenseite ja auch erst wieder komplett empfangen und assembliert werden, bevor sie an das eigentliche Ziel gesendet werden können.

Eine L2-Bridge über Protokolle aus höheren Schichten MUSS also weniger effizient sein, denn wenn man zum Vermeiden der Notwendigkeit des Segmentierens von Paketen diese per se kleiner macht, verschenkt man ja ebenfalls Performance ggü. dem möglichen Maximum.

Alles in allem bleibt Dir wohl tatsächlich nur OpenVPN, egal wie gut oder schlecht Deine Erfahrungen damit sein mögen - mit einem TAP-Device habe ich selbst bisher noch keine schlechten Erfahrungen gemacht (obwohl ich auch OpenVPN längere Zeit damit genutzt habe) und am Ende geht es ja eher darum, welche Software dieses TAP-Device bedient. Ein sinnvoll konfiguriertes OpenVPN KANN auch ziemlich performant sein, wobei es üblicherweise ja auf OpenSSL für die kryptographischen Funktionen zurückgreift. Hat man also ein OpenSSL mit Hardware-Unterstützung, ist auch das ggf. schon performanter, wobei das natürlich als Userland-Implementierung einer reinen kernel-basierten Lösung auch nicht das Wasser reichen kann, denn Kontextwechsel zwischen Kernel und Userland sind teuer und - anders als bei AES-NI als Befehlssatzerweiterung - die Hardware-Beschleunigung ist für Userland-Prozesse nur selten verfügbar.