Freifunk Routing vs Netfilter / IpTables

Hallo zusammen,

zunächst einmal vielen Dank für die Arbeit am Projekt und die Mühe beim Erstellen der Flash-Images!
Komplikationsfrei habe ich einen TP-Link WDR4300 mit einem entsprechenden Image flashen können. Dieser läuft auch an einer Fritzbox als Boarder Device einwandfrei … mit einer kleinen Einschränkung.
Kurz zur Erklärung:
Auf der Box läuft ein Linux-netfilter-Paket, welches den Zugriff auf die Box selbst (INPUT) aus jeglichen Richtungen (lan,dsl) auf ein absolutes Minimum beschränkt. Wenn ich nun den Freifunk-Router ans LAN der Box anschließe, ergeben sich folgende LOGS:

Apr 2 19:12:33 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=..16.124 DST=192.168.*.1 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=6699 DF PROTO=TCP SPT=41279 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0

Offensichtlich erzeugt der Zugriff auf 's Freifunk-Netz Netzverkehr vom DSL-Device (mit der öffentlichen IP) auf das LAN-Device der Box selbst (192.168.*.1). Nur ungern würde ich eine Regel hinzufügen, die den gesamten Traffic vom dsl-Device auf die Box selbst gestattet …

Das bedeutet, daß mit den geladenen netfilter-Regeln aktuell kein Traffic von und zum Freifunk-Netz zustande. Für eine Idee diesbezüglich wäre ich sehr dankbar !
Beste Grüße,

JD.

Du mußt den Zugriff auf DNS erlauben, da der FF-Router sonst keine Verbindung zu den Supernodes aufbauen kann.

Port: 53/UDP

Hallo Trickreicher,

danke für die Antwort - obwohl sie mich etwas irritiert: UDP Port 53 wird für alle Clients im LAN der Box im FORWARD erlaubt, ebenso wie im INPUT. Daran dürfte es eigentlich nicht liegen … zumal in den Logs explizit Port 80 TCP auftaucht …
Frohe Ostern,

JD.

Nur zur Sicherheit.
Du hast am FF-Router den blauen Port benutzt?

Die Gelben sind NUR für Clients innerhalb des FF-Netz.

:wink:

Ja, durchaus.
Aktuell sehen die Logs so aus:

Apr  3 21:06:59 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=lan OUT= MAC=01:00:5*00:00:01:*:f4:*:77:*:2a:08:00:*:c0:00:20:00:00:*:00:01:02:04:*:00:00:00:00:e0:00:00:01:*:04:00:00:11:64:ee:9b:00:00:00:00:80:10:24:90:14:0a:00:00 SRC=0.0.0.0 DST=224.0.0.1 
Apr  3 21:07:31 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=lan OUT= MAC=01:00:*:00:00:01:*:f4:*:77:*:2a:08:00:*:c0:00:20:00:00:*:00:01:02:04:*:00:00:00:00:e0:00:00:01:*:04:00:00:11:64:ee:9b:00:00:00:00:80:10:24:90:d3:8f:00:00 SRC=0.0.0.0 DST=224.0.0.1 

Ich brauche etwas Zeit, um die TCP-Header in Source, Dest, Port, Proto usw. zu dekodieren.
Immer noch gibt es im WLAN-Netz des WDR4300-FF-Routers keinen Internetzugang. Wenn ich die Firewall auf der FritzBox ausschalte, schon.
Grüße,

JD.

Neben DNS benötigst du noch Port 10000/UDP für den fastd-Tunnel.

Mea culpa, ich hatte eine Null übersehen.
Mit UDP 10000 und UDP 10040 läuft es jetzt.
Danke !

Frohe Ostern,

JD.

Dachte eigentlich, daß die alle auf 10000 laufen, aber die IPs gehören zu den Supernodes, daher würde ich dann 10040/UDP aufmachen

ich verstehe nach wie vor nicht, was da passiert ist.

Verstehe ich richtig „Box“ ist hier der NAT-Router „vor“ dem FF-Router?

Und der FF-Router (Gluon?) versucht beim Start (oder ständig?) auf das lokale WAN-Gateway auf Port 80 zuzugreifen?
Was würde der da denn zu holen versuchen? Da würde mich mal die URL interessieren.

FF-Wermelskirchen-FW?

Nein, das glaube ich nicht.

Paket kommt von außen: IN=dsl. Genaueres kann man nicht sagen, da ja die IP-Adressen manuell verstümmelt wurden. Warum eigentlich? Es fällt niemanden etwas ab wenn die korrekten Adressen angegeben werden.

1 Like

Hallo zusammen,

kurz zu Euren Fragen:
Der FF-Router hing am LAN eines Routers (Fritzbox), der die I-Netverbindung herstellt.
Verwendet wird die Gluon-FW.
MIttlerweile hängt der FF-Router in einem speziellen Subnetz der Fritzbox, dem Gastzugang (192.168.179.0/24).
Entscheidend für den I-Netzugriff der Geräte im Freifunk-WLAN waren, wie der Trickreiche schon korrekt dargestellt hat, Zugriffsmöglichkeiten in der FORWARD-Chain für dieses Subnetz auf Port 10040 UDP. Damit lief es … gestern. Heute ergab sich, bei über Nacht abgeschaltetem FF-Router, wieder Folgendes:

Apr  4 09:38:08 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=guest OUT= MAC=24:65:11:*:ce:*:a2:f4:c1:*:fc:*:08:00:45:00:00:4f:a8:13:40:00:40:11:ab:21:c0:a8:b3:16:c0:a8:b3:01:5a:0a:00:35:00:3b:38:91:9b:61:01:00:00:01:00:00:00:00:00:00 SRC=192.168.179.22 DST=1

(Nun auch mit vollständigem TCP-Header … :wink: )
Erst nachdem ich eine Regel

iptables -A INPUT -i guest -j ACCEPT

eingefügt habe, läuft der I-Net-Zugriff im FF-WLAN. Um ehrlich zu sein, gefällt mir diese Regel nicht so gut … bedeutet sie doch, daß jeder, der physischen Zugriff auf den FF-Router hat, per LAN-Zugang an diesem auch Zugang zur Firtbox hat …
Das widerspricht der Idee des Gastzugangs, also der kompletten Trennung zwischen LAN des (Haupt-)Routers und des Gast-(W)LANs komplett.
Grüße,

JD.

Edit:
Offensichtlich möchten auch die Supernodes Zugriff auf den ersten Router:

Apr  4 11:00:47 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=217.189.184.146 DST=192.168.178.1 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=21457 DF PROTO=TCP SPT=50692 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0 

Also ich kann hier gar nichts erkennen, kein Protokoll, kein Destination. So wirst Du keine sinnvollen Antworten erhalten können.

217.189.184.146 ist eine Adresse von O2 Telefonica. Der reverse DNS lässt vermuten, dass es eine dynamich vergebene ist:

$ host 217.189.184.146
146.184.189.217.in-addr.arpa domain name pointer xd9bdb892.dyn.telefonica.de.

Ein Supernode ist das garantiert nicht.

Bist Du sicher, die relevanten Dienste auf dem FF-Router neu gestartet zu haben nach Änderung auf seiner Versorgung mit WAN (am einfachsten: Reboot)?

Da ich echt keine Lust auf Rätselraten habe, werde ich mich jetzt hier ausklinken bis zu dem Zeitpunkt, wo hier Ross und Reiter genannt werden, meine Kristallkugel ist nämlich gerade in der Werkstatt.

Ja, ich bin sicher.
Konkret habe ich den Router mehrfach vom Strom getrennt. Ohne eine Regel

iptables -A INPUT -i guest -j ACCEPT

kann ich im FF-Netz keinen Kontakt zum I-Net herstellen.

Bei der Aufschlüsselung von

Apr  4 09:38:08 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=guest OUT= MAC=24:65:11:6f:ce:67:a2:f4:c1:77:fc:2a:08:00:45:00:00:4f:a8:13:40:00:40:11:ab:21:c0:a8:b3:16:c0:a8:b3:01:5a:0a:00:35:00:3b:38:91:9b:61:01:00:00:01:00:00:00:00:00:00 SRC=192.168.179.22 DST=1

dachte ich an Folgendes:

24:65:11:6f:ce:67 = Empfänger-MAC
a2:f4:c1:77:fc:2a = Absender-MAC
08:00 = Paket-Typ (IP)
45:00:00:4f:a8:13:40:00:40:11:ab:21 = IPv4-Header, 11 = Protokoll (Hex11 = UDP)
c0:a8:b3:16 = Source-IP (192.168.179.22)
c0:a8:b3:01 = Dest-IP (192.168.179.1) Boarder-Device FritzBox
5a:0a = Port Absender (9000)
00:35 = Port Ziel (53)
00:3b:38:91 = Länge 59, Checksum
9b:61:01:00:00:01:00:00:00:00:00:00 = UDP-Data

Offensichtlich handelt es sich um eine DNS-Anfrage eines Clients im FF-Netz. Diese wird scheinbar auf den DNS des Boarder-Devices umgelenkt (192.168.179.1). Vermutlich in meinem speziellen Fall daher, daß der FF-Router im Gast-LAN des Boarder-Devices hängt. Wie ich oben schrieb, finde ich das eigentlich nicht so schön - warum kann der FF-Router DNS-Anfragen seiner Clients nicht im FF-Netz beantworten und muß hierzu Zugriff auf den Haupt-Router haben ?
Grüße,

JD.

Edit: Beim Nachzählen fiel mir gerade auf, daß mit der Länge des Frames etwas nicht stimmt: Es sollten (s.o.) 59 Bytes sein, sind aber nur 54 …

Der Freifunkrouter beantwortet überhaupt gar keine DNS Anfragen aus dem Freifunk Netz. Die Freifunk Clients fragen andere Resolver, nicht den kleinen Plaste Router. Der Router selbst muß natürlich DNS Requests absetzten können (NTP, FASTD-Peers,…). Um dies zu tun nutzt er den Resolver, den er vom lokalen Router per DHCP zugewiesen bekommen hat.

Nur damit ich es richtig verstehe:

Mit DNS-Anfrage meinte ich eine Anfrage vom FF-Node (192.168.179.22:9000) an den "Haupt-"Router (192.168.179.1:53). Ist mein FF-Node ein in Deinem Terminus „Freifunk-Client“ ?
Was ich nicht meinte waren Clients im WLAN des FF-Routers.
Also nochmal: Da das FF-Netz (also das Netz aus allen FF-Knoten) doch Gateways ins I-Net hat, könnten doch diese DNS-Anfragen in eben dieses laufen, also nicht vorher über eine (DNS-)Anfrage an den eigentlichen Hauptrouter ?

FF-Node = FF-Router. Diese DNS Requests sind, wir ich schrieb, erforderlich.

Ich meinte FF-Client = Host, welcher normalerweise im WLAN des FF-Routers ist. Von diesen wirst Du keine DNS Requests sehen.

FF-Knoten = FF-Client. Von diesen siehts Du doch auch keine Requests.

Könntest Du evtl. noch einmal die (topologischen) Unterschiede zwischen FF-Node und FF-Client erläutern ?
Und um auf meine Frage zurückzukommen: Es ist also erforderlich, daß ich Zugriff vom guest-Device des Hauptrouters auf eben diesen selber zulasse, z.B. für solche DNS-Requests ?
Könnte ich diesen Zugriff zumindest auf einige existentielle Ports wie z.B. UDP 53 beschränken ?

FF-Node = FF-Router: Hat Layer2 Verbindung zum heimischen Router. DNS Requests von diesem Device müssen zugelassen werden. Sonst geht es einfach nicht.

FF-Client: Client in FF-WLAN. Hat keine Layer2-Verbindung zum Router. Dieser „sieht“ auch keinerlei Traffic von diesem Device.

Für DNS sind absolut zwingend Port 53 für UDP und TCP zuzulassen. Der Client kann jederzeit von UDP auf TCP umschalten. Alle anderen im Internet kursierenden Anleitungen sind falsch.

Okay, ich war deswegen ein wenig verwirrt:

Dann werde ich den Zugriff zunächst auf TCP/UDP:53 beschränken, die Logs beobachten und ggfs. die Regel anpassen.