VPN-tunnel gets bypassed on meshing nodes #402
Comments
|
Es scheint, das hier das Routing nicht stimmt
routing-tabelle 128 uns local sehen normal aus
Am Ende der olsr und localnets-tabelle steht jeweils eine Route ins uplink-LAN. Alle Clients kommen über diese Regel und finden einen Weg ins uplink-lan
Routing prio 19999: Der Weg für alle Clients auf Freifunk-interfaces zum VPN oder via Smartgateway
Ist eine leere Tabelle (warum landen die OLSR-routen nicht hier?)
die normalen Kernel-routen, was hier ankommt ist nicht via prio 20001 nach unreachable gegangen. ist also kein traffic von Freifunk-interfaces. Hierüber jann der Router mit der Aussenwelt reden
Wenn man jetzt die Uplink-lan route nicht in den |
|
Die Firewall sollte trotz "falscher" Route ein Routing in das Netz verhindern! Bevor nicht geklärt ist warum die Firewall nicht greift und eine Lösung für das Problem gefunden wurde, sollte das Problem nicht als gelöst betrachtet werden. |
|
Durch sauberes Routing ist dieses problem gelöst. |
|
Das close war nur GitHub automatisch. Ich würde sagen, das ist so erstmal für einen RC und vermutlich für die 0.2.0 gut genug (die ist schließlich damit auch ziemlich dringend), einen richtigen Fix und auch Doku usw. können wir dann noch machen. Die Firewall würde ich auch separat behandeln. |
|
+1 for @sarumpaet - this isue is fixed and the code is easy to review. |
|
I prepared a fix for the routing stuff which I find superior to the already merged fix here: We should if at all only add routes from interfaces which belong to freifunk zones to the localnets and olsr table. The hotplug script already contains the logic for this. We only have to move the code for localnets into the right if-block. I do think we have the time to change this properly before the release and we should do so. I would like to investigate the firewall problem before we push a release too. And if possible fix this somehow serious security problem before we publish 0.2.0. |
|
@booo I agree that the Freifunk zones approach is cleaner (that's why I proposed that by mail to you a few days ago). In master a hotfix is good though as otherwise we'd have absolutely no images we can recommend installing. I don't know if we should postpone 0.2.0 as I think both policyrouting and the firewall need a closer look and documentation and testing which will take a while (and I don't have any time for a few days now). I don't want policyrouting patched more without documenting it fully at the same time, and possibly it'd be a good idea to fork it instead of just patching it. As a side note, this whole release model is not great, we need (optional) auto-upgrades. |
|
And do we know more about this? Will we keep it as is for Hedy-RC? |
|
@booo please see comment 44ec287#commitcomment-24342536 regarding your "I prepared a fix for the routing stuff which I find superior" |
|
Since there is a fix and no other ready solution, we should remove this from Hedy-1.0.0 milestone. and should release asap. |
|
+1 for not having this as release-stopper |
fixes #581 f18bdea Merge pull request #404 from mwarning/nodogsplash 02966f8 nodogsplash: fix minor package issues 938e4db Merge pull request #402 from crza/fix-ndppd e737f4f Merge pull request #400 from cotequeiroz/bmx7_list.h dfe8097 bmx7: Avoid namespace collision with libubox. 85d01f8 Merge pull request #401 from mwarning/nodogsplash2 6f82d51 nodogsplash2: remove package 1a27c9a nodogsplash: update to release 3.0.0 9333cdf ndppd: fix compile error with musl 76773ec Merge pull request #399 from mwarning/nodogsplash2_fix c7d0e1c nodogsplash2: remove reference to dead code e46736e Merge pull request #395 from mwarning/nodogsplash2 fa70e4c nodogsplash2: init script cleanup and refactoring
|
I would like to close this issue cause I think it's solved. What do u think? |
|
As the initial issue is solved and there is no activity regarding #402 (comment) since more than 2 years, I close this. |
This was found by the Spandau-team and send via EMail by @bobster-galore
Problem:
Wenn zwei Freifunk-Router per Mesh miteinander verbunden sind, dann besteht für Clients, die sich am sekundären Router anmelden, direkter Zugriff ins Heimnetz.
Das ist insbesondere Problematisch, weil der sekundäre Router ggf. gar nicht mir gehört, sondern z.B. einem Angreifer.
Daher ist die Konfiguration des sekundären Routers nicht wirklich relevant, sondern nur wg. Vollständigkeit angegeben.
Setup Überblick
2.1. Setup FFMASTER:
2.1.1. WR1043nd, CPE510 mit Kathleen-0.2.0-beta; WR841 mit Kathleen-0.2.0-alpha
2.1.2. Nach "Reset to defaults" nur Standardkonfig im Wizard:
Knoten benennen, Internet teilen, VPN-Key eingeben, Bandbreite eingeben
Keine weiteren Konfigurationsschritte
2.1.3. Netzwerkstecker in blauer Buchse (WAN), verbunden über externen Switch an Heimnetz
2.1.4. SSID AP: master.freifunk.net (wird nicht benutzt)
2.1.5. SSID AdHoc: intern-ch13.freifunk.net
2.2. Setup FFSLAVE:
2.2.1. WR841 mit Kathlen-0.1.2
2.2.2. Nach "Reset to defaults" nur Standardkonfig im Wizard:
Knoten benennen, Internet teilen, VPN-Key eingeben, Bandbreite eingeben
Keine weiteren Konfigurationsschritte
2.2.3. Kein Ethernet Anschluss, weder blaues WAN noch gelbes WASAUCHIMMER, nur Mesh via Wifi zu FFMASTER
2.2.4. SSID AP: slave.freifunk.net
2.2.5. SSID AdHoc: intern-ch13.freifunk.net
2.3. Setup LAPTOP:
2.3.1. Verbunden über Wifi mit FFSLAVE an slave.freifunk.net
3.1. Vom LAPTOP aus besteht nun direkter Zugriff auf das Heimnetz.
3.2. Es kann z.B. der DSL Router (192.168.2.1) per Ping oder HTTP (Anmelden am Router möglich) angesprochen werden, aber auch jedes andere Gerät im Heimnetz.
3.3. Unklar, weil beides beobachtet: (Der Zugang zum Internet geht ebenso nicht über VPN03, sondern direkt über DSL.)
4.1. Pakete von Clients an FFMASTER AP werden korrekt ?ber das VPN03 geroutet (also nicht ins Heimnetz)
4.2. Pakete m?ssen vom LAPTOP an FFSLAVE und dann via OLSR ?ber FFMASTER kommen
4.3. FFSLAVE darf nicht ?ber WAN-Buchse angeschlossen sein, sonst hat man 4.1.
4.4. Unklar, weil beides beobachtet: (LAPTOP darf nicht per SSH eine Login-Shell auf FFSLAVE ?ffnen: Von dieser Shell aus ist das Heimnetz nicht erreichbar)
4.5. Es scheint noch weitere, nicht genau bekannte Einfl?sse zu geben, z.T. tritt dieses Routing ins Heimnetz nicht auf:
4.5.1. Offenbar muss das Heimnetz eine echte Verbindung ins Internet haben, bei Tests mit einer isolierten FritzBox, die nur DHCP bereitstellt, aber keinen Internet-Zugang hat, war ein Zugriff auf das Heimnetz nicht m?glich.
4.5.2. OLSR braucht z.T. sehr lange f?r die Initialisierung, der Zugriff auf das Heimnetz ist dann erst sp?ter m?glich.
The text was updated successfully, but these errors were encountered: