VPN Verbindungen aus Freifunk-Hagen scheitern (UDP/MTU-Probleme?)

@R2D2 Ehrlich gesagt, kapiere ich nicht genau, was Du da machst. Wenn ich einen Knoten mit Dortmunder SW flashe, dann ist es doch normalerweise egal wo ich den hinstelle - das bleibt ein Dortmunder Knoten.
Es sei denn, die Netze sind sich so aehnlich, dass es evtl zulässig ist, per uci explizit Hagener VPN server anzugeben und das spielt dann zusammen.
Und das geht üblicherweise nicht mit config page Mitteln.

Wir hatten in hagen nie fastd aktiv.
Auf den supernodes ist auf seit jahren mehr kein fastd es geht also nur firmware mit l2tp.
Es sollte erst mehr in einen Paket Mitschnitt das Problem analysiert werden.
Alles andere ist Wasserglas raten… Und das es in netzwerk xyz geht ist keine lösung…

3 „Gefällt mir“

Das ist richtig. Es war nur ein Test, um die technische Seite hier bei mir zuhause abzuklopfen: Endgeräte, Knotenhardware, mein ISP.

Test hat keine neuen Erkenntnisse gebracht, nur bestätigt: hier ist alles OK.

1 „Gefällt mir“

Ich werde mir genauer anschauen, was da beim Verbindungsaufbau abläuft. Nur schaffe ich das heute nicht mehr. Werde genauer loggen und sniffen.

Danke für Deine Hilfe.

Ich würde mich freuen, wenn die Community in Hagen wieder belebt wird. Ich biete gerne meine Hilfe an und möchte mich engagieren.

Ich bin vom Fach, Systementwicklung und administration ist Großteil meines jobs. Aber mich interessiert bei Freifunk sehr die gesellschaftliche und soziale Seite. Stichworte Dezentralisierung, Anonymisierung, Zensur, Datenschutz, Datenfreizügigkeit.
Deswegen ist mir VPN so wichtig. (Und das verschlüsseln von DNS Anfragen, was über Freifunk ohne Probleme geht).

Ich wohne in Wehrighausen und habe mir die Stadt Hagen und dieses Wohnviertel bewusst ausgesucht. Hier kann man günstig im Altbau wohnen und hat ein multikulturelles Umfeld, lebendig und mit all seinen Vor- und Nachteilen. Die Pelmke ist im Freifunk aktiv. Ein Nachbar von mir ein paar Häuser weiter hat eine Richtstrecke bei Freifunk eingerichtet und versorgt von seinem Wohnzimmer aus eine Kneipe gegenüber. Mit ihm überlege ich meinen Knoten per Richtantenne anzubinden, von einem meiner Knoten geht es den Innenhof rüber zum nächsten Freifunker mit drei Knoten. Das ist doch eine tolle Sache, das ruft doch quasi nach Weiterentwicklung. Dann gibt es hier das engagierte Repaircafe, auch mit Freifunk. Und hier leben viele Mitmenschen mit Wurzeln und Beziehungen in teilweise recht restriktive Länder. Gerade diesen Menschen kann man mit Freifunk sichere Kommunikationswege bieten, mit Aufklärung. Wo ginge das besser als hier in Wehringhausen, mit diesem coolen Kulturzentrum? Das schreit ja schon nach Themen wie Internet-Nachbarschaftshilfe, Oma ans Internet, Workshops, infoabende etc.

Man muss abwarten, wie sich das entwickelt. Aber ich sehe hier super Voraussetzingen etwas auf die Beine zu stellen.
Problem ist für mich nur, wenn VPN auf Endgeräten wie Smartphones und Tablets nicht geht, dann bin ich raus. Mir geht es darum, sichere, dezentrale, unzensierte, anonyme Kommunikationskanäle anzubieten. „Hier ist Umsonst-WLAN“ anzubieten interessiert mich nicht so.
Mal sehen wie es weitergeht.

Grad Wehringhausen bietet sich super an für einen breiten Ausbau. Ich wohne auch nur ein paar hundert Meter weiter und die Knoten hier werden sehr aktiv genutzt. Aber das diskutieren wir vielleicht nicht hier OT.:wink:

Wir als ENer koennen als netzbetreiber (was fuer in doofes wort) nur anbieten kommt zum treffen.

Hallo erstmal.

Eben mit einer VM die aktuelle Hagener Firmware daraufhin gecheckt. Hier funktioniert sowohl OpenVPN wie auch L2TP/IPSec über einen Hagener Router, Gegenseite ist dabei jeweils eine Sophos UTM. Alles ausschließlich unter IPv4.

1 „Gefällt mir“

Wenn Du dich engagieren möchtest ist das sehr wilkommen. Einen Ansprechpartner findest Du im Computer Fan Club Hagen e.V. jeden Mittwoch ab ca. 18:00 und über die Hagener Web-Seite.
Zu Deinem VPN-Problem: Ohne Debugging des Verbindungsaufbaus kann man kaum eine Fehler-Analyse machen. Die Vermutung eines MTU-Problemes liegt nahe und ist nicht unwahrscheinlich.
Ich habe getestet: OpenVPN, IPSEC, L2TP (IPSEC) gegen Linux, Windows u. Sophos UTM. Allerdings mit dynamischer MTU-Aushandlung. Ergebnis: Funzt. (IPv4).

Hallo Andreas.
Danke für Deine Nachricht und Deine Hilfe. Ich schaue mir das genauer an.

Ich bin heute erkrankt und liege mit Übelkeit im Bett, bin platt.

Ich konnte heute Vormittag noch durch Versuche mit meinem Unix Laptop das Problem einkreisen. Morgen geht es mir bestimmt besser, dann schreibe ich darüber im Forum. Heute bin ich zu platt.

Gruß, Marco.

Jetzt wollte ich grad den VPN-Test aus Wehringhausen zu unserem Firmennetz machen, da stelle ich fest: Außer (leider, aber geht grad nicht anders) meinem, sind auch die drei anderen Knoten in meiner unmittelbaren Nachbarschaft mittlerweile von der Karte verschwunden :sleepy:

Ich brauche dringend etwas Zeit für einen Plan, wie ich meinen wieder an den Start bekomme, ohne die halbe Wohnung umzubauen :face_with_raised_eyebrow:

Hallo.
Also, ich hatte die Vermutung, dass es eher an IPV6 liegt, nicht an der MTU size.

-Ich habe dann meinen Knoten HA-BACHSTRASSE01 mit der Hagener firmware geflasht und in der Konfiguration IPV6 ausgeschaltet.
-An meinem laptop habe ich dann in der firewall Konfiguration IPV6 zusätzlich geblockt. Et voilà: VPN geht.

Auf dem laptop habe ich dann das Programm zum Aufbau der VPN Verbindung (openvpn auf OpenBSD) manuell mit logging und mtu-test gestartet. Wird der Qualifizierer mtu-test mitgegeben, testen Programm und server 3 - 4 Minuten verschiedene MTU Größen durch und einigen sich dann auf eine gemeinsame Größe. Hier ein Ausschnitt aus dem log:

Mon Dec 10 16:14:28 2018 Initialization Sequence Completed
Mon Dec 10 16:14:30 2018 NOTE: Beginning empirical MTU test – results should be available in 3 to 4 minutes.
Mon Dec 10 16:17:37 2018 NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1525,1525] remote->local=[1522,1522]

Die beiden haben sich auf eine MTU von 1522 geeinigt.
Starte ich das Programm ohne mtu-test, einigen sich Programm und server auf 1500. Das ist völlig OK so.

Mit deaktiviertem IPV6 auf dem Knoten und dem laptop funktioniert der VPN Aufbau in Hagen nun.

Bei den iOS Geräten geht es immer noch nicht. Man kann in den Einstellungen IPV6 nicht deaktivieren. Und so bekommt das Telefon 2 IPV6 Adressen zugeordnet:

Da ich in der Konfiguration des Knotens IPV6 deaktiviert habe, scheint die IPV6 Kommunikation nicht nach außen zu gehen, aber Endgeräte (iPhones, iPads) und Knoten unterhalten sich über IPV6. Und über diesen IPV6 Kanal zwischen Endgerät und Knoten sind in Hagen keine VPN Verbindungen ins Internet möglich.
Wie gesagt, in Dortmund ist das auch mit IPV6 kein Problem.

An der Hagener firmware speziell für den AR150 kann es nicht liegen, da ich es ja auch bei anderen Hagener Freifunkern probiert habe (TP-Link Archer C5 v1, TP-Link TL-WR841N/ND v11).

Kommt man an den firmwarecode aus Dortmund und Hagen eigentlich ran? Sind die quelloffen? Ich würde in beide gerne mal reinschauen, um zu sehen, wo die Unterschiede sind.

Site Konfiguration liegt hier > ffha/site.conf · v2017.1.x · Freifunk im Ennepe-Ruhr-Kreis e.V. / gluon-configs · GitLab
IPv6 Funktioniert einwandfrei (gerade geprüft).

Also bei „vom Fach“ verstehe ich nicht, wie Du eine 1500 VPN MTU als „Gut“ bezeichnen kannst.
(1500 ist die maximale MTU für ein Fast-Ethernet Interface)
Du baust jetzt also einen VPN-Tunnel (MTU: 1500) durch einen VPN-Tunnel (MTU: 1364) auf, finde den Fehler. (Die MTU sollte abzüglich overhead kleiner sein als die des Tunnels durch die sie geht)
Ich kenne deine verwendete Software nicht, aber vlt. gibt es eine Option nur v4/v6 zu verwenden?

sieht ja irgendwie so aus, als wenn mtu-test am FF Tunnel vorbeigeredet hätte. Dann und nur dann wäre „gut“ irgendwie sinnvoll im SInne eines erwartbaren Ergebnisses…

Das OpenBSD-Programm openvpn hat mit dem server minutenlang die verschiedensten MTU Größen für eine optimale Verbindung getestet. Die beiden haben sich auf 1522 geeinigt. Der Verbindungsaufbau ohne diese spezielle Optimierung verläuft mit 1500. Recht nah dran. Also erstmal OK im Sinne von unverdächtig.

Nein nein. Ich versuche hier mein Netz anderen Leuten zu öffnen und ihnen sichere Dienste anzubieten. Was in Dortmund kein Problem ist. Aber hier in Hagen.

Das mache ich doch die ganze Zeit, versuchen, den Fehler zu finden. Und an der MTU size liegt es nicht, wie meine Versuche ja ergeben haben. Mit 1500 funktioniert es ja.

Das habe ich doch lang beschrieben. Ich kann mit meinem OpenBSD laptop VPN Verbindungen aufbauen, wenn ich IPV6 blocke. Das geht aber mit iOS Geräten nicht, die haben diese Option, IPV6 zu blocken, eben nicht.
Nochmal: es geht hier nicht um mich, ich habe in meinem privaten Netz die Möglichkeit, VPN Verbindungen aufzubauen, stressfrei und völlig automatisch.
Durch einen Fehler, der im Hagener Freifunk liegt, kann ich diese Dienste aber nicht im Hagener Freifunknetz anbieten. Auch wenn es nervt: in Dortmund geht es, auch mit IPV6, völlig problemlos.

Mir wird das langsam etwas mühsam. Ich schaue mir den firmware code von Hagen und Dortmund an und werde nach Unterschieden suchen.

Hagen hat kein ipv6. Nur v4
Ich kenne da jemand der jemand kennt dessen onkel die Server betreibt…

Habe mit netstat während der Tests alle Verbindungen beobachtet, da war nichts weiteres. Das ist ein schlankes OpenBSD laptop, da verbinden im Hintergrund noch ein ntp und ein smtp daemon und sonst war nichts weiters. Wäre sofort aufgefallen.

Vielleicht gibt es da bei der MTU size etwas zu optimieren, aber das interessiert mich gerade nicht, da die Verbindung funktioniert und ich das verifiziert habe, der aufgebaute Tunnel funktioniert.

Viel interessanter finde ich die Frage, warum die iOS Clients in Hagen keine VPN Verbindungen aufbauen können (Verdacht: hat mit IPV6 Kommunikation zwischen Endgerät und Knoten zu tun), in Dortmund aber schon.

Ich bin erstmal raus und schau mir die firmware mal genauer an, vielleicht finde ich was.

Das hört sich doch nach einem Ansatzpunkt an! Ein Unterschied zu Dortmund, eine Spur!

Das hört sich hingegen datenschutzrechtlich nach einer Katastrophe an. Ich nehme das jetzt mal als Witz, um hier nicht noch ein Fass aufzumachen und mich noch unbeliebter zu machen ; - )

1 „Gefällt mir“

So, nach den paar Tipps, die ich hier lesen konnte kann ich folgendes sagen:

jb@bart ~ % ping heise.de -s 1298
PING heise.de(redirector.heise.de (2a02:2e0:3fe:1001:302::)) 1298 data bytes
1306 bytes from redirector.heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=1 ttl=55 time=76.3 ms

--- heise.de ping statistics ---
2 packets transmitted, 1 received, 50% packet loss, time 2ms
rtt min/avg/max/mdev = 76.321/76.321/76.321/0.000 ms
jb@bart ~ % ping heise.de -s 1299
PING heise.de(redirector.heise.de (2a02:2e0:3fe:1001:302::)) 1299 data bytes

--- heise.de ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 54ms

Scheint also wohl doch ein Problem mit IP zu geben. Ich hab das vor ein paar Tagen schon mit legacy IP probiert, da hatte ich keine Probleme. Der DHCP Server meint, der Client solle doch bitte eine MTU von 1306 einstellen. Da kommen dann ein paar IP Header dazu und schon ist bei 1299 Schluss.

HTH
julian

Die katze vom onkel sagt hagen hat kein ipv6… Das kann sein das zufällig darum kein ping via ipv6 geht :slight_smile: