Statusseite wird durch br-wan geroutet und von der Firewall blockiert


#1

Im Heimnetz mit OpenWrt-Router habe ich das Problem, dass die Statusseite des daran angeschlossenen Freifunkrouters aus dem Heimnetz heraus nicht geöffnet werden kann. Der Weg hin zum Freifunkrouter geht den “normalen” Weg, d. h. aus dem Heimnetz über den Backbone zum Freifunk-Router. Die Rückroute vom Freifunk-Router wird dann entsprechend der Routing-Tabelle über das br-wan-Interface geleitet, wodurch die Pakete, so vermute ich, in der Firewall hängen bleiben.

Ist die IPv6-Konfiguration auf dem OpenWrt-Router fehlerhaft? Vorher hatte ich statt des OpenWrt-Routers eine Fritzbox und später einen DIR-868L betrieben, ohne das es zu diesem Problem kam.
Details sind hier schon beschrieben:


#2

ja ist im default aus

https://wiki.freifunk.in-kiel.de/wiki/Erweiterte_Konfiguration#Statusseite_auch_auf_dem_WAN_Interface


#3

Dafür schon einmal Danke! Gäbe es denn auch die Möglichkeit, die Statusseite zwangsweise über br-client zu leiten (ohne das die Routingtabelle von Hand verändert wird)?


#4

Du aenderst nur die Firewall und listenport für http
nix am routing


#5

Über die private IPv4-Adresse lässt sich die Statusseite dann wie erwartet im Heimnetz via br-wan aufrufen.

Was IPv6 betrifft, ändert sich allerdings nichts an der Situation.


#6

hat der router ne iv6 auf dem interface?


#7

Ja.

6: br-wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether a6:e8:de:d9:d9:58 brd ff:ff:ff:ff:ff:ff
    inet 192.168.111.243/24 brd 192.168.111.255 scope global br-wan
       valid_lft forever preferred_lft forever
    inet6 fd26:b45b:fd50::a4e8:deff:fed9:d958/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 2a00:6020:xxxx:xxxx:a4e8:deff:fed9:d958/64 scope global dynamic 
       valid_lft 2298sec preferred_lft 948sec
    inet6 fe80::a4e8:deff:fed9:d958/64 scope link 
       valid_lft forever preferred_lft forever

#8

Jetzt funktionierte es. Ich habe die IPv6-Einstellungen am OpenWrt-Router noch einmal geändert und das Netzwerk auf den Freifunkknoten neu gestartet. Der Freifunk-Knoten hat jetzt (nur) “stateful”-IPv6-Adressen und keinen Eintrage mehr in der Routingtabelle mit dem lokalen IPv6-Präfix.

EDIT: Und dann geht es schon wieder nicht. Es klappt, solange das Heimnetz-IPv6-Präfix nicht in der Routingtabelle des Freifunkrouters auftaucht. Sonst nicht.


#9

Das ist aber Pfusch, Dein Problem liegt woanders.

wusel@ysabell:~$ traceroute 2001:bf7:1310:11:26a4:3cff:feb1:11d9 
traceroute to 2001:bf7:1310:11:26a4:3cff:feb1:11d9 (2001:bf7:1310:11:26a4:3cff:feb1:11d9), 30 hops max, 80 byte packets
 1  gut1.as206946.net (2001:678:xxxx:xxxx::1)  3.081 ms  3.057 ms  3.075 ms
 2  de0.as206946.net (2a06:e881:2600:42::1)  25.365 ms  27.863 ms  27.864 ms
 3  bgp-gut01.4830.org (2a06:e881:1700:1:400:c0ff:fefb:e277)  27.852 ms  27.839 ms  27.825 ms
 4  2a06:e881:1700:1:400:c0ff:fefb:e251 (2a06:e881:1700:1:400:c0ff:fefb:e251)  27.819 ms  27.802 ms  27.786 ms
 5  2001:bf7:1310:11:26a4:3cff:feb1:11d9 (2001:bf7:1310:11:26a4:3cff:feb1:11d9)  25.094 ms  25.092 ms  25.090 ms

root@33332-Schalueckstr-107-11d9:~# traceroute6 -n 2a06:e881:260c:xxxx:xxxx:xxxx:xxxx:94e4 
traceroute to 2a06:e881:260c:xxxx:xxxx:xxxx:xxxx:94e4 (2a06:e881:260c:xxxx:xxxx:xxxx:xxxx:94e4), 30 hops max, 16 byte packets
 1  2a06:e881:260c:xxxx:xxxx:xxxx:xxxx:94e4  3.830 ms  2.591 ms  3.400 ms

Und dennoch klappen ssh oder wget:

wusel@ysabell:~$ wget -O /dev/null http://\[2001:bf7:1310:11:26a4:3cff:feb1:11d9\]
--2019-02-12 01:20:56--  http://[2001:bf7:1310:11:26a4:3cff:feb1:11d9]/
Connecting to [2001:bf7:1310:11:26a4:3cff:feb1:11d9]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 345 [text/html]
Saving to: '/dev/null'

/dev/null           100%[=====================>]     345  --.-KB/s   in 0s     

2019-02-12 01:20:56 (33.2 MB/s) - '/dev/null' saved [345/345]

#10

Das Problem tritt wohl dadurch auf, das der OpenWrt-Router auf ‘DHCPv6’ auf ‘stateless+stateful’ eingestellt war. Anscheinend (ich habe das nicht Verifiziert) wird dann die öffentliche Freifunk-IPv6 auch dem WAN-Interface zugewiesen. Jetzt habe ich das auf ‘stateful only’ umgestellt und alles funktioniert. Auch mit dem IPv6-Präfix des Heimnetzes in der Routingtabelle auf dem FF-Knoten. traceroute meldet, dass der Datenverkehr jetzt in beide Richtungen durch das Freifunk-Netz geht.


#11

Nochmal: mein LAN läuft auf DHCPv4 und RA. Damit bekommt auch ein Freifunk-Knoten auf dem WAN RFC1918-IPv4 und öffentliches IPv6. Und ich habe keine Probleme, die FF-Statusseiten auch der Knoten im LAN aufzurufen. Das läuft dann “außen rum” zum Knoten, der Rückweg via br-wan. Falls das nicht klappt, spuckt da AFAICS eine Firewall in die Suppe, weil die externe v6-IP eben eigentlich nur über das GW ins LAN darf.

Damit bekommen Androiden aber keine IPv6-Adresse mehr im LAN, oder?


#12

Wenn dem genau so ist, also die Antworten an die ff-ipv6 des FF-Routers über die br-wan-ipv6 des Gluon beantwortet würden, dann wäre schlicht der Webserver auf dem Gluon defekt.

Ganz unabhängig von der Firewall.
(Und vermutlich würde der Client, also Dein Webbrowser mit den Antworten auch nichts anfangen können.)


#13

Richtig.

Ansonsten was mir hilft als Workaround ist den Knoten mit extra port/vlan ein eigenen /64 zuweisen. Dann läuft es.