VPN-tunnel gets bypassed on meshing nodes

[SvenRoederer]

This was found by the Spandau-team and send via EMail by @bobster-galore

1. 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.

2. Setup Überblick

   -------------------
   Heimnetz + DSL
   (beliebiger Switch)
   -------------------
   !
   !
   !
   ! [Ethernet]
   !
   !
   !
   -------------------
   (blaue Buchse "WAN")
   FFMASTER Router
   -------------------
   o
   o
   o
   o [Wifi AdHoc intern-ch13.freifunk.net]
   o
   o
   o
   -------------------
   FFSLAVE Router
   -------------------
   o
   o
   o
   o [Wifi AP slave.freifunk.net]
   o
   o
   o
   -------------------
   LAPTOP
   -------------------

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. Detailliertes Problem:

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. Warum das evtl. nicht auff?llt:

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.

[SvenRoederer]

Es scheint, das hier das Routing nicht stimmt

root@SAm0815-test-routing:/# ip rule 0: from all lookup 128 1: from all lookup local 1000: from all lookup olsr 2000: from all lookup localnets 19999: from all iif tunl0 lookup olsr-tunnel 19999: from all iif br-dhcp lookup olsr-tunnel 19999: from all iif ffvpn lookup olsr-tunnel 19999: from all iif wlan0-adhoc-2 lookup olsr-tunnel 20000: from all iif tunl0 lookup olsr-default 20000: from all iif br-dhcp lookup olsr-default 20000: from all iif ffvpn lookup olsr-default 20000: from all iif wlan0-adhoc-2 lookup olsr-default 20001: from all iif tunl0 unreachable 20001: from all iif br-dhcp unreachable 20001: from all iif ffvpn unreachable 20001: from all iif wlan0-adhoc-2 unreachable 32766: from all lookup main 32767: from all lookup default 100000: from all lookup olsr-tunnel 100010: from all lookup olsr-default

routing-tabelle 128 uns local sehen normal aus

root@SAm0815-test-routing:/# ip route show table 128 root@SAm0815-test-routing:/# ip route show table local local 10.31.21.103 dev wlan0-adhoc-2 proto kernel scope host src 10.31.21.103 local 10.31.21.103 dev tnl_0a1f1747 proto kernel scope host src 10.31.21.103 broadcast 10.230.195.80 dev br-dhcp proto kernel scope link src 10.230.195.81 local 10.230.195.81 dev br-dhcp proto kernel scope host src 10.230.195.81 broadcast 10.230.195.95 dev br-dhcp proto kernel scope link src 10.230.195.81 broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 broadcast 172.31.240.0 dev ffvpn proto kernel scope link src 172.31.242.24 local 172.31.242.24 dev ffvpn proto kernel scope host src 172.31.242.24 broadcast 172.31.255.255 dev ffvpn proto kernel scope link src 172.31.242.24 broadcast 192.168.8.0 dev eth1 proto kernel scope link src 192.168.8.126 local 192.168.8.126 dev eth1 proto kernel scope host src 192.168.8.126 broadcast 192.168.8.255 dev eth1 proto kernel scope link src 192.168.8.126

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

root@SAm0815-test-routing:/# ip route show table olsr 10.31.14.174 via 10.230.140.32 dev wlan0-adhoc-2 metric 2 onlink 10.31.14.175 via 10.230.140.32 dev wlan0-adhoc-2 metric 2 onlink 10.31.21.103 dev wlan0-adhoc-2 scope link 10.31.21.125 via 10.31.21.125 dev wlan0-adhoc-2 metric 2 onlink 10.31.23.71 via 10.230.140.32 dev wlan0-adhoc-2 metric 2 onlink 10.36.39.0/27 via 10.230.140.32 dev wlan0-adhoc-2 metric 2 onlink 10.230.104.160/27 via 10.230.140.32 dev wlan0-adhoc-2 metric 2 onlink 10.230.140.32 via 10.230.140.32 dev wlan0-adhoc-2 metric 2 onlink 10.230.140.35 via 10.230.140.32 dev wlan0-adhoc-2 metric 2 onlink 10.230.146.183 via 10.230.140.32 dev wlan0-adhoc-2 metric 2 onlink 10.230.195.80/28 dev br-dhcp scope link 10.230.197.208/28 via 10.31.21.125 dev wlan0-adhoc-2 metric 2 onlink 172.31.240.0/20 dev ffvpn scope link 192.168.8.0/24 dev eth1 scope link root@SAm0815-test-routing:/# ip route show table localnets 10.31.21.103 dev wlan0-adhoc-2 scope link 10.230.195.80/28 dev br-dhcp scope link 172.31.240.0/20 dev ffvpn scope link 192.168.8.0/24 dev eth1 scope link

Routing prio 19999: Der Weg für alle Clients auf Freifunk-interfaces zum VPN oder via Smartgateway

root@SAm0815-test-routing:/# ip route show table olsr-tunnel default via 172.31.240.1 dev ffvpn default dev tnl_0a1f1747 metric 2 172.31.240.0/20 dev ffvpn scope link src 172.31.242.24

Ist eine leere Tabelle (warum landen die OLSR-routen nicht hier?)

root@SAm0815-test-routing:/# ip route show table olsr-default

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

root@SAm0815-test-routing:/# ip route show table main default via 192.168.8.1 dev eth1 proto static src 192.168.8.126 10.230.195.80/28 dev br-dhcp proto kernel scope link src 10.230.195.81 172.31.240.0/20 dev ffvpn proto kernel scope link src 172.31.242.24 192.168.8.0/24 dev eth1 proto kernel scope link src 192.168.8.126 192.168.8.1 dev eth1 proto static scope link src 192.168.8.126 root@SAm0815-test-routing:/# ip route show table default

Wenn man jetzt die Uplink-lan route nicht in den olsr und localnets tabellen hat, sollten erst die unreachable Tabellen greifen für Freifunk-traffic und dann ggf. die main-kernel-tabelle. Somit werden die FF-clients vor erreichen der uplink-lan-route schon ins "Nirvana" geschickt

[booo]

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.

[SvenRoederer]

Durch sauberes Routing ist dieses problem gelöst. Dass die Firewall hier "kaputt ist" / "anders funktioniert" sollte in einem neuen Ticket behandelt werden.

[sarumpaet]

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.

[SvenRoederer]

+1 for @sarumpaet - this isue is fixed and the code is easy to review. I don't like the idea to change even more code than we do already this close to a release (update OpenWrt-base, OpenWrt-packages and LuCI-feed). Let's review this policy-routing for the next release and find a clean way.

[booo]

I prepared a fix for the routing stuff which I find superior to the already merged fix here:

https://github.com/freifunk-berlin/firmware/commit/44ec2879ef8e06938191fbe2bd8d4b2c2ab685bf

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.

[sarumpaet]

@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.

[bobster-galore]

And do we know more about this? Will we keep it as is for Hedy-RC?

[SvenRoederer]

@booo please see comment https://github.com/freifunk-berlin/firmware/commit/44ec2879ef8e06938191fbe2bd8d4b2c2ab685bf#commitcomment-24342536 regarding your "I prepared a fix for the routing stuff which I find superior"

[bobster-galore]

Since there is a fix and no other ready solution, we should remove this from Hedy-1.0.0 milestone. and should release asap.

[SvenRoederer]

+1 for not having this as release-stopper

[bobster-galore]

I would like to close this issue cause I think it's solved. What do u think?

[SvenRoederer]

As the initial issue is solved and there is no activity regarding https://github.com/freifunk-berlin/firmware/issues/402#issuecomment-259816511 since more than 2 years, I close this.