PPPoE reconnect "verliert" IPv6 Adressen

[robgnu]

Hallo Zusammen,

ich habe bei mehreren OPNsense Installationen gelegentlich Probleme mit den IPv6 Adressen auf den internen Interfaces. Wenn die Internetverbindung, aus welchen Gründen auch immer, kurz unterbrochen wird, dann wird die PPPoE Verbindung sofort wieder aufgebaut. Manchmal erhalte ich jedoch auf den (V)LAN-Interfaces keine IPv6 Adresse mehr. Die (V)LAN-Interfaces stehen auf Track-Interface. Meistens funktioniert alles wie gewollt, jedoch manchmal auch nicht.

Die Probleme bestehen schon eine Weile, ich konnte sie teilweise bei OPNsense 20.1.x, 20.7.x und auch bei der aktuellen Version 21.1.x beobachten.
Durch einen Klick auf Reload unter "Interfaces -> Overview -> WAN" wird die Verbindung neu aufgebaut und i.d.R. stimmt dann wieder alles.

Netzwerkplan:
Telekom VDSL <-> Vigor 165 Modem <-> OPNsense <-> LAN/VLAN Interfaces

Da ich eine ähnliche Konfiguration bei verschiedenen Installationen beobachtet habe und auch im Forum gelegentlich nachgefragt wird, wollte ich mich hier an dieser Stelle auch noch mal melden um dem (lästigen) Problem auf die Spur zu kommen. Wenn sich die OPNsense hinter einer FRITZ!Box befindet, dann gibt es solche Probleme nicht. Die Prefix-Delegation der FRITZ!Box scheint einwandfrei zu funktionieren.

Meine bisherigen Lösungsversuche:

1. Ich würde gerne mit Monit überwachen, ob die Interfaces eine IPv6 Adresse haben. Der Check wäre mit einem Ping möglich, jedoch fehlt mir der Shell-Befehl um PPPoE neu verbinden zu lassen. Meine Suche hier im Forum war nicht erfolgreich. Daher die Frage: Kann man die PPPoe Verbindung mit einem Shell-Befehl neu aufbauen? (Reload-Button)

2. Ich besitze Log-Dateien von einem "fehlerhaften" Verbindungsaufbau (LAN Interfaces ohne IPv6 Adresse) und von einem "erfolgreichen" Verbindungsaufbau (LAN Interfaces mit IPv6 Adresse) - leider werde ich daraus nicht schlau.

3. Das VLAN-Tagging bei VDSL habe ich über die OPNsense sowie über das Vigor-Modem versucht. Es gibt keine Unterschiede.

Bisher überwache ich mit einem externen Monit die internen Interfaces per Ping-Check. Sobald der Check Alarm schlägt, logge ich mich in die entsprechende OPNsense ein und führe einen Reconnect aus. Das nervt und sollte doch irgendwie lösbar sein.

Vielleicht kann jemand helfen?

Gruß
Robert

[tiermutter]

Moin, ist das nicht die "heiße" Diskussion im englischen Forum?
https://forum.opnsense.org/index.php?topic=21506.0

Dafür wurde kürzlich ein Fix erstellt.

[robgnu]

Moin,
ich glaube, dass es hier evtl. ein anderes Problem ist. Auf dem WAN Interface läuft IPv6 sauber. Es sind nur die (V)LAN Interfaces, bei denen IPv6 verloren geht. Ich kann aber nicht ausschließen, dass das evtl. zusammen hängt.

Gruß

[computeralex92]

Hallo,

auch wenn dieser Thread schon "etwas" älter ist, wollte ich fragen, ob du eine finale Lösung für das Problem gefunden hast?

Vielen Dank,
Alex

[robgnu]

Hallo Zusammen,

ich hatte in den letzten Monaten mit diesem Problem kaum zu kämpfen, jedoch ist es in den letzten Tagen wieder vermehrt aufgekommen. Leider konnte ich noch keine Logs "besorgen". Das werde ich aber versuchen demnächst nachzuholen.

Das Problem kann ich derzeit so beschreiben: Aus irgend einem Grund wird die PPPoE Verbindung getrennt und dann neu aufgebaut. (OPNsense macht VLAN 7). Die Verbindung steht mit IPv4 einwandfrei und bei IPv6 erhält das WAN Interface eine Adresse. Alle LAN und VLAN Interfaces sind auf "Track Interface" konfiguriert. Im Dashboard steht anstelle der IPv6 Adresse nur "track6". DHCPv6 wird im LAN ganz bewusst nicht verwendet. Radvd ist auf "Unmanaged" konfiguriert. Das funktioniert bei über 20 Installationen einwandfrei. Da das LAN-Interface keine IPv6 bekommt, bekommen auch die Clients keine IPv6 Adresse mehr.

Die Probleme tauchen seit Monaten bei verschiedenen OPNsense Versionen (>20.1 / 20.7 / 21.1 / 21.7) auf. Ich habe das soweit beobachten können, dass es mal Wochen/Monate lang läuft und dann taucht das Problem der Reihe nach bei vielen Installationen auf. Als ob die Telekom ihre DSLAMS aktualisiert und dadurch die Verbindungen "anders" getrennt werden als gewöhnlich.

Da ich einige Dienste auf "IPv6 only" betreibe ist das ziemlich ärgerlich, denn diese sind dann einfach offline.

Sobald ich Logs habe, werde ich diese hier posten.

Gruß
Robert

ps. Ich würde das gerne per Monit überwachen, leider fehlt mir noch der "Befehl", wie ich per Monit einen PPPoe Reconnect hinbekomme...

[NKnusperer]

Konntest du das Problem lösen @robgnu?
Ich beobachte aktuell genau das selbe verhalten mit der 22.7.6 an einem Telekom Anschluss.

[bringha]

Hallo zusammen,

seit letzter Woche beobachte ich auch auf meinem Telekom Anschluss (Magenta XL) dieses Verhalten mit IPv6. Bei mir hängt dies wohl damit zusammen, dass aktuell jede Nacht zwischen 3 und 4 Uhr (typisches Wartungsfenster der Telekom) eine netzseitige Zwangstrennnung erfolgt.

Wahrscheinlich gab es kürzlich ein Software Update oder ein Profilupdate für (das) DSL Leitungsbündel; danach wird häufig für einige Tage bis wenige Wochen regelmäßig getrennt, damit die Optimierungssoftware ASSIA das für das jeweilige Leitungsbündel optimale Profil finden und einrichten kann. So etwas kann zB auch dann vorkommen, wenn auf einem Leitungsbündel neue Anschlüsse geschaltet werden oder Baumaßnahmen durchgeführt wurden.

Unabhängig davon ist die Frage, wie die Opnsense damit klarkommt. Bei mir ist nicht nur das Thema IPv6, was so ca jedes 2. - 3. Mal nicht funktioniert, sondern der Dyndns update findet ebenfalls häufig nicht statt.

In den Logs sieht das dann zumeist so aus:

Code Select Expand


(...)
<13>1 2022-10-14T03:33:06+02:00 OPNsense.zuhause.xx opnsense 86316 - [meta sequenceId="130"] plugins_configure dhcp (,inet6)
<13>1 2022-10-14T03:33:06+02:00 OPNsense.zuhause.xx opnsense 86316 - [meta sequenceId="131"] plugins_configure dhcp (execute task : dhcpd_dhcp_configure(,inet6))
<13>1 2022-10-14T03:33:06+02:00 OPNsense.zuhause.xx dhcp6c 23613 - [meta sequenceId="132"] dhcp6c REQUEST on pppoe0 - running newipv6
<11>1 2022-10-14T03:33:07+02:00 OPNsense.zuhause.xx opnsense 30975 - [meta sequenceId="133"] /usr/local/etc/rc.newwanipv6: IPv6 renewal is starting on 'pppoe0'
<11>1 2022-10-14T03:33:07+02:00 OPNsense.zuhause.xx opnsense 30975 - [meta sequenceId="134"] /usr/local/etc/rc.newwanipv6: On (IP address: 2003:f8:XX:XX:XX....) (interface: WAN[wan]) (real i
nterface: pppoe0).
(.... 100 te Male hintereinander)


Für Dyndns Update startet es mit der Fehlermeldung:

Code Select Expand


<11>1 2022-10-14T03:30:19+02:00 OPNsense.zuhause.xx opnsense 19307 - [meta sequenceId="1"] /usr/local/etc/rc.dyndns: Curl error occurred: Resolving timed out after 15010 milliseconds
<13>1 2022-10-14T03:30:33+02:00 OPNsense.zuhause.xx opnsense 37711 - [meta sequenceId="2"] plugins_configure dns_reload (1)
<13>1 2022-10-14T03:30:33+02:00 OPNsense.zuhause.xx opnsense 37711 - [meta sequenceId="3"] plugins_configure dns_reload (execute task : system_resolvconf_generate(1))
<13>1 2022-10-14T03:30:33+02:00 OPNsense.zuhause.xx opnsense 58583 - [meta sequenceId="4"] plugins_configure dns_reload (1)
<13>1 2022-10-14T03:30:33+02:00 OPNsense.zuhause.xx opnsense 58583 - [meta sequenceId="5"] plugins_configure dns_reload (execute task : system_resolvconf_generate(1))
<13>1 2022-10-14T03:30:33+02:00 OPNsense.zuhause.xx opnsense 37711 - [meta sequenceId="6"] plugins_configure dns_reload (execute task : system_hosts_generate(1))
<13>1 2022-10-14T03:30:34+02:00 OPNsense.zuhause.xx opnsense 58583 - [meta sequenceId="7"] plugins_configure dns_reload (execute task : system_hosts_generate(1))
<11>1 2022-10-14T03:30:39+02:00 OPNsense.zuhause.xx opnsense 25399 - [meta sequenceId="8"] /usr/local/etc/rc.dyndns: Curl error occurred: Resolving timed out after 15004 milliseconds
<27>1 2022-10-14T03:30:44+02:00 OPNsense.zuhause.xx dhcp6c 28537 - [meta sequenceId="9"] transmit failed: Can't assign requested address
<27>1 2022-10-14T03:31:23+02:00 OPNsense.zuhause.xx dhcp6c 28537 - [meta sequenceId="10"] transmit failed: Can't assign requested address
<27>1 2022-10-14T03:31:29+02:00 OPNsense.zuhause.xx dhcp6c 28537 - [meta sequenceId="11"] transmit failed: Can't assign requested address
<27>1 2022-10-14T03:32:40+02:00 OPNsense.zuhause.xx dhcp6c 28537 - [meta sequenceId="1"] transmit failed: Can't assign requested address
<11>1 2022-10-14T03:32:47+02:00 OPNsense.zuhause.xx opnsense 86228 - [meta sequenceId="2"] /usr/local/etc/rc.newwanip: IPv4 renewal is starting on 'pppoe0'
<11>1 2022-10-14T03:32:47+02:00 OPNsense.zuhause.xx opnsense 86228 - [meta sequenceId="3"] /usr/local/etc/rc.newwanip: On (IP address: 87.178.19.22) (interface: WAN[wan]) (real interface: pppoe0).
<11>1 2022-10-14T03:32:47+02:00 OPNsense.zuhause.xx opnsense 720 - [meta sequenceId="4"] /usr/local/etc/rc.newwanipv6: IPv6 renewal is starting on 'pppoe0'
<11>1 2022-10-14T03:32:47+02:00 OPNsense.zuhause.xx opnsense 720 - [meta sequenceId="5"] /usr/local/etc/rc.newwanipv6: Failed to detect IP for WAN[wan]
<13>1 2022-10-14T03:32:47+02:00 OPNsense.zuhause.xx dhcp6c 11057 - [meta sequenceId="6"] RTSOLD script - Sending SIGHUP to dhcp6c
<11>1 2022-10-14T03:32:47+02:00 OPNsense.zuhause.xx opnsense 86228 - [meta sequenceId="7"] /usr/local/etc/rc.newwanip: ROUTING: entering configure using 'wan'
<13>1 2022-10-14T03:32:48+02:00 OPNsense.zuhause.xx dhcp6c 17933 - [meta sequenceId="8"] RTSOLD script - Sending SIGHUP to dhcp6c
(...)
<11>1 2022-10-14T03:32:50+02:00 OPNsense.zuhause.xx php 86228 - [meta sequenceId="40"] /usr/local/etc/rc.newwanip: Curl error occurred: Could not resolve host: update.dedyn.io
(...)


und dann werden baw auch keine Updateversuche mehr unternommen.

Mal ist 'nur' kein IPv6, mal geht beides nicht, mal ist nur kein Dyndns update.

Lösung ist jedenfalls ein Client seitiges Neuverbinden, dann geht alles wieder (wurde ja auch schon so beschrieben)

Hoffen wir mal, dass bald wieder Ruhe herrscht und die Optimierung zügig abgeschlossen wird .... Ist so jedenfalls lästig

Br br

[robgnu]

Hallo,

eine richtige Lösung habe ich leider auch nicht. Bei >10 unserer Kunden, die OPNsense und Telekom in Kombination mit einem Vigor-Modem nutzen, läuft es absolut stabil und zuverlässig. Sehr selten gibt es mal den Fall, dass morgens in den Interfaces anstelle der IPv6 Adresse einfach nur "track6" steht. Ein Neuverbinden löst dann das Problem. Da stimmt bei der OPNsense mMn etwas nicht. Leider weiß ich nicht, wie ich der Lösung näher kommen soll - es passiert ja nur sehr selten und wenn es passiert, muss es schnell wieder gehen.

Bei einem einzigen unserer Kunden gibt es fast täglich zwischen 3 und 4 Uhr eine Neuverbindung. Die OPNsense verliert dabei jedes mal die IPv6 Adressen im LAN, ist aber weiterhin über WAN/IPv6 erreichbar, während das LAN IPv6-technisch offline ist. Das Log ist voller Fehlermeldungen, die für mich nicht zu deuten sind. Denn auch wenn alles perfekt läuft, finden sich viele Fehlermeldungen im Log. Ein Neuverbinden reicht hier nicht aus, ich muss die ganze Firewall neu starten. Meist geht es dann wieder.

Insgesamt scheint IPv6 immer noch schwierig zu sein, obwohl es so alt und auch so wichtig ist.  :(

Gruß
Robert

[robgnu]

Guten Morgen,

heute Nacht gab es mal wieder das "track6" Problem. Das Neuverbinden hat dazu geführt, dass die IPv6 Verbindung komplett weg war. Ein "Reconnect" unter Interfaces / Overview / WAN hat die Verbindung wieder ordentlich aufgebaut.

Hier das Log:

2022-10-19T03:24:29 Error   opnsense    /usr/local/etc/rc.newwanipv6: Warning! dhcpd_radvd_configure(manual) found no suitable IPv6 address on vlan01
2022-10-19T03:24:29 Error   opnsense    /usr/local/etc/rc.newwanipv6: Warning! dhcpd_radvd_configure(manual) found no suitable IPv6 address on igb2
2022-10-19T03:24:29 Error   opnsense    /usr/local/etc/rc.newwanipv6: Warning! dhcpd_radvd_configure(manual) found no suitable IPv6 address on igb0
2022-10-19T03:24:29 Error   opnsense    /usr/local/etc/rc.newwanipv6: On (IP address: 2003:a:XXXX:XXXX:de58:bcff:fee0:3170) (interface: WAN[wan]) (real interface: pppoe0).
2022-10-19T03:24:28 Error   opnsense    /usr/local/etc/rc.newwanipv6: IPv6 renewal is starting on 'pppoe0'
2022-10-19T03:24:28 Error   php /usr/local/etc/rc.newwanip: Resyncing OpenVPN instances for interface WAN.
2022-10-19T03:24:26 Error   opnsense    /usr/local/etc/rc.newwanip: The WAN_PPPOE monitor address is empty, skipping.
2022-10-19T03:24:26 Error   opnsense    /usr/local/etc/rc.newwanipv6: Failed to detect IP for WAN[wan]
2022-10-19T03:24:26 Error   opnsense    /usr/local/etc/rc.newwanipv6: IPv6 renewal is starting on 'pppoe0'
2022-10-19T03:24:26 Error   opnsense    /usr/local/etc/rc.newwanip: The WAN_DHCP6 monitor address is empty, skipping.
2022-10-19T03:24:26 Error   opnsense    /usr/local/etc/rc.newwanip: ROUTING: keeping current default gateway 'fe80::200:ff:fe00:0%pppoe0'
2022-10-19T03:24:26 Error   opnsense    /usr/local/etc/rc.newwanip: ROUTING: setting IPv6 default route to fe80::200:ff:fe00:0
2022-10-19T03:24:26 Error   opnsense    /usr/local/etc/rc.newwanip: ROUTING: IPv6 default gateway set to wan
2022-10-19T03:24:26 Error   opnsense    /usr/local/etc/rc.newwanip: ROUTING: keeping current default gateway '62.156.244.3'
2022-10-19T03:24:26 Error   opnsense    /usr/local/etc/rc.newwanip: ROUTING: setting IPv4 default route to 62.156.244.3
2022-10-19T03:24:26 Error   opnsense    /usr/local/etc/rc.newwanip: ROUTING: IPv4 default gateway set to wan
2022-10-19T03:24:26 Error   opnsense    /usr/local/etc/rc.newwanip: ROUTING: entering configure using 'wan'
2022-10-19T03:24:26 Error   opnsense    /usr/local/etc/rc.newwanip: On (IP address: XX.XXX.178.69) (interface: WAN[wan]) (real interface: pppoe0).
2022-10-19T03:24:26 Error   opnsense    /usr/local/etc/rc.newwanip: IPv4 renewal is starting on 'pppoe0'

Gruß
Robert

[Nano]

Hallo zusammen,

bei mir genau das selbe. Über Nacht (3 Uhr) kommt scheinbar ein reconnect. IPv4 kein Problem, aber das IPv6 Subnetz was ich normalerweise zugewiesen bekomme, kommt nicht mehr mit.
Bin mir unsicher ob ich die alte IPv6 Adresse auf der WAN Schnittstelle behalte oder eine neue bekomme.
Nach einem reconnect der PPPoE Verbindung bekomme ich ein Subnetz und alles läuft wieder.
Jemand eine Lösung gefunden oder eine Idee?

Habe mal mein Log angehängt.
Nur die Einträge fürs DynDNS sind entfernt.

2022-12-21T03:18:43   Notice   opnsense   plugins_configure newwanip (execute task : webgui_configure_do(,wan))   
2022-12-21T03:18:43   Notice   opnsense   plugins_configure newwanip (execute task : vxlan_configure_do())   
2022-12-21T03:18:43   Notice   opnsense   plugins_configure newwanip (execute task : unbound_configure_do(,wan))   
2022-12-21T03:18:43   Notice   opnsense   plugins_configure newwanip (execute task : openssh_configure_do(,wan))   
2022-12-21T03:18:43   Notice   opnsense   plugins_configure newwanip (execute task : opendns_configure_do())   
2022-12-21T03:18:43   Notice   opnsense   plugins_configure newwanip (execute task : ntpd_configure_do())   
2022-12-21T03:18:41   Error   opnsense   /usr/local/etc/rc.newwanipv6: Dynamic DNS: updatedns() starting   
2022-12-21T03:18:41   Notice   opnsense   plugins_configure newwanip (execute task : dyndns_configure_do(,wan))   
2022-12-21T03:18:41   Notice   opnsense   plugins_configure newwanip (execute task : dnsmasq_configure_do())   
2022-12-21T03:18:41   Notice   opnsense   plugins_configure newwanip (,wan)   
2022-12-21T03:18:40   Error   opnsense   /usr/local/etc/rc.newwanipv6: OpenVPN server 1 instance started on PID 44721.   
2022-12-21T03:18:40   Error   opnsense   /usr/local/etc/rc.newwanip: Interface '' (ovpns1) is disabled or empty, nothing to do.   
2022-12-21T03:18:40   Error   opnsense   /usr/local/etc/rc.newwanip: IPv4 renewal is starting on 'ovpns1'   
2022-12-21T03:18:40   Error   opnsense   /usr/local/etc/rc.newwanipv6: The command '/sbin/route -q delete 10.10.0.1' returned exit code '1', the output was 'route: route has not been found'   
2022-12-21T03:18:40   Error   opnsense   /usr/local/etc/rc.newwanipv6: Resyncing OpenVPN instances for interface WAN.   
2022-12-21T03:18:39   Error   opnsense   /usr/local/etc/rc.newwanipv6: The WAN_PPPOE monitor address is empty, skipping.   
2022-12-21T03:18:39   Notice   opnsense   plugins_configure monitor (execute task : dpinger_configure_do(,WAN_PPPOE))   
2022-12-21T03:18:39   Notice   opnsense   plugins_configure monitor (,WAN_PPPOE)   
2022-12-21T03:18:39   Error   opnsense   /usr/local/etc/rc.newwanipv6: The WAN_DHCP6 monitor address is empty, skipping.   
2022-12-21T03:18:39   Notice   opnsense   plugins_configure monitor (execute task : dpinger_configure_do(,WAN_DHCP6))   
2022-12-21T03:18:39   Notice   opnsense   plugins_configure monitor (,WAN_DHCP6)   
2022-12-21T03:18:39   Error   opnsense   /usr/local/etc/rc.newwanipv6: ROUTING: keeping current default gateway 'fe80::231:xxxx:xxxx:9f83%pppoe0'   
2022-12-21T03:18:39   Error   opnsense   /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv6 default route to fe80::231:xxxx:xxxx:9f83   
2022-12-21T03:18:39   Error   opnsense   /usr/local/etc/rc.newwanipv6: ROUTING: IPv6 default gateway set to wan   
2022-12-21T03:18:39   Error   opnsense   /usr/local/etc/rc.newwanipv6: ROUTING: keeping current default gateway '62.xxx.xxx.xxx'   
2022-12-21T03:18:39   Error   opnsense   /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv4 default route to 62.xxx.xxx.xxx   
2022-12-21T03:18:39   Error   opnsense   /usr/local/etc/rc.newwanipv6: ROUTING: IPv4 default gateway set to wan   
2022-12-21T03:18:39   Error   opnsense   /usr/local/etc/rc.newwanipv6: ROUTING: entering configure using 'wan'   
2022-12-21T03:18:39   Error   opnsense   /usr/local/etc/rc.newwanipv6: Warning! dhcpd_radvd_configure(auto) found no suitable IPv6 address on vtnet0   
2022-12-21T03:18:39   Error   opnsense   /usr/local/etc/rc.newwanipv6: Warning! dhcpd_radvd_configure(auto) found no suitable IPv6 address on vtnet2   
2022-12-21T03:18:34   Notice   opnsense   plugins_configure dns_reload (execute task : system_hosts_generate(1))   
2022-12-21T03:18:34   Notice   opnsense   plugins_configure dns_reload (execute task : system_resolvconf_generate(1))   
2022-12-21T03:18:34   Notice   opnsense   plugins_configure dns_reload (1)   
2022-12-21T03:18:34   Notice   dhcp6c   dhcp6c RELEASE on pppoe0 - running dns reload   
2022-12-21T03:18:32   Notice   opnsense   plugins_configure newwanip (execute task : webgui_configure_do(,wan))   
2022-12-21T03:18:32   Notice   opnsense   plugins_configure newwanip (execute task : vxlan_configure_do())   
2022-12-21T03:18:32   Notice   opnsense   plugins_configure newwanip (execute task : unbound_configure_do(,wan))   
2022-12-21T03:18:32   Notice   opnsense   plugins_configure newwanip (execute task : openssh_configure_do(,wan))   
2022-12-21T03:18:32   Notice   opnsense   plugins_configure newwanip (execute task : opendns_configure_do())   
2022-12-21T03:18:32   Notice   opnsense   plugins_configure newwanip (execute task : ntpd_configure_do())   
2022-12-21T03:18:31   Notice   opnsense   plugins_configure dhcp (execute task : dhcpd_dhcp_configure(,inet6))   
2022-12-21T03:18:31   Notice   opnsense   plugins_configure dhcp (,inet6)   
2022-12-21T03:18:31   Error   opnsense   /usr/local/etc/rc.newwanipv6: On (IP address: 2003:e4:xxxx:xxxx:xxxx:xxxx:8901:f7d5) (interface: WAN[wan]) (real interface: pppoe0).   
2022-12-21T03:18:31   Error   opnsense   /usr/local/etc/rc.newwanipv6: IPv6 renewal is starting on 'pppoe0'   
2022-12-21T03:18:31   Notice   dhcp6c   dhcp6c REQUEST on pppoe0 - running newipv6   
2022-12-21T03:18:29   Notice   opnsense   plugins_configure newwanip (execute task : dyndns_configure_do(,wan))   
2022-12-21T03:18:29   Notice   opnsense   plugins_configure newwanip (execute task : dnsmasq_configure_do())   
2022-12-21T03:18:29   Notice   opnsense   plugins_configure newwanip (,wan)   
2022-12-21T03:18:29   Error   dhcp6c   transmit failed: Can't assign requested address   
2022-12-21T03:18:28   Error   opnsense   /usr/local/etc/rc.newwanip: OpenVPN server 1 instance started on PID 54481.   
2022-12-21T03:18:28   Error   opnsense   /usr/local/etc/rc.newwanip: Interface '' (ovpns1) is disabled or empty, nothing to do.   
2022-12-21T03:18:28   Error   opnsense   /usr/local/etc/rc.newwanip: IPv4 renewal is starting on 'ovpns1'   
2022-12-21T03:18:28   Error   opnsense   /usr/local/etc/rc.newwanip: The command '/sbin/route -q delete 10.10.0.1' returned exit code '1', the output was 'route: route has not been found'   
2022-12-21T03:18:28   Error   opnsense   /usr/local/etc/rc.newwanip: Resyncing OpenVPN instances for interface WAN.   
2022-12-21T03:18:28   Error   opnsense   /usr/local/etc/rc.newwanip: IP address change detected, killing states of old ip 87.xxx.xxx.xxx   
2022-12-21T03:18:28   Notice   dhcp6c   RTSOLD script - Sending SIGHUP to dhcp6c   
2022-12-21T03:18:28   Error   opnsense   /usr/local/etc/rc.newwanip: The WAN_PPPOE monitor address is empty, skipping.   
2022-12-21T03:18:28   Notice   opnsense   plugins_configure monitor (execute task : dpinger_configure_do(,WAN_PPPOE))   
2022-12-21T03:18:28   Notice   opnsense   plugins_configure monitor (,WAN_PPPOE)   
2022-12-21T03:18:28   Error   opnsense   /usr/local/etc/rc.newwanipv6: Failed to detect IP for WAN[wan]   
2022-12-21T03:18:28   Error   opnsense   /usr/local/etc/rc.newwanip: The WAN_DHCP6 monitor address is empty, skipping.   
2022-12-21T03:18:28   Error   opnsense   /usr/local/etc/rc.newwanipv6: IPv6 renewal is starting on 'pppoe0'   
2022-12-21T03:18:28   Notice   opnsense   plugins_configure monitor (execute task : dpinger_configure_do(,WAN_DHCP6))   
2022-12-21T03:18:28   Notice   opnsense   plugins_configure monitor (,WAN_DHCP6)   
2022-12-21T03:18:28   Error   opnsense   /usr/local/etc/rc.newwanip: ROUTING: keeping current default gateway 'fe80::231:xxxx:xxxx:9f83%pppoe0'   
2022-12-21T03:18:28   Error   opnsense   /usr/local/etc/rc.newwanip: ROUTING: setting IPv6 default route to fe80::231:xxxx:xxxx:9f83   
2022-12-21T03:18:28   Error   opnsense   /usr/local/etc/rc.newwanip: ROUTING: IPv6 default gateway set to wan   
2022-12-21T03:18:28   Error   opnsense   /usr/local/etc/rc.newwanip: ROUTING: keeping current default gateway '62.xxx.xxx.xxx'   
2022-12-21T03:18:28   Error   opnsense   /usr/local/etc/rc.newwanip: ROUTING: setting IPv4 default route to 62.xxx.xxx.xxx   
2022-12-21T03:18:28   Error   opnsense   /usr/local/etc/rc.newwanip: ROUTING: IPv4 default gateway set to wan   
2022-12-21T03:18:28   Error   opnsense   /usr/local/etc/rc.newwanip: ROUTING: entering configure using 'wan'   
2022-12-21T03:18:28   Error   dhcp6c   transmit failed: Can't assign requested address   
2022-12-21T03:18:28   Notice   dhcp6c   RTSOLD script - Sending SIGHUP to dhcp6c   
2022-12-21T03:18:28   Error   opnsense   /usr/local/etc/rc.newwanip: On (IP address: 87.xxx.xxx.xxx) (interface: WAN[wan]) (real interface: pppoe0).   
2022-12-21T03:18:28   Error   opnsense   /usr/local/etc/rc.newwanip: IPv4 renewal is starting on 'pppoe0'   
2022-12-21T03:16:27   Notice   opnsense   plugins_configure dns_reload (execute task : system_hosts_generate(1))   
2022-12-21T03:16:27   Notice   opnsense   plugins_configure dns_reload (execute task : system_resolvconf_generate(1))   
2022-12-21T03:16:27   Notice   opnsense   plugins_configure dns_reload (1)   
2022-12-21T03:16:27   Notice   opnsense   plugins_configure dns_reload (execute task : system_hosts_generate(1))   
2022-12-21T03:16:27   Notice   opnsense   plugins_configure dns_reload (execute task : system_resolvconf_generate(1))   
2022-12-21T03:16:27   Notice   opnsense   plugins_configure dns_reload (1)

Liebe Grüße
Tobias

[weeßicknich]

Ich habe mit OPNsense 22.7.10_2 das selbe Problem und wir sind auch nicht allein: https://github.com/opnsense/core/issues/6223#issue-comment-box

[DerDanilo]

Ich habe mit OPNsense 22.7.10_2 das selbe Problem und wir sind auch nicht allein: https://github.com/opnsense/core/issues/6223#issue-comment-box

Habe einen längeren Post in das Github Issue geschrieben. Nerviges Thema und ich verstehe nicht warum für Jahre keine vernünftige Lösung für PPPoe Zwangstrennungen implementiert wird. Nahezu alle anderen Router haben dafür Funktionen eingebaut.
"PPPoe ist alt, wir bauen dazu nichts mehr bei OPNsense aus" funktioniert halt nicht wenn viele ISPs aber noch darauf aufbauen und dies selbst hinter ONTs für Fiber Anschlüsse noch verwenden. Das Ergibt kaum Sinn weil die ONTs eh alle mit deren MAC Adresse registriert und für den jeweiligen Kunden freigeschaltet werden müssen.

Hoffen wir mal dass sich hier etwas tut. Anbei der Beitrag (in Englisch) vom Issue:

Code Select Expand

We also have this problem with multiple setups. ONT --> PPPoe v4 and v6 suffix (/56) via DHCPv6--> OPNsense . We are also forced to reconnect once every 24h and receive a new IPv4 and v6 suffix.

To control when the reconnect should be triggered we setup a cron job to reset the PPPoe and WAN interface at 3 AM. IPv4 is no problem, but the IPv6 suffix is not requested by OPNsense during the interface reset.

Pressing the button "Reload" for DHCPv6 on the Interface Overview for PPPoe immediately requests a new /56 and v6 is working again.

The LAN interface tracking to receive a /64 out of the /56 suffix usually works fine if the PPPoe requests a new /56. Sometimes it also fails and either the interface has to be edited and saved of the FW has to be rebooted.

This leaves us with multiple problems:

    - complicated setup for pppoe forced reconnect control
    - DHCPv6 for pppoe not working properly
    - LAN tracking interface not always working
    - if DHCPv6 for the pppoe interface can be somehow controlled via cron there is about a minute between the pppoe v4 reconnect and the request for a new v6 suffix (& IP for FW if configured). During that time IPv6 does not work and all devices loose connections to v6 targets for more than a minute (until SLAAC or the local DHCPv6 server kicks in once the new suffix is received)

Why are there no options in the PPPoe configuration page to control when a forced reconnect should occure? I've read multiple threads regarding this isssue and I don't understand why it's not addressed properly? PPPoe is still common, even with fiber providers (for whatever reason). People are litterally switching to other (commercial) products because OPNsense (and apparently pfsense as well) is not handling this problem properly for years. This is very sad.

The following optional options in the pppoe config page make sense in my opinion:

"when to trigger post pppoe reconnect" (both option can be active at the same time):

    - force pppoe reconnect at MM:HH every day or via cronstyle schedule and trigger "post ppoe reconnect" tasks
    - watch pppoe v4 IP and trigger "post pppoe reconnect" when changed

The following option make not only sense when the reconnect is triggered but should be also be triggered when pppoe receives a new v4 address.

"post pppoe reconnect / new pppoe ip":
(order should be fixed since they depend on each other)

    - request a new IPv6 suffix (& IP for FW if configured) after pppoe is up again --> DHCP (client) reload
    - force configured v6 tracking LAN interfaces to track the new v6 suffix (to make sure it knows about the new suffix)
    - trigger SLAAC/radv restart (to make sure it knows about the new suffix)
    - trigger local DHCPv6 server restart (to make sure it knows about the new suffix)

Most of these options should be possible to implement quiet easy since nearby all actions are already possible somehow within the GUI. If there is a GUI option there is a command to be triggered via other means. The only one where I couldn't find a button for is to force the LAN interface tracking.

I hope that this somehow makes sense and that we have a solution at hand within version 23.x.



[awmst4]

Ich hätte zu dem Problem hier die folgenden Fragen:
Wenn dieses Problem auftritt, wird dann auch ein neues Präfix verteilt? Oder sind das alles Business DSL Anschlüsse mit fester IP / Präfix?
Wie ist der jeweilige Upstream DNS Konfiguriert? ist das immer der Telekom DNS oder habt ich was manuelles Konfiguriert?

Ich habe ein Draytek Modem mit der OPNsense und nicht anders Konfiguriert wie hier schon beschrieben.
Bei den (V)LAN`s Track Interface

Mögliche unterscheide:
Ich habe aber einen Business DSL Anschluss und eine feste IP / Präfix
Ich habe einen eigenen DNS eingetragen (und dem Provider das überschreiben verboten)
Ich habe es so eingestellt, dass das WAN Interface eine IPv6 Adresse bekommt und das Präfix (Nur Präfix beziehen ist abgewählt)
Die Priorität der beiden Gateways ist 255 für IPv4 und 254 für IPv6 ansonsten sind diese gleich Konfiguriert, wobei es "Far Gateway" für das IPv6 Gateway nicht gibt.
Ich habe bei den (V)LANS`s spielerischen gründen die Präfix ID etwas variiert, also nicht durchnummeriert (Ich nutze 04, 05, 08 und 0c)
Das VLAN Tagging macht bei mir das Draytek Modem

Müsste sich das Problem nicht lösen, wenn man per Cron den DHCPd einfach immer um 05 Uhr neu startet? dieser müsste dabei doch das ganze IPv6 incl. Präfix neu abrufen?
Steht, wenn die (V)LANS`s kein IPv6 mehr haben in Interfaces: Overview ein delegiertes Präfix oder ist das dann leer?

Ich habe hier zwar keine Zwangstrennung, aber ich habe beim Umstecken / Abstecken / Update - Reboot noch nie ein generelles Präfixproblem gehabt. Lediglich mit Androids (alle 24std), wenn der DNS über DoT oder DoH konfiguriert war. --> Deswegen die Frage nach den DNS

[DerDanilo]

Ich habe fälschlicherweise "suffix" anstelle von "prefix" geschrieben und damit Leute verwirrt.

Wir haben das Problem dass wir kein Prefix bekommen wenn es die PPPoe Zwangstrennung gibt bzw. wenn wir diese per Cron steuern. Wir erhalten dann keine IPv6 Adresse und auch kein IPv6 Prefix, in der Overview sind die entsprechenden Felder dann leer.

Wenn wir auf den Knopf "reload" drücken wird bei unseren Setups innerhalb von Sekunden ein neues v6 Prefix zugewiesen, die LAN Interfaces bekommen dies per Tracking idr. mit und SLAAC erledigt den Rest. Lediglich ein paar Android Geräte stellen sich ein wenig an das neue v6 LAN Prefix anzunehmen. WLAN trennen und neu verbinden hilft dabei. Habe allerdings hier noch nicht ausprobiert ob die sich das neue Prefix irgendwann später holen, es ging uns bisher erst einmal darum sicherzustellen dass wir überhaupt ein Prefix erhalten wenn der PPPoe Reconnect durchgeführt wird.

Bei Neustarts gibt es bisher auch keine Probleme, da wird scheinbar ein DHCPv6 Client Requests via PPPoe v4 abgesetzt und zugewiesen.

Wir haben hier dynamsiche IPs, da die meisten Kunden bei den hier vorhandenen Glasfasertarifen keinen Business Tarif benötigen. 600 Down, 200 Up für 40 Euro im Monat mit FTTH langt in er Regel.

Upstream DNS haben wir meistens auf 1.1.1.1 oder 8.8.8.8 und entsprechend deren v6 IPs gesetzt. Alle Setups haben allerdings sowieso noch andere lokale DNS Server (nicht OPNsense) konfiguriert, von daher sind die DNS Einstellungen bei uns nur bedingt wichtig.

Wir beziehen zusätzlich zu dem Prefix auch noch eine IPv6 für den Router, damit der direkte Zugriff auf diesen auch per v6 möglich ist (VPN usw.).

Die GWs werden von OPNsense automatisch über den PPPoe Connect konfiguriert.

Wir haben keine Unterschiede wenn wir andere LAN Prefixe vergeben, die LANs bekommen per Tracking ihr /64 wenn das Prefix beim PPPoe gesetzt wird.

VLAN tagging benötigen wir bei uns nicht, darum kümmern sich die ONTs bei unseren Setups.

Helfen diese Infos dir weiter?

[id3fix_]

Gleiches Problem auch bei mir. Allerdings etwas andere Voraussetzungen. Telekom DSL Business mit fester IPv4 und festem Prefix.
Opnsense WAN Schnittstelle auf DHCPv6 und einen Haken bei:
- Request only an IPv6 prefix
- Send IPv6 prefix hint
- Use IPv4 connectivity
Prefix delegation size steht auf 56.
LAN steht auf Track und das Router Advertisements für LAN:
- Unmanaged
- Priority high
- Advertise Default Gateway
- AdvDeprecatePrefix off (wegen statischem Prefix)
Mein Ansatz war jetzt folgender...
Opnsense generiert ganz viele Scripte selbst und erst zur Laufzeit. Wäre also quatsch hier was ändern zu wollen, weil ja auch nach einem Update alles wieder weg ist, bzw. sich die Scripte auch wieder selbst überschreiben.
Ich habe versucht das mit Monit zu lösen...
Es gibt eine Konfig-Datei für den RA Daemon -> /var/etc/radvd.conf und dort steht - wenn alles richtig gelaufen ist - das Prefix drin, dass man vom Provider bekommt.
Etliche reconnects später ist das dann auch irgend wann weg und dann funktioniert auch nichts mehr auf den Clients.
Hier habe ich versucht anzusetzen. Mein Check im Monit prüft nun auf das Prefix, wenn es nicht vorhanden ist muss der DHCPv6 getriggert werden.
Dazu habe ich folgendes probiert. Einfach die Datei /tmp/pppoe1_oldipv6 gelöscht und Opnsense versucht dann die ganze IPv6 Strecke neu aufzubauen. Wenn alles gut läuft ist der Prefix wieder da und alles ist prima...
Kann nur leider nicht immer wieder testen um zu schauen ob das auch dauerhaft funktioniert, weil eigentlich gibt es den reconnect bei Business Kunden nicht, nur leider ist meine Leitung so schlecht, dass ich hier ständig ungewollte Abbrüche habe. Wenn ich das aber selbst erzwingen will, z.B. durch einen restart vom Modem (Vigor 165), dann werde ich vom Verteiler immer weiter gedrosselt und dass kann ich dann nicht ewig machen...

Vielleicht ist das ja noch ein interessantes Thema für den ein oder anderen und kann hier mal selbst testen...
Wenn der Check für Monit interessant für jemanden ist, kann er sich ja hier melden und ich stelle das Script zur Verfügung...

PS: und nein, ich nutze den Telekom DNS nicht. Im RA Daemon kann man unter "DNS options" seine eigenen DNS Server für die Clients Konfigurieren...