OpenWrt/OpenVPN: IPv6 Probleme wegen NDP

killerbees19

killerbees19

Member
Hallo,

ich verwende seit Jahren einen OpenVPN-Tunnel (tap!), um mehrere Netzwerke mit IPv6 zu versorgen. Das hat unter OpenWrt 12.09 (als Client) immer einwandfrei funktioniert. Jeder Standort bekommt dafür ein größeres Subnetz (mindestens /56) und verteilt einzelne /64 daraus an bestimmte VLANs weiter. Bei einer neuen Installation auf Basis von OpenWrt 15.05 habe ich das Problem, dass mir sporadisch die Verbindung wegbricht. IPv4 über den Tunnel funktioniert währenddessen weiterhin einwandfrei. Offensichtlich ist NDP die Problemursache, da die Neighbor Solicitations vom Server nicht beantwortet werden.

Code: 
# ip -6 neigh show dev vpn (am Server)
2001:db8::10  router INCOMPLETE
fe80::1010:2020:3030:4040 lladdr 10:20:30:40:50:60 router REACHABLE

# ip -6 neigh show dev br-vpn (am Client)
2001:db8::1 lladdr 11:22:33:44:55:66 router REACHABLE
fe80::1111:2222:3333:4444 lladdr 11:22:33:44:55:66 router REACHABLE

Starte ich die Bridge am OpenWrt Router neu (br-vpn), die das tap-Device beinhaltet, funktioniert alles sofort wieder – dafür funktioniert IPv4 danach nicht mehr. Damit beides wieder läuft, muss ich die OpenVPN-Instanz (am Client) neu starten. Ich weiß im Moment aber nicht, warum es dazwischen plötzlich nicht mehr funktioniert. Die Firewall wirkt intakt und die Routing Tabelle ebenfalls. Was mir komisch vorkommt ist, dass die Link-Local Adresse vom Client in der Neighbor Tabelle als REACHABLE gelistet wird, das eigentliche Ziel fürs Routing aber weiterhin INCOMPLETE ist.

Was soll ich beim nächsten Ausfall (auf Server oder Clientseite) noch prüfen?
Habt ihr noch irgendwelche anderen Anhaltspunkte oder Tipps für mein Problem?


MfG Christian
 
Ich hatte noch ein wichtiges Detail vergessen: Ich nutze dort nur deswegen tap anstatt tun, weil damals von Haus aus ältere OpenVPN Versionen (2.1/2.2) genutzt werden mussten und somit IPv6 nur so möglich war.

Bei OpenWrt gibt es die Bridge "br-vpn", die aber als eigenständiges Interface agiert. Kein VLAN oder sonst irgendeine Schnittstelle ist damit verbunden! Es wird alles hinüber geroutet. Am Server ist es genau das gleiche Verhalten. Mein /48 Netz wird vom Provider auf die primäre IP des Servers geroutet. Danach werden die kleineren Subnetze wieder weiter geroutet an die VPN-Clients.

Alle NDP Pakete im Tunnel bleiben also im Tunnel und werden nur von den jeweiligen Clients und dem Server verschickt sowie empfangen. Weder das Netz vom Provider (hinter eth0) oder die VLANS hinter den Clients bekommen davon etwas mit. Die Menge an NDP-Paketen ist somit überschaubar, da es nur eine handvoll Adressen der VPN-Clients aus einem /64 betrifft.

Die Jackpotfrage ist im Moment nur, was sich zwischen den beiden OpenWrt Versionen geändert hat, dass es plötzlich Probleme gibt. OpenVPN wurde von 2.2.2 auf 2.3.6 aktualisiert und der Linux Kernel ist deutlich neuer. Beides sollte aber nicht ausschlaggebend sein. Die alten Setups laufen unterdessen problemlos weiter…


MfG Christian
 
Seit einem kurzen Internetausfall ist das Problem wieder aufgetaucht, davor war 20-30 Stunden Ruhe.
Was kann/soll ich noch testen? IPv4 über den Tunnel läuft gerade, IPv6 ist wieder gestört.

EDIT: Und plötzlich läuft es wieder von selbst, obwohl es stundenlang gestört war… :confused:


MfG Christian
 
Last edited by a moderator:
killerbees19 said:
Und plötzlich läuft es wieder von selbst, obwohl es stundenlang gestört war…
Click to expand...
Offenbar läuft es plötzlich wieder, wenn ich tcpdump am OpenWrt-Router starte. Der Promiscuous Mode dürfte dafür sorgen, dass die Pakete wieder richtig beantwortet werden. Der nachfolgende Mitschnitt ist von der Serverseite aus gemacht. Um 11:46:58 wurde es dann auf der Clientseite ebenfalls gestartet. Danach funktionierte sofort wieder alles. Dieses Verhalten konnte ich jetzt mehrfach reproduzieren.

Code: 
11:46:47.654209 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::0000:0000:0000:0002 > fe80::0000:0000:0000:0001: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::0000:0000:0000:0001
11:46:47.673633 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::0000:0000:0000:0001 > fe80::0000:0000:0000:0002: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is fe80::0000:0000:0000:0001, Flags [router, solicited]

11:46:52.499529 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::0000:0000:0000:0002 > ff02::1:ff00:10: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:db8::10

11:46:52.678939 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::0000:0000:0000:0001 > fe80::0000:0000:0000:0002: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::0000:0000:0000:0002
11:46:52.678991 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::0000:0000:0000:0002 > fe80::0000:0000:0000:0001: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is fe80::0000:0000:0000:0002, Flags [router, solicited]

11:46:53.498228 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::0000:0000:0000:0002 > ff02::1:ff00:10: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:db8::10
11:46:54.498281 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::0000:0000:0000:0002 > ff02::1:ff00:10: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:db8::10

11:46:58.091201 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::0000:0000:0000:0002 > ff02::1:ff00:10: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:db8::10
11:46:58.110626 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db8::10 > fe80::0000:0000:0000:0002: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is 2001:db8::10, Flags [router, solicited, override]

Was läuft da vorher falsch? Kernel Bug? Firewall Problem? Routing Fehler? Konfigurationsfehler meinerseits? :(


MfG Christian
 
Ich habe einmal meinen Testrouter (TL-MR3220) angeworfen und einen neuen User am VPN-Server angelegt. Minimalinstallation von OpenWrt 15.05 nur mit OpenVPN und sofort auf das gleiche Problem gestoßen. Upgrade auf die aktuellste Trunk Version und exakt das gleiche Verhalten.

Die Firewall blockt sicher nichts, soviel weiß ich mittlerweile. Ich habe ip6tables mit so vielen Debug-Regeln gefüttert, da bleibt nichts hängen, was nicht hängen bleiben soll. Das Routing sieht korrekt aus und der Kernel wurde von 3.18 auf 4.1 aktualisiert.

Ich bin mit meinem Latein am Ende! Hat noch irgendjemand Tipps, wie ich feststellen kann, warum die Neighbor Solicitation Pakete vom Client sporadisch nicht korrekt beantwortet werden? Oder muss ich den Fehler doch am VPN-Server suchen? Aktuellere Paketmitschnitte von beiden Seiten liefere ich gerne nach, sofern benötigt.


MfG Christian
 
Die vermutliche Ursache: Die Bridge in OpenWrt hatte IPv4/IPv6 Adressen, der tap-Adapter nur eine für IPv4. Offenbar hat das den Kernel in der aktuellen Version durcheinander gebracht, weil die Bridge nicht immer zum VPN-Device passte. Die aktuelle Empfehlung ist, den Adapter innerhalb von OpenWrt mit dem Protkoll "none" abzubilden. Das wäre damals aber nicht möglich gewesen.

Diesen Mischmaschmurks versuche ich gerade mit einem neuen Setup zu korrigieren, wo nur noch tun verwendet wird und auf die eingebaute IPv6-Funktionalität von OpenVPN gesetzt werden soll. tap ist somit nicht mehr notwendig, da alle Clients mittlerweile bei Version 2.3 angekommen sind.


MfG Christian
 
You must log in or register to reply here.
Back
Top