(OpenWRT-)IPv6-Einstellungen und Erreichbarkeit des Routers

Technik Funk & Router
1

Nachdem ich den Router des Heimnetzwerks auf OpenWRT umgestellt habe, kann ich den angeschlossenen Freifunkrouter (Statusseite, SSH) nicht mehr über dessen öffentliche IPv6-Adresse erreichen. Der L2TP-Tunnel läuft und Daten in der Karte sind auch vollständig. Ich vermute, dass es sich um ein Problem mit der Firewall handelt, nur wie lässt sich das Problem näher eingrenzen? Die OpenWRT-Firewall-Einstellungen sind ‘original’ und nur um Portfreigaben für VoIP ergänzt.

https://karte.freifunk-muensterland.de/map36/#!v:m;n:44d9e7ace223

  • ping funktioniert ohne Paketverlust
  • SSH funktioniert nicht über die öffentliche IPv6 (mit der privaten IPv4-Adresse im Heimnetz kein Problem)
  • Statusseite wird nicht angezeigt:

wget -O- http://[2a03:2260:115:3600:46d9:e7ff:feac:e223]/
--2019-02-10 22:49:37--  http://[2a03:2260:115:3600:46d9:e7ff:feac:e223]/
Verbindungsaufbau zu [2a03:2260:115:3600:46d9:e7ff:feac:e223]:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet …
  • SSH- und HTTP-Verbindungen zu anderen Freifunkroutern im sind kein Problem
2

Also ich kann die Statusseite erreichen.

So pauschal würde ich mal behaupten dein IPv6 in deinem Heimnetz ist Kapod :slight_smile:

3

Klingt plausibel. Wie muss das denn unter OpenWRT eingestellt werden? Der Router hängt an einem FTTH-Anschluss und bekommt ein /56-Präfix. Ich ging davon aus, dass die Standardeinstellungen passen…

4

Der HTTP-Request kommt an, offensichtlich geht die Antwort des Webservers auf dem Knoten verloren.

Client -> Freifunkknoten

traceroute to 2a03:2260:115:3600:46d9:e7ff:feac:e223 (2a03:2260:115:3600:46d9:e7ff:feac:e223), 30 hops max, 80 byte packets
 1  2a00:6020:xxxx:xxxx::1 (2a00:6020:xxxx:xxxx::1)  7.091 ms  5.725 ms  10.525 ms
 2  * * *
 3  be10-717.cr1.int1-dus.dg-ao.de (2a00:6020:0:2::2)  13.036 ms  13.089 ms  16.010 ms
 4  be10-717.pr2.int1-dus.dg-w.de (2a00:6020:0:2::3)  16.014 ms * *
 5  2a03:2260::5 (2a03:2260::5)  19.292 ms  19.262 ms  15.946 ms
 6  2a03:2260::4 (2a03:2260::4)  31.851 ms  22.020 ms  24.451 ms
 7  2001:4ba0:ffa4:3d2:5:199:135:168 (2001:4ba0:ffa4:3d2:5:199:135:168)  25.308 ms  28.517 ms  26.364 ms
 8  2a03:2260:115:3600:46d9:e7ff:feac:e223 (2a03:2260:115:3600:46d9:e7ff:feac:e223)  44.330 ms  50.777 ms  45.429 ms

Umgekehrt nehmen die Pakete den direkten Weg. Freifunkknoten -> Client:

traceroute to 2a00:6020:xxxx:xxxx::7bf (2a00:6020:xxxx:xxxx::7bf), 30 hops max, 64 byte packets
 1  2a00:6020:xxxx:xxxx::7bf (2a00:6020:xxxx:xxxx::7bf)  13.244 ms  6.355 ms  5.086 ms

Wie kann ich mir das vorstellen? Werden die Pakete vom Webserver dann statt über br-client via br-wan verschickt und versanden dann in der Firewall des Knotens? Und wie schafft man da Abhilfe?

EDIT:
Daran scheint es zu liegen, hier der tcpdump-Output des Knotens, jeweils br-client und br-wan auf Port 80 während auf der Gegenstelle die Statusseite geöffnet wird, mittels wget -O- http://[2a03:2260:115:3600:46d9:e7ff:feac:e223]/

root@ffwaf-eloh-eschenweg-1:~# tcpdump -vv -i br-client port 80
tcpdump: listening on br-client, link-type EN10MB (Ethernet), capture size 262144 bytes
18:28:26.390671 IP6 (flowlabel 0xce1ad, hlim 57, next-header TCP (6) payload length: 40) 2a00:6020:xxxx:xxxx::7bf.34692 > 2a03:2260:115:3600:46d9:e7ff:feac:e223.80: Flags [S], cksum 0x0f9a (correct), seq 3690733389, win 28800, options [mss 1440,sackOK,TS val 23257578 ecr 0,nop,wscale 7], length 0
^C
1 packet captured
1 packet received by filter
0 packets dropped by kernel

root@ffwaf-eloh-eschenweg-1:~# tcpdump -vv -i br-wan port 80
tcpdump: listening on br-wan, link-type EN10MB (Ethernet), capture size 262144 bytes
18:28:46.163848 IP6 (flowlabel 0x16285, hlim 64, next-header TCP (6) payload length: 40) 2a03:2260:115:3600:46d9:e7ff:feac:e223.80 > 2a00:6020:xxxx:xxxx::7bf.34706: Flags [S.], cksum 0x61bd (incorrect -> 0x0c6e), seq 3510760251, ack 3368482310, win 28560, options [mss 1440,sackOK,TS val 7170116 ecr 23262521,nop,wscale 3], length 0
18:28:47.242174 IP6 (flowlabel 0xcc09c, hlim 64, next-header TCP (6) payload length: 40) 2a03:2260:115:3600:46d9:e7ff:feac:e223.80 > 2a00:6020:xxxx:xxxx::7bf.34706: Flags [S.], cksum 0x61bd (incorrect -> 0x0c02), seq 3510760251, ack 3368482310, win 28560, options [mss 1440,sackOK,TS val 7170224 ecr 23262521,nop,wscale 3], length 0
18:28:48.042160 IP6 (flowlabel 0x20a4c, hlim 64, next-header TCP (6) payload length: 40) 2a03:2260:115:3600:46d9:e7ff:feac:e223.80 > 2a00:6020:xxxx:xxxx::7bf.34690: Flags [S.], cksum 0x61bd (incorrect -> 0xf969), seq 1127678052, ack 3391661475, win 28560, options [mss 1440,sackOK,TS val 7170304 ecr 23254901,nop,wscale 3], length 0
18:28:49.322143 IP6 (flowlabel 0x03d2b, hlim 64, next-header TCP (6) payload length: 40) 2a03:2260:115:3600:46d9:e7ff:feac:e223.80 > 2a00:6020:xxxx:xxxx::7bf.34706: Flags [S.], cksum 0x61bd (incorrect -> 0x0b32), seq 3510760251, ack 3368482310, win 28560, options [mss 1440,sackOK,TS val 7170432 ecr 23262521,nop,wscale 3], length 0
^C
4 packets captured
5 packets received by filter
0 packets dropped by kernel
5

Hmm, bei mir geht das genau so: Der lokale Prefix liegt ja am WAN an, das muß dann auch über br-wan raus …

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:xxx:xxx::1)  3.263 ms  3.231 ms  3.206 ms
 2  de0.as206946.net (2a06:e881:2600:42::1)  25.609 ms  25.602 ms  25.604 ms
 3  bgp-gut01.4830.org (2a06:e881:1700:1:400:c0ff:fefb:e277)  25.589 ms  28.522 ms  28.538 ms
 4  2a06:e881:1700:1:400:c0ff:fefb:e251 (2a06:e881:1700:1:400:c0ff:fefb:e251)  28.541 ms  28.585 ms  28.571 ms
 5  2001:bf7:1310:11:26a4:3cff:feb1:11d9 (2001:bf7:1310:11:26a4:3cff:feb1:11d9)  22.673 ms  22.702 ms  25.299 ms

root@33332-Schalueckstr-107-11d9:~$ traceroute6 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  xxxxxxxxxxxxxxxx94e4.gt6.uu.org (2a06:e881:260c:xxxx:xxxx:xxxx:xxxx:94e4)  3.224 ms  4.049 ms  2.450 ms

Zugriff auf die Statusseite aus dem LAN via v6 tut:

wusel@ysabell:~$ LANG=C wget -O /dev/null http://\[2001:bf7:1310:11:26a4:3cff:feb1:11d9\]
--2019-02-12 00:46:39--  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 00:46:39 (34.5 MB/s) - '/dev/null' saved [345/345]

Ich hatte erst gluon-ebtables-source-filter im Verdacht (haben wir nicht in der FW), aber da geht es um FORWARD; die Ausgabe vom Webserver ist aber OUTPUT.

Ah, warte mal: stecken Freifunk-Router und Dein Client an einem Switch hinter dem OpenWrt-Router, oder direkt an unterschiedlichen Ports davon. Weil:

2a03:2260:115:3600:46d9:e7ff:feac:e223.80 > 2a00:6020:xxxx:xxxx::7bf.34706

=> Der Freifunkrouter spricht mit seiner FF-IP in Dein LAN. An einem Hub/Switch sollte das tun (Switch == Layer 2); an zwei Ports eines OpenWrt-Routers könnten Firewall-Einstellungen (Layer 3) diese Antwortpakete verwerfen (schließlich ist 2a03:2260:115::/48 außerhalb des LANs).

6

Es ist nur ein Router mit integriertem Switch und Netzwerkbrücke über LAN und WLAN.

EDIT: Der Router verteilt jetzt DHCPv6 nur noch ‚stateful-only‘, damit ist das Problem verschwunden.

7

Habe es mal mit stateful only probiert, aber damit kriegen manche Geräte kein ipv6 mehr. Eine andere Lösung ist es, auf ein extra Port/vlan ein eigenes /64 anzulegen. Dann kann der Knoten mit seiner Statusseite erreicht werden.

8

OK – nicht so toll, wieder abgestellt.

Das ist wohl auch die Ursache. Gibt es einen Hinweis, welche Firewall-Einstellung (OpenWrt, vanilla) das sein könnte?

9

Ich schalte als erstes i. d. R. die FW aus, weil ich mir damit schon zu oft in den Fuß geschossen habe (=> Reflash, das war besonders bei den Foneras damals schmerzhaft, da zeitintensiv), insofern kann ich dazu leider nichts sagen. Aber genau das sollte ja zur Verifikation, ob es am OpenWrt-Firewalling liegt, taugen?