OPNsense Forum
International Forums => German - Deutsch => Topic started by: Kju on February 08, 2022, 07:38:46 pm
-
Hallo zusammen,
ich bin noch sehr neu bei OPNsense und teste gerade dessen IPv6 Fähigkeiten für den Heimgebrauch, da mir die kaputte Implementierung bei Mikrotik (zumindest bei dynamischen Präfixen) auf den Senkel geht. Ich hoffe mit OPNsense eine Alternative gefunden zu haben. :)
Leider habe ich aber auch mit OPNsense ein Problem, zu dem ich hier hoffentlich eine Lösung finde. Vielleicht habe ich auch einfach nur irgendwo einen Haken vergessen.
Zu meinem Testaufbau:
- Aktuelle Version OPNsense 22.1
- VM mit zwei virtuellen Interfaces, 1x WAN (VLAN 10 als Access Port), 1x LAN (VLAN aware)
- VM hängt hinter einer Fritzbox, welches die Einwahl macht und IPv6 Präfixe per DHCP6 verteilt
- WAN Interface erhält eine IPv6 Adresse sowie ein delegated prefix /60
- VLAN100 auf LAN-Interface erstellt, konfiguriert als "Track Interface" und sendet Router Advertisements
Das funktioniert alles hervorragend. Meine Geräte in VLAN 100 bekommen eine IPv6 Adresse und IPv6 Traffic funktioniert wunderbar. Nun kommt aber das Aber:
Sobald sich mein vom ISP zugeteiltes IPv6 Präfix ändert, erhält das WAN-Interface innerhalb weniger Sekunden eine neue IPv6 Adresse. Die alte Adresse wird als Deprecated markiert. Leider holt sich OPNsense im Anschluss kein neues Präfix per DHCPv6 (verifiziert via packet capture), sondern erst nach einigen Stunden, wahrscheinlich wenn der Lease ausläuft? Nach der täglichen Zwangstrennung (ja, einige ISPs machen das noch ::) ) dauerte es die letzten Tage 1,5 Stunden, bis OPNsense sich ein neues gültiges Präfix geholt hat. In der Zeit ist IPv6 kaputt, da mir die IPs vom ISP nicht mehr zugeteilt sind. Sobald OPNsense ein neues Präfix erhalten hat, wird das Netz auf VLAN100 aktualisiert und den Clients mitgeteilt, dass die alte Adresse deprecated ist und diese sich eine neue IPv6 aus dem aktuellen Netz zuweisen dürfen (der Part, der bei Mikrotik nicht anständig funktioniert).
Nun ist die Frage: Wie überrede ich OPNsense dazu, per DHCP6 nach einem neuen Präfix zu fragen, sobald das WAN-Interface eine neue IPv6 erhalten hat? Hab ich eine Einstellung dafür vergessen? Zumindest in meinem Fall bedeutet eine neue WAN-IPv6 auch ein neues IPv6-Präfix. Händisch kann ich das forcieren, indem ich im WAN-Interface bei DHCP auf "reload" klicke.
Ich würde mich freuen, wenn mir jemand bei diesem Problem weiter helfen könnte. :)
Viele Grüße
-
Am besten nicht auf die Zwankstrennung warten, sondern unter "System -> Settings -> Cron" ein festen Zeitpunkt für die Zwangstrennung eintragen.
Dann mache die Firewall ein aktives Reload auf die Schnittstelle WAN und fordert "schnell" ein Prefix an.
Trotzdem ist mir aufgefallen, dass es einige Zeit dauern kann, bis das Interface, welches mit TRACK INTERFACE ein ipv6-Bereich zugewiesen bekommen, tatsächlich erhält.
-
Jap, dauert bei mir auch manchmal ein paar Minuten bis LAN und co ihr v6 wieder haben.
-
Danke für euren Input.
Ein Cronjob würde es auf jeden Fall besser machen, aber so richtig gefallen tut es mir immer noch nicht. In der Fritzbox ist eine Zeit für die Zwangstrennung eingetragen (ansonsten wird diese vom ISP nicht immer zur selben Zeit gemacht) und kurz darauf könnte ich per Cronjob natürlich das Interface Reloaden. Dann sollte der IPv6-Ausfall minimal sein. Probleme hab ich jedoch, wenn die Fritzbox rebootet wird, z.B. durch ein Update oder aus anderem Gründen die Verbindung zu anderen Zeiten unterbrochen wird.
Bei mir läuft >40% meines Traffic über v6, weshalb mir die Sache schon recht wichtig ist.
Der Cronjob brachte mich aber auf eine andere Idee:
Ich habe mir ein kleines Shell-Skript geschrieben, welches schaut, ob sich die öffentliche IPv6 auf dem WAN-Interface geändert hat. Wenn dem so ist, wird das Interface neu gestartet. Das ganze läuft als Cron 1x die Minute. In meinen Tests haben meine Clients so immer innerhalb einer Minute eine neue v6 Adresse bekommen.
Statt dem Restart wäre nur ein neues Präfix anfordern natürlich noch besser, aber leider habe ich bisher nicht herausgefunden, wie das über die Shell geht. Ich hatte jetzt auch keine Lust mehr, in den PHP-Skripten zu stöbern. :)
Hier nun einmal mein erste Version von dem Skript:
#!/bin/sh
INT="em0"
FILE="/tmp/oldWanIp"
if [ -f "$FILE" ]; then
oldIP=`cat "$FILE"`
else
oldIP=""
fi
newIP=`ifconfig "$INT" | grep -v deprecated | awk '/inet6 2001/{print $2}'`
echo "Old IP: $oldIP"
echo "New IP: $newIP"
if [ "$oldIP" != "$newIP" ]; then
echo "reload WAN interface"
/usr/local/sbin/configctl interface linkup stop "$INT"
/usr/local/sbin/configctl interface reconfigure "$INT"
/usr/local/sbin/configctl interface linkup start "$INT"
echo "$newIP" > "$FILE"
fi
Gestern hatte ich noch probiert, ein Legacy Plugin (https://docs.opnsense.org/development/backend/legacy.html) zu schreiben. Ich habe auf das newwan-Event gelauscht. Aber scheinbar wird das Event nicht getriggert, wenn sich das WAN Interface über SLAAC eine neue IPv6 zugewiesen hat. Außerdem habe ich in den PHP-Skripten gesehen, dass wenn "Request only an IPv6 prefix" aktiviert ist, das Event auch nur getriggert wird, wenn sich das Präfix ändert. Also so ein bisschen Henne Ei Problem. :)
Weitere Verbesserungsvorschläge werden gerne entgegen genommen, aber ich hoffe, dass sich meine IPv6 Probleme damit nun endlich weitestgehend erledigt haben. Besser als übers Mikrotik scheint es jetzt schon definitiv zu sein. Kann also gut sein, dass ich mir demnächst eine SFP+-Netzwerkkarte für meinen Server besorgen muss. ;D ::)
-
Nicht persönlich nehmen, aber so ein Gefrickel soll die Zukunft des Internets sein? IPv6 gehört verboten...
-
Hi :D
1. Du hast IPv4 falsch geschrieben. Diese ganzen Krücken und Hacks die wir tagtäglich nutzen müssen, gehören tatsächlich verboten. Und von den Kosten von IPv4 Adressen will ich gar nicht erst anfangen. Viele meiner Dienste im Internet lasse ich schon auf IPv6 Only laufen. :D
2. Habe ich ein Problem gefixt, was die meisten OPNsense-Nutzer wahrscheinlich gar nicht wirklich wahrnehmen, da sie entweder:
- Kein IPv6 konfiguriert haben
- Einen anständigen ISP haben der keine Zwangstrennungen macht und die Leasetime der Präfixe mehrere Tage beträgt (da muss ich Telekom positiv hervorheben) oder gar feste IPs haben
- Einen ISP haben, der es nicht einmal im Jahre 2022 geschafft hat, IPv6 auszurollen. (Hallo EWE *klick* (https://twitter.com/Moin_EWE/status/1250433367964672007) )
- oder die Trennung i.d.R. Nachts ist und sich alles eh nach einer halben Stunde bis Stunde wieder repariert hat und da alle schalfen.
Ich empfinde ein simples Skript jetzt auch nicht als Gefrickel. Auf der Arbeit schreibe ich täglich Skripte um Dinge zu automatisieren, optimieren oder realisieren, die out of the Box nicht möglich sind.
Und man sollte auch nicht vergessen, dass das Problem nur durch die zwischengeschaltete Fritzbox kommt. Wenn OPNsense nicht wäre, würde die Fritzbox zuverlässig IPv6 Adressen verteilen (bzw die Clients sich welche per SLAAC zuweisen), auch nach einer Zwangstrennung - einfach da das DHCPv6 entfällt. Wenn die Fritzbox nicht wäre und OPNsense hier alleine stehen würde, wäre das vielleicht ebenfalls so.
PS: Bitte nimm Punkt 1 mit etwas Humor. Es ist meine Meinung und die einiger Netzwerker-Kollegen aus der Firma. :)
-
Hi Kju,
ich habe exakt das selbe Problem (auch mit ner FB dazwischen) und hatte mir damals auch ein ähnliches script gebaut, was aber irgenwann nicht mehr funktioniert hat (vermutlich wegen configctl) und ich dann keine Lust mehr hatte und wieder v6 deaktivierte. Da ich aber mittlerweile nicht mehr auf v6 verzichten möchte, hatte ich gesucht und den Thread hier gefunden. Fährst du dein Script mit der aktuellsten opnsense Version immer noch so oder hast du was verändert?
Edit: Seems to work :)
Hier noch mein altes Script:
#!/bin/sh
wan_ip="$(ifconfig igb0 | grep inet6 | grep 2003 | grep -v deprecated | awk '{print $2}')"
lan_ip="$(ifconfig igb1 | grep inet6 | grep 2003 | grep -v deprecated | awk '{print $2}')"
#check if tmpfile exists
if [ ! -f "/tmp/v6addr" ]; then ifconfig igb0 | grep inet6 | grep 2003 | grep -v deprecated | awk '{print $2
}' >/tmp/v6addr ; fi
old_ip="$(cat /tmp/v6addr)"
[ -z $old_ip ] && old_ip="-"
if [ $wan_ip != $old_ip ]
then
echo "ip changed!!" >> /tmp/v6addr.log
/usr/local/sbin/configctl interface reconfigure && ifconfig igb0 | grep inet6 | grep 2003 | grep -v deprecated | awk '{print $2}' >/tmp/v6addr && sleep 3 && pkill -9 unbound && pluginctl dns
else
echo "ip did not change" >>/tmp/v6addr.log
exit 0
fi
-
Edit: Seems to work :)
Cool, freut mich, dass dir mein Skript weiter geholfen hat. Ich selber nutze es seit ich glaube Oktober nicht mehr, da ich nun wieder bei der Telekom bin und dort alles einfach funktioniert. :)
-
Moin zusammen,
mit Glück bin ich auf den Beitrag hier gestoßen. Ich habe seit ca. zwei Wochen OPNsense im Einsatz und bin soweit auch mega zufrieden. Leider kommt auch bei mir ein Aber - nämlich IPv6 bzw. die Aktualisierung der Track Interfaces. Hin und wieder kommt es bei mir vor, dass nachts die Leitung einen Reset durch ASSIA oder Wartungsarbeiten bekommt. Dabei ist mir dann aufgefallen, dass meine Geräte auch morgens kein IPv6 mehr haben. Als ISP verwende ich Deutsche Telekom mit einem privaten Tarif.
Wie habt ihr das konfiguriert bei Euch? Ansonsten würde ich gerne das Script bei mir einsetzen, mir fehlt da leider noch die Erfahrung, was wo und wie. Ich würde es zunächst allerdings gerne mal ohne Script versuchen.
Was ich schon probiert habe, die Lease Time im RADVD (unmanaged, also ohne DHCPv6) auf 7260s und die Preferred Time auf 600s zu setzen. MaxInterval ist auf 300s konfiguriert.
Ich habe das Gefühl, das es etwas gebracht hat. Zumindest, wenn ich mal das LAN-Kabel zw. Speedport (Modem) und OPNsense gezogen habe, hatten die Clients spätestens nach 5 Minuten ihren neuen Präfix. Soweit ich weiß, ist es nach RFC auch vorgeschrieben nur Präfixe größer zwei Stunden anzunehmen, ansonsten gilt die alte Laufzeit.
Konfiguriert habe ich PPPoE nach der offiziellen Anleitung, also inkl. "Prevent Release" und "nur einen Präfix anfordern" (also keine WAN-Adresse per DHCPv6 anfordern, da die per SLAAC kommt).
Ich hatte aufgeschnappt, dass es bei pfSense wohl gehen soll, gleichzeitig hatte mir bei einem Testlauf zwischendurch das System insgesamt nicht ganz so zugesagt. OPNsense wirkt für mich irgendwie moderner und gerade hier im deutschen Raum "besser" vertreten. Leider haben sich die Entwickler aus dem offiziellen Issue https://github.com/opnsense/core/issues/6223 (https://github.com/opnsense/core/issues/6223) zurückgezogen und ich weiß leider nicht, wie wir da helfen können.
Freue mich über Eure Rückmeldung.
-
Moin zusammen,
ich war mal so frei und hab anhand Eurer Scripts mal einen weiteren Entwurf gemacht, der etwas dynamischer mit den Präfixen umgehen soll und dabei APIPA und ULA ignorieren.
Da ich leider noch nicht weiß, wie ich's auf die OPNsense Hardware mit nem Cron bekomme, kann ich Euch erstmal nur den ungetesten Code geben. Ich hatte mir testweise lokal unter Ubuntu mal ein Textfile mit inet6 etc. erstellt und das anstelle des ifconfig verwendet.
Bei Euren Scripts ist mir aufgefallen, dass einmal ein linkup stop und start dabei ist und beim andere nur ein reconfigure. Ich weiß leider noch nicht ganz, was davon wirklich benötigt wird.
Freu mich über Euer Feedback. Ich nehme gerne auch etwas Hilfe fürs Einrichten vom Cron. ;) Ich hab in der Oberfläche nur vorgefertige Auswahlmöglichkeiten beim Cron gefunden. Leider weiß ich nicht, wie ich das Script da reinbekomme.
Hier der Code:
#!/bin/sh
#
# checkwanipv6.sh
#
# Script for checking WAN IPv6 changes.
# E.g. Updated prefix after PPPoE reconnect or simply prefix renew
# Interface name like igc1, igb1 etc.
INTERFACE="pppoe0"
FILE="/tmp/wanipv6.old"
# Get current WAN IPv6 address. Ignore APIPA and ULA.
wanipv6=`ifconfig "$INTERFACE" | grep inet6 | grep -v '[[:space:]]fe80:\|[[:space:]]fd31:' | grep -v '\%' | grep -v deprecated | awk '{print $2}'`
# Ensure that wanipv6.old exists. Otherwise create with current WAN IPv6 entry.
if [ ! -f "$FILE" ]; then
echo "$wanipv6" > "$FILE"
fi
# Get old WAN IPv6 address from file.
wanipv6old=`cat "$FILE"`
echo "Old WAN IPv6: $wanipv6old"
echo "New WAN IPv6: $wanipv6"
if [ "$wanipv6old" != "$wanipv6" ]; then
echo "WAN IPv6 address has changed. Reload WAN interface."
/usr/local/sbin/configctl interface linkup stop "$INTERFACE"
/usr/local/sbin/configctl interface reconfigure "$INTERFACE"
/usr/local/sbin/configctl interface linkup start "$INTERFACE"
echo "$wanipv6" > "$FILE"
fi
Beste Grüße
Edit: Ich glaube, ich habe da noch einen Denkfehler drin. Wenn OPNsense selbst die Verbindung via PPPoE aufbaut, habe ich da gerade eine Endlosschleife gebaut? Nach einem reconfigure bekomme ich ja wieder eine neue WAN IP. Habt ihr da noch eine Idee um das zu verhindern?
-
Moin zusammen,
damit es hier nachvollziehbar und leserlich bleibt, hier nochmal ein neuer Entwurf. Der sollte jetzt die Schleife vermeiden und prüft zusätzlich das LAN-Interface auf Veränderung. Wie findet ihr den neuen Entwurf?
Ich möchte mich an der Stelle auch nochmal für Eure großartige Vorarbeit bedanken. Auf die Idee mit einem Skript bin ich gar nicht gekommen und ich glaube ohne Eure Ansätze wäre es mir auch schwergefallen.
Viele Grüße
#!/bin/sh
#
# checkwanipv6.sh
#
# Script for checking WAN IPv6 changes.
# E.g. Updated prefix after PPPoE reconnect or simply prefix renew.
# Interface name like pppoe0, igc1, igb1 etc.
WAN_INTERFACE="pppoe0"
LAN_INTERFACE="igc0"
WANFILE="/tmp/wanipv6.old"
LANFILE="/tmp/lanipv6.old"
# Get current WAN IPv6 address. Ignore APIPA and ULA.
wanipv6=`ifconfig "$WAN_INTERFACE" | grep inet6 | grep -v '[[:space:]]fe80:\|[[:space:]]fd31:' | grep -v '\%' | grep -v deprecated | awk '{print $2}'`
lanipv6=`ifconfig "$LAN_INTERFACE" | grep inet6 | grep -v '[[:space:]]fe80:\|[[:space:]]fd31:' | grep -v '\%' | grep -v deprecated | awk '{print $2}'`
# Ensure that wanipv6.old exists. Otherwise create with current WAN IPv6 entry.
if [ ! -f "$WANFILE" ]; then
echo "$wanipv6" > "$WANFILE"
fi
# Ensure that lanipv6.old exists. Otherwise create with current LAN IPv6 entry.
if [ ! -f "$LANFILE" ]; then
echo "$lanipv6" > "$LANFILE"
fi
# Get old WAN and LAN IPv6 addresses from file.
wanipv6old=`cat "$WANFILE"`
lanipv6old=`cat "$LANFILE"`
echo "Old WAN IPv6: $wanipv6old"
echo "New WAN IPv6: $wanipv6"
echo "Old LAN IPv6: $lanipv6old"
echo "New LAN IPv6: $lanipv6"
# Reload WAN interface as LAN IPv6 address seems to be stuck or empty after WAN IPv6 change.
if [ "$wanipv6old" != "$wanipv6" ] && [ "$lanipv6old" == "$lanipv6" ]; then
echo "WAN IPv6 address has changed while LAN IPv6 address seems to be stuck. Reload WAN interface."
/usr/local/sbin/configctl interface linkup stop "$WAN_INTERFACE"
/usr/local/sbin/configctl interface reconfigure "$WAN_INTERFACE"
/usr/local/sbin/configctl interface linkup start "$WAN_INTERFACE"
elif [ "$wanipv6old" != "$wanipv6" ] && [ "$lanipv6" == "" ] && [ "$lanipv6old" != "" ]; then
echo "WAN IPv6 address has changed while LAN IPv6 address seems to be empty. Reload WAN interface."
/usr/local/sbin/configctl interface linkup stop "$WAN_INTERFACE"
/usr/local/sbin/configctl interface reconfigure "$WAN_INTERFACE"
/usr/local/sbin/configctl interface linkup start "$WAN_INTERFACE"
fi
# Save current (empty) IPv6 addresses to file.
echo "$wanipv6" > "$WANFILE"
echo "$lanipv6" > "$LANFILE"
-
Bitte mal 23.1.7 mit https://github.com/opnsense/core/issues/6223#issuecomment-1542005368 probieren.
Grüsse
Franco
-
Hey @franco,
vielen Dank für Deine Antwort. Ich wollte Dich tatsächlich nachher auf Github anschreiben und meine Hilfe anbieten. Ich bin bei OPNsense noch nicht so ganz im Thema. Deswegen hatte ich mich erstmal an einem Script versucht. Abseits von IPv6 ist OPNsense die erste Software als Firewall/Router, die mir total zusagt und ich bin einfach begeisert. Ich haben einen riesen Respekt davor, wieviel Arbeit die Entwickler da reininvestieren. Danke für Eure Arbeit!
Muss ich den von dir verlinkten Kommentar per Terminal (ssh) durchführen? Sorry, für die blöde Frage, bin halt noch OPNsense Neuling. Komme eher aus dem C#-Umfeld.
Liebe Grüße und danke!
-
Hi :)
Ja auf der Console/SSH als root.
IPv6 bekommt schon regelmässig Verbesserungen, aber mehr Hilfe ist immer besser.
Danke
Franco
-
Hey @franco,
heute habe ich die 23.1.7_3 installiert und wollte gerade den Patch aufspielen. Nun ist mir auf Github allerdings aufgefallen, dass es in einem anderen Issue mit IPv6 auch ein Update mit einem anderen Patch gab.
Welchen Patch zum Testen würdest Du empfehlen?
# opnsense-patch 05c6f2e
vs.
# opnsense-revert -z dhcp6c
Mag nur nichts altes testen, wenn schon neuere Erkenntnisse vorhanden sind. :) Ich fürchte nur, da meine Leitung die letzten Nächte ohne Reconnect/ASSIA gewesen ist, dass ich aktuell wenig reproduzieren kann. Ach so und soll ich zum Testen "Prevent release" deaktivieren?
Grüße
-
Hi Cuberturtle,
Nach ein paar Tagen IPv6 Sprint scheint vor allem 05c6f2e vielversprechend.
Grüsse
Franco
-
Ah super, danke für die Info. Verstehe ich die Sourcen richtig, dass nun bei neuem Prefix ein force renew bei IPv6 für die Interfaces ausgelöst wird?
Beste Grüße
Cyberturtle
PS: Find's super, dass ihr an der IPv6-Sache trotz des teilweise fragwürdigen Tons auf Github noch dran seid. :)
Edit: Achso und soll ich meine radvd-Anpassung mit den verkürzten Lease-Zeiten wieder zurücksetzen für den Test?
-
Viel hilft viel. Im Log ist mit dem Patch (übrigens am besten neu starten oder zumindest das Interface rekonfigurieren) ersichtlich ob dann doch erneuert wurde trotz gleicher IP (force: yes) und das lässt dann auch radvd neu starten und der alte Prefix sollte weg sein von den Clients.
Grüsse
Franco
-
Hey Franco,
der Patch sieht in der Tat vielversprechend aus. Ich hab's zwischendurch mal gestetet. Das System zeigte keine Instabilitäten und ich habe am WAN dann mal das Kabel zum Modem getrennt und wieder eingesteckt und der Präfix hat die Clients erreicht!
Ich habe mir mal erlaubt es mit pfSense+ zu vergleichen. Mit pfSense CE lief IPv6 nicht zuverlässig, mit der Plus-Version scheint IPv6 dort ebenso sauber wie mit dem Patch zu laufen. Allerdings habe ich an meinen Clients (hab's auf die Schnelle nur mit Windows gestetet) ein anderes Verhalten zwischen beiden Systemen bemerkt.
Bei OPNsense ist der alte Präfix weg und der neue da. Bei pfSense+ sind die alten Präfixe als verworfen gekennzeichnet unter Windows und der neue wird genutzt.
Für mich ist beides in Ordnung, ich wollte es nur vollumfassend berichten. :)
Ich denke, wir sind auf dem richtigen Weg bei OPNsense. Mir ist von der thermischen Seite allerdings was aufgefallen. Ich habe keine Ahnung, ob's am Patch liegt oder an den Sensor-Treibern, allerdings sind die Temperaturen mit OPNsense wesentlich höher. Ebenso sind die Lastspitzen andere. Interessanterweise werden mir bei OPNsense per SSH auch andere Temperaturen angezeigt als im Widget (je nachdem, wie ich auslese). Mittels "sysctl -a dev.cpu | grep "temp"" sind die Temperaturen ca. 10 Grad kühler als mittels "sysctl -a | grep "dev.cpu"".
-
Hey Franco,
ich habe heute den Patch nochmal probiert und dabei die Option "Prevent release" deaktiviert gehabt. Funktioniert. Übrigens zeigt mir Windows heute an, dass die alten Prefixe ungültig sind. Keine Ahnung, ob das gestern einfach nur ein Schluckauf war.
Was mir allerdings aufgefallen ist. Die Internetverbindung muss mindestens 30-60s weg sein, bis PPPoE als down erkannt wird. Zwischendurch wurde es so nämlich sonst nur als Packetloss erkannt und es haben sich die IP-Adressen am WAN nebst Präfixen nicht verändert. (Das hatte ich aber auch schonmal vor dem Patch beobachtet, dass es lange dauern muss). Ich habe keine Ahnung, wie lange so eine nächtliche Zwangstrennung bei ASSIA dauert oder bei einigen Fällen, wo es den daily reconnect gibt.
Das Gateway-Monitoring habe ich übrigens deaktiviert. Damit werde ich nachher vielleicht auch nochmal testen.
Muss ich eigentlich vor dem nächsten regulären Update ein revert vorher durchführen?
Viele Grüße
Cyberturtle
-
Mir ist in den Logs noch etwas aufgefallen. Ich weiß nicht, ob die beiden IP-Adressen, die als new und old angegeben werden für den internen Vergleich herangezogen werden, weil dann wäre bei mir noch etwas unklar.
Bei der new-Adresse wird bei mir korrekterweise die WAN-Adresse angezeigt (igc1, pppoe0), bei der old-Adresse allerdings die Adresse des (igc2, opt1). Aus meiner Sicht wird quasi die falsche alte Adresse angezeigt. Die Adresse lag am GuestLAN tatsächlich an, aber nicht am WAN.
Ich hab davon mal einen Screenshot in den Anhang gepackt.
Edit: Ich kann das übrigens nicht reproduzieren. Manchmal (überwiegend) werden auch die richtigen Interface-IDs am Ende angezeigt, also quasi die 10f8 statt der 10fa. Ich kann mir den Wechsel der Interface-IDs daher nicht wirklich logisch herleiten. Ich habe auch einen Log-Eintrag gefunden, wo bei new die :10fa am Ende mit der old :10f8 angegeben wurde.
-
Hi Cyberturtle,
Danke für die Infos. :)
> Ich habe mir mal erlaubt es mit pfSense+ zu vergleichen. Mit pfSense CE lief IPv6 nicht zuverlässig, mit der Plus-Version scheint IPv6 dort ebenso sauber wie mit dem Patch zu laufen.
Das scheint mit etwas suspekt, wenn die CE Version ja die Grundlage der Plus sein soll und diese dann (besser) als unsere Software funktioniert? Ich werde das mal beobachten...
Bei den Temperaturen bin ich etwas ratlos weil es auf die Hardware ankommt. Wir haben bei unseren Boxen auch ein Offset von 10 Grad eingestellt da die Temperaturen auch zu hoch angezeigt werden standardmässig. Ob das jetzt ein Bug oder Feature von FreeBSD 13 ist weiss ich nicht. Also das hier für amdtemp(4):
dev.amdtemp.0.sensor_offset -> -10
> Die Internetverbindung muss mindestens 30-60s weg sein, bis PPPoE als down erkannt wird.
Das sollte dann schneller funktionieren mit Gateway Monitor eingeschaltet. In pfSense ist der ja standardmässig an und dann reagiert das auch schneller aus aus der mdp5-Software in einen Timeout zu rennen mit PPPoE.
> Muss ich eigentlich vor dem nächsten regulären Update ein revert vorher durchführen?
Revert beim Update macht das Update selbst. Das ist dann nur unpraktisch wenn ein Patch noch nicht im Release ist. Den muss man das noch mal neu Aufspielen. Aber das RENEW/REBIND sollte in 23.1.8 kommen. Sehe da keine Probleme bislang.
> Bei der new-Adresse wird bei mir korrekterweise die WAN-Adresse angezeigt (igc1, pppoe0), bei der old-Adresse allerdings die Adresse des (igc2, opt1).
Ich weiss warum. das OPT1 ist doch bestimmt als Track Interface konfiguriert. Das lässt sich beheben.
Grüsse
Franco
-
Hi Franco,
sehr gerne. Ich versuche so viel Input/Infos wie möglich zu liefern. Das scheint mir hilfreicher als einfach nur zu "nörgeln". :D Da ich ja selbst ITler bin, ist mir auch klar, dass es keine fehlerfreie Software gibt. Gibt da ja so die schöne Kette Fehlerwirkung -> Fehlerzustand -> Fehlhandlung. Manche Bugs sind in einigen Fällen halt nur nerviger.
Ich hab's mit der Plus-Version übrigens keine vier Stunden ausgehalten. ;D MTU bzw. MSS-Clamping funktioniert nicht sauber, den Traffic Shaper konnte ich echt vergessen und dann haben mir noch die IPv6-DynHost-Aliase gefehlt. Ich würde daher nicht sagen, es läuft "besser". Eben anders. Mir kommt OPNsense irgendwie reaktionsfreudiger vor und ich glaube, es ist für den Telekom-Anschluss irgendwie kompatibler. Ich konnte IPv6 mit der CE wirklich so gar nicht richtig in Gang kriegen. Bei gleichen Einstellungen habe ich dann ein Upgrade auf Plus durchgeführt und es ging. Allerdings scheinen dafür andere gar kein IPv6 mehr zu haben, wenn ich das im Forum dort richtig gelesen habe. Tja, kochen halt auch nur mit Wasser. ;)
Gibt es einen Sensor-Offset auch für Intel? Bei mir kommt nämlich ein J4125 zum Einsatz. Ich hab übrigens gestern mal Hardware CRC aktiviert (also das Häkchen entfernt). Damit ist die CPU-Last etwas runtergegangen.
Das Gateway Monitoring hatte ich für IPv4 schon aktiv, nur nicht für IPv6. Da werde ich dann auch mal den guten alten Google Public DNS für verwenden.
Ja, OPT1 (igc2) und LAN (igc0) sind bei mir beides Track Interfaces. Einmal Guest/Work und Privat.
Kommt der dhcp6c-Patch, den du hier ursprünglich verlinkt hattest, auch mit in die 23.1.8?
Beste Grüße
Cyberturtle
-
Ich kann von meiner Installation nicht sagen, das die Prefix-Delegation lange dauert.
Hatte gerade einen Prefix-Wechsel, weil Vodafone am Kabelnetz rumfummelt ( Wartungsarbeitung ) und dadurch es zu mehreren Ausfällen kam.
Nachdem die Leitung wieder stabil lief ( FritzBox 6951 im BridgeModus vor der OPNSense ) bekommen die OPNsense ihren neuen Prefix und die VLAN die Delegation direkt danach.
Das dauert keine Minute.
-
> Gibt es einen Sensor-Offset auch für Intel? Bei mir kommt nämlich ein J4125 zum Einsatz. Ich hab übrigens gestern mal Hardware CRC aktiviert (also das Häkchen entfernt). Damit ist die CPU-Last etwas runtergegangen.
Habe geschaut im Quellcode aber scheint es nicht zu geben. Sorry.
> Das Gateway Monitoring hatte ich für IPv4 schon aktiv, nur nicht für IPv6. Da werde ich dann auch mal den guten alten Google Public DNS für verwenden.
Sollte dann aber auch für IPv6 schon reagieren da es ja über die gleiche Einwahl geschieht.
> Ja, OPT1 (igc2) und LAN (igc0) sind bei mir beides Track Interfaces. Einmal Guest/Work und Privat.
https://github.com/opnsense/core/commit/bde52467d
# opnsense-patch bde52467d
> Kommt der dhcp6c-Patch, den du hier ursprünglich verlinkt hattest, auch mit in die 23.1.8?
Denke ja, keine Beschwerden bislang.
Grüsse
Franco
-
Hey Franco,
heute hatte ich leider einen reellen Use Case zum Test. Im DSLAM gab's nen Schluckauf und die Leitungen am Bündel wurden alle neugestartet. Die Interfaces hatten nach ca. 2 Minuten, als die Leitung wieder synchron war, auch die neuen Prefixes gezogen.
Das scheint prinzipiell zu funktionieren.
Leider haben nur meine WiFi Clients noch immer den alten Prefix bevorzugt drin. Ich habe keine Ahnung, ob das nen "Bug" jetzt noch im UniFi-AP ist oder einfach ein Verhalten der iOS-Geräte, die trotz des neuen Präfixes noch den alten bevorzugen. Ich vermute mal, das liegt an der AdvPreferredLifetime. Ich hatte nach dem Patch das Router Advertisment auf Default gesetzt, allerdings gehen dann die Zeiten ziemlich nach oben.
Vermutlich haben die WiFi Clients einfach nicht das deprecated empfangen, damit kann ich allerdings leben, da ich die Zeiten wieder entsprechend anpassen werde.
Aus meiner Sicht, wenngleich ich sicherlich nicht für alle reden kann, spricht nichts gegen den Patch im Release.
Beste Grüße
Cyberturtle
Edit: Vielleicht liegt es nicht nur an den Zeiten. Ich habe gerade mal testweise auf "Save" in den Router Advertisement geklickt und schwupps hatten alle WiFi-Geräte den neuen Präfix. Wird denn mit dem Patch auch das RA neugestartet? Ich sehe in den Logs nach dem Reset der Leitung jedenfalls unbound, vlan etc. mit einem (re)configure. Den radvd konnte ich jedenfalls nicht in den Logs finden.
Edit2: Ich vermute dennoch irgendwie die UniFi-APs als Ursache, da die kabelgebundenen Clients keine Probleme hatten.
-
Ok, so weit so gut. Bzgl. radvd und neuem Prefix: der Reload sollte eigentlich auch durch den Prefix Wechsel durchgehen. Kannst du im Log prüfen, z.B.:
# opnsense-log | grep dhcp6c_script
dhcp6c_script: REQUEST on igb1 executing
dhcp6c_script: REQUEST on igb1 renewal (REASON)
dhcp6c_script: RENEW on igb1 executing
dhcp6c_script: RENEW on igb1 executing
dhcp6c_script: RENEW on igb1 executing
dhcp6c_script: RENEW on igb1 renewal (PDINFO)
Es kann aber auch sein dass radvd nicht die richtige Adresse bekommen hat und dann der Reload fehlschlug (nur SIGHUP und das macht kein deprecate). Da können wir dann auf Basis 23.1.8 noch mal debugggen.
Grüsse
Franco
-
Hey Franco,
vielen Dank für die Rückmeldung. Nach dem Reboot war bei mir das Log leider leer bis auf den Eintrag nach dem Reboot. Ich bin schon auf die 23.1.8 gespannt und nehme mir dann gerne Zeit für weiteres Debugging, falls erforderlich.
Beste Grüße
-
Anmerkung zum Thema:
Heute haben wir die Fritzbox noch mal genauer angeschaut.
Neustart der FB oder LAN-Kabel raus geht alles prima.
"Neu verbinden" im Online Monitor der VB: läuft irgendwie alles weiter.
DSL/Telefon abklemmen: oh oh...
Die FB verliert doch tatsächlich das Wissen über die vergebenen Leases nach dem harten Neuverbinden anders als beim Knopf "Neu verbinden". Das bringt 2 Probleme mit sich:
1. Der Client mit dem aktiven Lease weiss nicht, dass das Lease nicht mehr existiert. Der Client meldet sich erst wenn er ein RENEW anfordert. Das dauert hier im Netzwerk bis zu 30 Minuten!
2. passiert dann beim RENEW folgendes: Der Server schickt eine leere Antwort mit dem Status Code "NoBinding"[1]. dhcp6c kann damit nichts anfangen und akzeptiert dies als valide Antwort (ohne Prefix oder Adresse). Dann probiert es ein REBIND. Bei diesem besteht genau das gleiche Problem. Und dann wartet es auf irgendeine Aktion auf dem Link oder Zwangstrennung der dann die Situation wieder gerade biegt. Das kann dann aber schon mal einen halben oder ganzen Tag dauern je nach dem wann der DSL Ausfall war.
Einen Patch für 2.) wäre https://github.com/opnsense/dhcp6c/commit/555bdcdeff3e0f4
Im Debug Mode für DHCPv6 findet sich sowas hier im System Log:
# opnsense-log | grep status.code..no.binding
dhcp6c 62966 status code: no binding
[...]
Wer den Patch ausprobieren will:
# pkg add -f https://pkg.opnsense.org/FreeBSD:13:amd64/snapshots/misc/dhcp6c-20230523_1.pkg
(am besten neu starten)
# opnsense-log | grep resetting.lease
dhcp6c 18251 - resetting lease on igb1
In dem Fall hat es dann zugeschlagen..
Zu 1.) sieht es mir nach einem Fehlverhalten der FB aus oder dhcp6c hat noch andere Probleme. Ich kenne mich mit den relevanten RFCs nicht gut genug aus.
Grüsse
Franco
[1] https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-5
-
Hey Franco,
bezüglich RFC könnten wir uns ja mal austauschen. Zumindest habe ich die RAs versucht daran anzulehnen und anzupassen als ich mich mit dem Thema hier angefangen habe zu beschäftigen.
Ich habe leider keine Fritzbox vorgeschaltet. Ich verwende nen Speedport Smart 4 als simples Modem. Da sollte ja dann alles schick sein?
Was macht die Fritzbox denn anders, wenn sie selbst als Router fungiert nachdem das DSL wieder da ist? Evtl. könnte man da mit Wireshark mal schauen, wie da die Clients mit dem neuen Präfix versorgt werden. Ist gerade mal so in die Tastatur gedacht.
Beste Grüße
Cyberturtle
-
Ich erinnere mich dunkel, dass ich früher damit auch mal Probleme hatte - da lag es daran, dass dummerweise bei der Neuvergabe von IPv6 die inzwischen verworfenen Adressen normalerweise bestehen bleiben.
Grundsätzlich ist die Annahme bei IPv6 zum einen, dass mehrere Präfixe gleichzeitig gelten dürfen (Beispiel ULA vs. GUA, aber eben auch mehrere GUAs) und dass zum anderen kein Mangel an Adressen herrscht. Die RFCs sehen also den Fall "dynamischer Präfix unter Wegfall des alten Präfix" gar nicht so richtig vor.
Einen Trick, den man bei SLAAC anwenden kann, ist, dass man ein RA schickt, mit dem der alte Präfix invalidiert wird, bevor man einen neuen annonciert. Dadurch würden die Clients ihre alten GUAs aufgeben. Voraussetzung ist, dass der Router das so macht und derweil die alte (noch) und neue Adresse (schon) kennt. Resettet man z.B. den Router einfach, bleiben die alten Clients lange noch auf der falschen GUA hängen.
Ich mache deshalb typischerweise nur SLAAC mit sehr kurzen Gültigkeiten, damit veraltete Adressen schnellstmöglich verworfen werden. Ich kann es aktuell aber gar nicht testen, weil mein ISP IPv4 dynamisch, aber IPv6 GUAs quasi-statisch vergibt.
-
Du sprichst von dem AdvDeprecatePrefix oder?
Ich kann ja mal nen Screenshot posten, wie ich die Zeiten eingestellt habe. Ich habe ebenfalls kurze Zeiten gewählt, damit die Präfixe schnell aktualisiert werden. Habe aktuell allerdings keine nächtliche Zwangstrennung mehr. Nur noch sporadisch, wenn der DSLAM mal wieder thermische Probleme hat.
Edit: Hier der Screenshot. Neue Präfixe werden ja nur bevorzugt, wenn sie größer als 2h sind. Die PreferredTime ist gerade bei iOS Clients wichtig.
-
Aus meiner Erinnerung ist es so, dass ein solcher RA einfach eine neue Lifetime von 0 für den alten Präfix vorgibt, damit wird er am Client sofort invalidiert. Danach wird dann der neue Präfix annonciert.
Ich kenne aber die RADVD Parameter dafür nicht, bzw. ich weiß gar nicht, ob der so etwas kann. Die Fritzbox nutzt m.W. auch keinen RADVD, sondern eine eigene Implementierung dafür. Mir ist aber klar, dass es da (leider) für manche Parameter Untergrenzen gibt, damit sie überhaupt berücksichtigt werden. Das Thema wurde auch schon mal hier diskutiert: https://forum.opnsense.org/index.php?topic=21682.0
Leider ist es so, dass die Client-Implementierungen z.T. auch abweichende Interpretationen machen, wie Du richtig schreibst. Ohne Ausprobieren kommt man also nicht viel weiter - und wie gesagt, ich kann derzeit nicht konkret helfen.
-
Dann meinen wir dasselbe. Mit dem DeprecatePrefix Parameter wird die Zero PreferredLifetime und ValidLifetime mit etwas mehr als zwei Stunden verteilt, damit der (Zero)Prefix nicht ignoriert wird. Ich glaube das war Kapitel 5.5.3 in der RFC dazu. Bin mir aber nicht sicher ob der Parameter nur beim Shutdown berücksichtigt wird.
-
RADVD ist ja SLAAC, DHCPv6 ist DHCPv6...
Ich muss mich korrigieren. Gestern Abend habe ich mit "Neu verbinden" dann doch das gleiche Szenario gehabt wie bei einer Trennung vom DSL.
Ich weiss jetzt nicht genau ob ein RA hier was ausrichten kann, vielleicht eher RS. Die Frage ist ja eher was tut man in dem Fall die Lease ist nicht abgelaufen aber wird vom Server nicht mehr geführt? Für so was würde man ja idealerweise eine Broadcast-Nachricht abgesetzt die sagt "Ich bin ein neuer Router. Wer mich kennt soll sich bitte jetzt neu anmelden per DHCPv6". Gibt es diese Nachricht nicht muss es über Plan B abgebildet werden:
Wir führen ein RENEW eben alle 5 Minuten aus. Das sieht unschön aus, aber hätte eine relativ rasche Neuvergabe der Lease zur Folge. Dann machen wir irgendwie DHCPv6 zu SLAAC. ;)
Capture wäre eine Variante. Ich kann das morgen mal prüfen nach dem 23.1.8 Release heute welches Vorrang hat.
Grüsse
Franco
-
Moin zusammen,
habe heute früh die 23.1.8 eingespielt. Das Update lief ohne Probleme durch und im Gegensatz zur 23.1.7_3 wollte es auch einen Neustart haben.
Nachdem Neustart waren die Clients stellenweise noch bis zu 30 Minuten mit den alten IPv6-Adressen bzw. Präfixen unterwegs. Ich vermute, das liegt dann wirklich an der PreferredLifetime. Ich möchte vermeiden das RA auf 300s oder niederiger zu setzen, denn so häufig verliere ich dann auch nicht den DSL-Sync. Vermutlich liegt's aber auch daran, dass während des Updates ja die Patches zurückgesetzt werden und daher das RENEW etc. nicht sauber lief oder Tracking ausblieb. Ich habe heute noch den AdvDeprecatePrefix auf on gesetzt, in der Hoffnung, dass es mit der Zero-Lifetime etwas bringt.
Zur Fritzbox: ich habe gestern mal bei einem Bekannten schauen dürfen. Die Fritzbox scheint in einem solchen Fall tatsächlich ein Zero Valid-Lifetime RA rumzuschicken, selbst wenn der Präfix eigentlich noch seine Gültigkeite hätte, aber eben nicht mehr geführt wird, weil sich durch den Reconnect eben der Präfix geändert hat oder eine neue Lifetime bekommen hat (falls nochmal der alte rumgeschickt wird).
Mein Vorschlag wäre daher bei jedem Reconnect/PPPoE-Loss einfach einen RA mit der Zero-Valid Lifetime zu senden und anschileßend den neuen (manchmal ist's auch wieder der alte) Präfix zu verteilen.
Ich hoffe, ich hab mich da verständlich ausgedrückt. Das dürfte dann die sauberste Lösung sein.
Wie seht ihr das?
Beste Grüße
Cyberturtle
Edit: Nach einem Reboot, meine ich gestern übrigens auch ein RA mit Zero-Lifetime in der Fritzbox gesehen zu haben und dann im Anschluss wurde die neue IPv6-Adresse bei meinem Bekannten verteilt.
-
Moin,
Nun ja das RA ist ja nur für SLAAC. Ob wir da jetzt WAN-seiting mit dem Hilfsmode SLAAC das eigentliche DHPCv6 "nachsteuern" wollen ist eine schwierige Frage... es wird zu vermehrten Verbindungsabbrüchen/Neuverbinden führen. Meine Frage war ja ob wir innerhalb DHCPv6 Möglichkeiten haben oder ob das schlicht nicht im RFC/Standard verankert ist.
LAN-seitig senden wir das entsprechende RA sofern nach dem Reconnect ein neuer Prefix gesetzt wird, sonst eben nicht. Ich sehe da kein Problem aktuell, bzw. keins das nicht schon gelöst wurde in 23.1.x. Aber auch hier betrifft das nur SLAAC/radvd und nicht DHCPv6 clients im LAN.
Das Update spielt zwar manuelle Patches zurück aber das RENEW/REBIND ist ja drin sowie alle dhcp6c Verbesserungen ausser dem letzten um mit Upstream-Verbindungsabbruch besser (bzw. überhaupt) klar zu kommen.
-
Nun ja das RA ist ja nur für SLAAC. Ob wir da jetzt WAN-seiting mit dem Hilfsmode SLAAC das eigentliche DHPCv6 "nachsteuern" wollen ist eine schwierige Frage... es wird zu vermehrten Verbindungsabbrüchen/Neuverbinden führen. Meine Frage war ja ob wir innerhalb DHCPv6 Möglichkeiten haben oder ob das schlicht nicht im RFC/Standard verankert ist.
...was bei mir schon vor OpnSense der Hauptgrund war, nur SLAAC zu machen. Ich nutze IPv6 schon sehr lange und anfangs konnten die meisten Clients DHCPv6 noch gar nicht. Der Vorschlag von Cyberturtle, auf jeden Fall ein RA von 0 zu machen, wenn sich der Präfix ändert, kann m.E. nicht schaden (außer, wenn sich der Präfix NICHT ändert). Ich nehme an, das war der Grund für AVM, das so zu machen.
Was ich aber nicht wirklich weiß und aktuell eben auch dank statischer IPv6 Präfixe nicht ausprobieren kann, ist, ob man den RADVD zu diesem Verhalten bringen kann. Ich glaube nämlich, dass der bei Beendigung keinen RA 0 schickt und auch durch andere Signale oder bei Präfix-Änderungen immer nur den aktuellsten Präfix schickt.
Die Verkürzung der Lifetime darf man m.W. auch nicht zu weit treiben, da gibt es Minimalwerte für manche Parameter. Als ich vor kurzem mal mit den advanced Werten gespielt habe, war mein IPv6 prompt gestört.
-
Ja, die Zeiten muss man im Blick behalten. AVM schickt das Zero RA auch mit ner ValidLifetime mit etwas mehr als 7200s, damit das Ganze gemäß RFC läuft.
Bei 6to4, wo bspw. die IPv4 ebenfalls dynamisch ist und sich noch die IPv6 Adresse davon ableitet, werden sogar sehr kurze RAs nebst kurzen Lifetimes empfohlen. Da ist’s letztlich egal, ob ein alter Prefix bis um Ende seiner Laufzeit läuft, wenn er eh nur 300s mit Gültigkeit verschickt wird. Das habe ich auch hier mal getestet und lief auch vielversprechend.
Gleichzeitig muss man dann RDNSS (Max. 2-3x Max interval) im Blick behalten.
Ich habe bei mir auch nur Unmanged ohne DHCPv6 fürs LAN.
-
Ich glaube wir sind hier etwas zu weit von der Realität im Code entfernt.
Fakten die wir in 23.1.x gelernt haben:
radvd SIGHUP sendet kein Zero Lifetime RA für den Prefix, ein Neustart des Daemons aber schon (bzw. der Exit).
SIGHUP hatten wir ja in 23.1.4 eingeführt und hat nicht richtig funktioniert wegen anderen radvd Problem. in 23.1.5 wurde das dann gelöst.
Nur SIGHUP war aber nicht praktikabel weil der Prefix nicht verschwindet. Dann wurde in 23.1.7 nachgebessert:
o dhcp: restart radvd on config changes, otherwise keep SIGHUP
Ich denke das funktioniert auch jetzt sinnvoll und hat früher schon so funktioniert. 23.1.4 bis 23.1.6 waren da ungeeignet, vielleicht waren das auch genau die Versionen die hier vordergründig angeschaut wurden.
Jetzt kommt aber noch die Ausnahme: DeprecatePrefix darf nicht auf "off" stehen. Das muss es aber z.B. im CARP Setup (Source Address mit CARP VIP). Das muss im Einzelfall beachtet werden weil dann die Grundvoraussetzung nicht gegeben ist.
Grüsse
Franco
-
PS: DHCPv6 im LAN macht hautsächlich für Downstream-Router Sinn, v.a. wenn man einen Prefix delegieren will. Da gehe ich mit. Im WAN Bereich sind wir aber auf DHCPv6 als Client angewiesen aus bekannten Gründen. :)
-
Mal ganz doof gefragt: was macht denn der Mitbewerber mit dem N im Namen mit der Plus-Version anders? Dort musste ich jedenfalls nicht die Zeiten im RA anpassen und es hat sich für mich wie die Fritzbox verhalten, wenn's ne neue Verbindung gab oder neue Präfixe. Dafür lief mir zu viel anderes nicht (MTU-Probleme, Shaper etc.).
Dort waren die Standardzeiten fürs Lease mit teilweise 86400 und 14400 Sekunden konfiguriert. Ich hab's seinerzeit leider nicht mitgeschnitten, ob da nen Deprecate mit Zero Lifetime rumgeschickt wird.
Nach den ganzen Patches, die mit 23.1.8 jetzt gekommen sind, sollte ich hier auch mal auf die Standardzeiten stellen oder versprecht ihr euch davon weniger?
Beste Grüße
Cyberturtle
-
Heute standen meine Interfaces leider wieder auf track6. :-(
Im Log finde ich auch keine Infos zu einem Renew oder force.
Edit: Gerade half auch kein reconnect oder sowas. Ich musste tatsächlich den Router neustarten, damit die Geräte wieder mit IPv6 versorgt wurden. Irgendwas scheint da noch nicht ganz zu passen und ich weiß nicht was. Ich habe nun auch mal wieder "Prevent release" aktiviert. Sollte ich das Gateway Monitoring für IPv6 auch mal aktivieren?
Edit2: Im Log stand tatsächlich doch etwas. dhcp6c_script: RELEASE on pppoe0 executing kurz nach dem Neuaufbau der Verbindung. Ich hatte vor 23.1.8. auch Prevent Release aktiv. Es scheint wohl irgendwie das Häkchen abhanden gekommen zu sein. Kann das mit dem track6 daran liegen? Evtl. hat der ISP auf das RELEASE reagiert und dann hat sich keine neue IPv6 Adresse zuweisen lassen?
-
Ohne dhcp6 (debug) Logs kann man da nichts sagen. Und https://github.com/opnsense/dhcp6c/commit/555bdcdef is ja auch noch offen...
Grüsse
Franco
-
Hey Franco,
wie wäre deine Empfehlung mit der 23.1.9 in Kombination „prevent Release“ zu testen?
Habe mich heute sehr über die Ankündigung der 23.1.9 gefreut (im RSS Feed).
Beste Grüße
-
Prevent release aus, auf die 23.1.9 rauf und Reboot. Wenn es immer noch nicht klappt prevent release wieder rein.
Grüsse
Franco
-
Bislang ist das Problem nicht wieder aufgetaucht, wenngleich es auch keinen Reconnect gab. Insgesamt scheint die Version 23.1.9 hervorragend zu laufen. In den Logs stehen auch regelmäßige Einträge mit "RENEW on pppoe0 executing" und das ganze scheint erfolgreich zu laufen.
Ich glaube, die Version 23.1.8 und .9 waren ein wichtiger Schritt in Sachen IPv6.
Ein kleiner (wohl aber doch eher großer) Schritt für die Devs und ein großer Schritt für die IPv6-User. :)
-
Ok, prima. Die eine Änderung mit der falschen WAN Adresse im rc.newwanipv6 Skript ist noch nicht drin. Noch nicht ganz durch die QA wegen weiteren Problemchen hier, aber kommt noch.
Danke
Franco
-
Hallo zusammen,
vergangene Nacht war es mal wieder soweit. Die Vermittlungsstelle hat Updates eingespielt und es kam zu einem Reconnect. Heute morgen hatte ich mich schon gefreut, dass sämtliche Interfaces eine neue IPv6-Adresse bekommen haben, also die Präfix-Aktualisierung hat geklappt. Allerdings bekommt keiner meiner Clients mehr eine IPv6-Adresse zugewiesen. Selbstverständlich ist die 23.1.11 installiert. In den Logs ist mir nur aufgefallen, dass der von Dir erwähnte Fix wegen QA noch nicht drin ist. Ich vermute dort allerdings nicht die Lösung. Nach dem Verbindungsverlust wurde SIGHUP am dhcp6c 2x ausgeführt und es sind auch die RENEWs dabei. Via UI und CLI sind auf dem igc0, igc2 und pppoe0 IPv6-Adressen zugewiesen. Kann sich der RA evtl. aufgehängt haben? Und wie kann ich das prüfen?
Viele Grüße
Cyberturtle
Edit: In den Logs ist mir noch was aufgefallen:
<12>1 2023-07-18T02:19:11+02:00 OPNsense.localdomain opnsense 50995 - [meta sequenceId="28"] /usr/local/etc/rc.newwanipv6: dhcpd_radvd_configure(manual) found no suitable IPv6 address on igc0
<12>1 2023-07-18T02:19:11+02:00 OPNsense.localdomain opnsense 50995 - [meta sequenceId="31"] /usr/local/etc/rc.newwanipv6: dhcpd_radvd_configure(manual) found no suitable IPv6 address on igc2
<13>1 2023-07-18T02:19:10+02:00 OPNsense.localdomain dhcp6c 53757 - [meta sequenceId="23"] dhcp6c_script: REQUEST on pppoe0 executing
<13>1 2023-07-18T02:19:10+02:00 OPNsense.localdomain dhcp6c 54765 - [meta sequenceId="24"] dhcp6c_script: REQUEST on pppoe0 renewal
Edit2: RADVD scheint sich aufgehängt zu haben. Ich habe ihn gerade neugestartet und der vergangene Nacht zugewiesene Präfix wird nun auch verteilt. Wäre es evtl. sinnvoll noch einen RADVD Restart einzubauen, wenn es zum RENEW mit Change kommt? Vielleicht könnte man ja zur Sicherheit ja neustarten, dann ca. 10 Minuten noch die alten Präfixe mit Deprecate verteilen und gleichzeitig auch den neuen?
-
Hallo zusammen,
ich weiß, dass es zu keinem Guten Ton in den Foren gehört, die "alten Leichen" wieder aus der Vergessenheit zu holen, dennoch frage ich trotzdem:
Ist das Problem inzwischen gelöst oder besteht es immer noch? Die Diskussion hier ruht leider seit Mitte letzten Jahres. Allerdings gab es auch keine abschließende Meldung "Ja, es läuft und ist bereits im Release drin", oder "Nein, es hat nichts gebracht, alles im Sande verlaufen".
Beim verlinkten Issue auf Github ist auch Ruhe seit Mitte letzten Jahres mit dem einzigen WorkArround, OPNsense doch jede Nacht per cron zu rebooten.
Ist es denn wirklich die einzig funktionierende Lösung derzeit?
Ich frage hier, da ich derzeit solche Probleme bei mir beobachte. Bevor ich aber hier lange Romane schreibe und meine komplette Konfiguration und Screenshots poste, wollte ich zunächst algemein fragen, ob das Problem denn generell immer noch besteht oder ob es vielleicht an mir liegt.
Danke!
-
Hallo august,
ich kann dir leider nicht sagen, ob das Problem abschließend behoben ist. Am Ende wurde es bei mir durch die neueren Versionen zwar besser, ich hatte allerdings keine Zeit das weiter zu beobachten und ggf. zu fixen, da ich aus beruflichen Gründen eine verlässliche Lösung akut benötigt hatte. Ich habe meine alte Fritzbox als Übergangslösung genommen - diese läuft unauffällig. In einigen Punkten fehlt mir OPNsense schon, gleichzeitig hatte ich einfach nicht mehr die Zeit fürs Troubleshooting.
Vielleicht haben andere ja noch neue Erkenntnisse dazugewonnen?
Viele Grüße
-
Ich habe bei mir (DG, Sense direkt am ONT) seit geraumer Zeit keine Probleme mehr.
Anfangs hatte es nach einem Reboot, etc. mal einige Minuten gedauert, bis ich wieder v6 Adressen hatte, mittlerweile (seit etwa 2022?) ist sofort alles da. Mein Präfix ändert sich allerdings auch nie (ist aber auch nicht statisch)...
-
Nun melde ich mich heute wieder, weil dieses Scheiß-Problem nun wieder aufgetreten ist und ich nach mehr als einem Monat schon vergessen habe, welche von den vielen Handlungen mich damals doch dazu gebracht hat, dass es nun wieder lief.
Was war nun heute passiert. Ich habe heute ein größeres msata-SSD-Speicher in mein APU4D4 (das ist die Hardware von OPNsense) installiert. Denn die empfohlenen 16GB (wer auch immer diese Empfehlungen immer macht) natürlich relativ knapp bemessen waren. Update erfolgte so, dass ich alle Einstellungen von OPNsense gesichert habe und dann mein APU4D4 auf dem neuen msata-SSD-Speicher neu aufgesetzt habe. Anschließend zurückspielen aller Einstellungen und da war es wieder "No available address range for configured interface subnet size." unter allen Services->ISC DHCPv6->LAN (und anderen) zu vermelden.
Alles Erdenkliche danach ausprobiert: De Fritz!Box, die als DSL-Gateway dient neu gestartet, OPNSense neu gestartet. Netzwerkkabel am WAN getrennt und nach einer Weile wieder eingesteckt (müsste normalerweise zur Deaktivierung des WAN-Interfaces und dann wieder zum Hochfahren dessen führen) usw. Und? Nichts da! Fehler bleibt bestehen!
Ich denke langsam, dass OPNsense immer noch einen Wurm in der Logik der Detetkierungs-Skripten für Tracking hat! Auch wie letztes Mal, wo ich die Fritz!Box an DSL getauscht hatte war diesmal keine Handlung, die jeden Tag auftritt. Bloß, das Umstellen aller Interfaces wieder auf was anderes als Tracking und dann wieder alles von vorne manuell Einrichten, was überall als einzig mögliche "Heilung" berichtet wird ist doch auch keine Lösung!
Ich wäre bereit es zu debuggen, bloß was und wo genau soll ich nachschauen. Damals hatte es mich auch schon einen halben Tag gekostet, in den Tiefen den Einstellungen rumzufummeln. Heute läuft es auf das Gleiche aus!
Meine Persönliche Vermutung: Die Logik in den Detektierungsskripten zur Erneuerung der deligierten IPV6-Adresse bei OPNsense ist buggy. In bestimmten Fällen, die ich leider nicht näher eingrenzen kann, führt dies dazu, dass die Adresse nicht erneuert wird. Ich hatte da in irgendwelchen Logs schon letztes Mal gesehen, dass da eine lokale "fe80"-Adresse entweder als "alte" oder als "neue" oder als beides auftauchte. Dass eine lokale "fe80"-Adresse sich nicht ändert ist ja logisch und führt meines Erachtens dazu, dass dort keine Änderung detektiert wird. Vermutlich gerät die Detektierung außer tritt und verfällt in diesem "fe80"-Modus, wenn man beim bereits vollständig eingerichteten OPNsense was ändert, wie beispielweise die Fritz!Box am DSL-Anschluss oder neu aufsetzen vom System. In dem Falle werden irgendwelche Initialisierungsoperationen vermutlich weg gelassen (durch die fehlerhafte Logik), die normalerweise beim Neueinrichten der Tracking-Interfaces durchgeführt werden. Und schon hat man den Salat, von dem sehr viele berichten. Das würde die "Heilung" durch das Reseten all der getrackten Interfaces auf was anderes als Tracking und dann das manuelle Neueinrichten erklären.
Wie gesagt, ich würde es gerne debuggen, bloß wo sind all diese Skripte, dass man die zunächst mal zumindest reviewen kann?
Edit: Eine neue Erkenntnis nach mehreren Stunden des Rumprobierens: Bei mir wird einer der deligierten Präfixen im /58-Subnetz von der Fritz!Box angezeigt, die als DSL-Gateway dient. Bis jetzt habe ich dann bei OPNsense die "Prefix delegation size" auf 57 (also n-1) eingestellt, weil es in allen möglichen Anleitungen so beschrieben war, damit man diese "Delegation" per Tracking auf mehrere lokalen SubNetze aufteilen kann. Als 0x1, 0x2 usw. Nun habe ich aus lauter Verzweiflung (weil es mir schon wirklich nichts mehr blieb) 58 anstelle von 57 eingestellt (also nicht n-1, sondern n) und siehe da: alles hat sich wieder "repariert".
Ich glaube aber nicht, dass es wirklich die Lösung ist, sondern tippe auf irgendwelche Nebeneffekte. Denn mit "n-1" hat für mich in all den Anleitungen als logisch angehört. Warum es jetzt mit "n" als dieselbe Präfixlänge, wie bei der Fritz!Box funktioniert, ist mir ein Rätsel. Ich beobachte es weiter.
-
> Edit: Eine neue Erkenntnis nach mehreren Stunden des Rumprobierens: Bei mir wird einer der deligierten Präfixen im /58-Subnetz von der Fritz!Box angezeigt, die als DSL-Gateway dient. Bis jetzt habe ich dann bei OPNsense die "Prefix delegation size" auf 57 (also n-1) eingestellt,
Könntest du das ggf. nochmals erläutern was da wo stand? Für mich liest sich das nach "in der Fritzbox steht ich habe ein /58er Prefix" und du hast dann ein /57 delegiert - was dann natürlich Unfug ist, denn du kannst kein größeres Netz delegieren als dir zugeteilt wurde. Vielleicht verstehe ich dich falsch herum. Oder dein Provider hat die Delegation von /56 (was eigentlich normal für Endkunden sein sollte) auf /58 verkleinert um Adressen zu sparen (was kompletter BS ist) und deshalb hat die Zuweisung nicht mehr hingehauen?
Wie gesagt eine Vermutung weil ich den Absatz nicht 100%ig verstehe, aber wenn es so sein sollte wie ich es lese, ist es völlig klar, warum es kaputt gegangen ist, da du ein zu großes Netzsegment angefordert hast (/57) und die Fritte dir nur ein /58 zur Verfügung stellen konnte und daher die Anfrage abgelehnt hat. Normalerweise war es bei AVM meistens so, dass die Fritte nicht mehr als /58 /59 oder /60 delegieren konnte, evtl. ging auch mal /57. Das komplette /56er ging oftmals nicht, deshalb ist es meistens n+1 oder n+2 gewesen. Aber n-1 wäre mir neu.
Cheers :)
-
Ich bin z.B. nach der Anleitung https://docs.opnsense.org/manual/how-tos/ipv6_fb.html (https://docs.opnsense.org/manual/how-tos/ipv6_fb.html) vorgegangen. Ich glaube, es gab noch 2-3 weitere die ich gelesen hatte und die in eine ähnliche Richtung gehen. "n-1" meine ich in einer diesen Anleitungen so gesehen zu haben, aber definitiv nicht in der zitierten hier. Und wenn ich jetzt die zitierte Anleitung zum fünften Mal durchlese und genau auf diese "n+1" vs "n-1" Thematik achte, dann gebe ich dir Recht, dass dort "n+1" und nicht "n-1" gemeint ist. Aber eindeutig beschrieben und sofort zu verstehen ist es da in der Anleitung auf jeden Fall für mich nicht und daher sehr verwirrend. Insbesondere der Satz "In this example the FB gave us aaaa:bbbb:cccc:9410::/60", also "die Box gab uns /60" gab mir die falsche Botschaft: "wenn in der Box /60 steht, stell in der OPNsense /59", weil ja in der Anleitung IMMER und IMMER wieder zwischen diesem 59 und 60 gekaut wird, ohne eindeutig zu sagen "n+1" oder "n-1". Zweites Beispiel aus der Anleitung: "the requested prefix differs by one bit compared to what the ISP delegated the FB (60 vs. 59)". Liest für mich auch beim durchfliegen in DER REIHENFOLGE IN DEM SATZ so: "Der Provider gibt dir 60, dann stell 59 ein". Ja, ich gebe es zu, man muss es genau und vermutlich 5 Mal lesen. Ist vermutlich so was Ähnliches wie doppelte Verneinung im Deutschen. Aber sei es rum. Lass uns mal in den konkreten Beispielen reden:
Der Provider gibt mir /58. Das sehe ich in der Fritz!Box unter "Heimnetz->Netzwerk->IPv6-Adressen" als deligierte Adresse:
Verwendete IPv6 Präfixe:
Heimnetz 2a01:XXX:YYYY:1::/64
Gastnetz 2a01:XXX:YYYY:2::/64
WAN 2a01:XXX:YYYY::/64
Delegiert 2a01:XXX:YYYY:c0::/58
Delegiert 2a01:XXX:YYYY:bc::/62Es gibt dort noch eine weitere /62-Delegation, ich nutze aber die /58
Da ich es falsch mit n-1 verstanden hatte, stand bei mir unter OPNsense WAN als "Prefix delegation size" bis vor kurzem /57 eingestellt. Die Frage ist: Warum hat es dann trotzdem sporadisch funktioniert?
Nun steht bei mir jetzt unter OPNsense /58 und nicht mehr /57 und es scheint (warum auch immer) so zu gehen. Also n_OPNsense = n_FB.
Soll ich jetzt doch auf "n+1" umstellen, dass n_OPNsense = n_FB +1 ist? Also auf 59 in OPNsense, wenn mein Provider mir 58 (gesehen in der Fritz!Box) gibt?
Danke!
-
Hi zusammen, mit der aktuellen Version OPNsense 24.1.6-amd64 besteht das ursprünglich beschriebene Problem nach wie vor. Gibt es derzeit irgendwelche Workarounds?
-
An Workarounds wäre ich ebenfalls interessiert. Ich verwende aus diesem Grund seit vergangenen Sommer OPNsense nicht mehr, da meine Leitung halt gerne mal von ASSIA optimiert wird und es dann nachts zu einem Reconnect kommt. Für mich war da die Verlässlichkeit für mein VPN nicht mehr gegeben und ich hatte leider keine Zeit mehr für weitere Tests, wenngleich hier ja so einige Versionen mit Verbesserungen im Bereich IPv6 veröffentlicht wurden.
Ich frage mich wirklich, wie AVM das bspw. löst. Soweit ich mich erinnere, ging es auch mit pfSense Plus, allerdings gibt es das nicht mehr für den privaten Gebrauch und ich mag auch eher OPNsense unterstützen. :)
Könnte man nicht einfach nach einem PPPoE-Reconnect das Neustarten des IPv6-Interfaces triggern?
-
Meine oben gemeldeten Probleme lagen tatsächlich an der Missverständnis bzgl. Präfix-Delegation zwischen der Fritz!Box und der Opnsense bzw. besser gesagt dieser n+1 vs. n-1, je nachdem, wie man die Doku ließt und sie versteht. Seit März habe ich keine Probleme mehr. Die äußere IPV6-Adresse hat sich seither bereits ein Paar geändert, auch einige Updates von Opnsense mit entsprechenden Reboots von Opnsense habe ich auch bereits getätigt. Scheint alles stabil zu laufen.