IPv6 on Deutsche Telekom very unstable, PPPoE reload dyfunctional since 23.1

[franco]

You can try but I think it's missing the point of what causes this.


Cheers,
Franco

[sbellon]

Ok, right now, it's working - even though I am still unsure of whether "Request only an IPv6 prefix" is correct for Deutsche Telekom, or not (based on yesterday's thread discussion I now changed it to unticked and rebooted).

I'd like to continue this topic as soon as at some morning I see that IPv6 is gone. I'd like to extract state information and log files before I start messing with it.

I assume the messages from /var/log/system/latest.log with newwanipv6 are relevant. What else?

[Andi75]

Have you tried to restart the Router Advertisement service? Some minutes ago something similar happened to me. I lost my connection and after getting back online, all clients lost IPv6. After restarting the RA service they got their new GUA.

[sbellon]

But it's the "dhcpd6" service that is not running any more (and does not want to start). Are you suggesting that I have to restart "radvd" before I can try to restart "dhcpd6"?

[Andi75]

I did not run DHCPv6 to configure the clients. I'm only using radvd to do the stateless address auto-configuration. That's working great for me.

[mimugmail]

What puzzles me is this: @pmhausen says he has "Request only an IPv6 prefix" unticked, @bringha links to a thread where "Request only an IPv6 prefix" is ticked. @meyerguru says I should untick, @franco says it should stay ticked.

Surely there must be a definitive answer and not a 50:50 arm wrestling ... :-|

Maybe because DTAG doesnt do what you "request" and both might work To me tick the value works

[TheDJ]

To me, this once sounds like another incarnation of this issue: https://github.com/opnsense/core/issues/6223 (also discussed in https://forum.opnsense.org/index.php?topic=31443.0 and in German e.g. in https://forum.opnsense.org/index.php?topic=21682.msg124693#msg124693).

Currently, IPv6 prefix assigment in Dual Stack config from Deutsche Telekom seems (partially) broken, breaking all of the v6 connectivity afterwards. As I mention in the Github issue, unfortunately, I am not skilled enough to implement a solution. Currently I actually have v6 turned off for my main LAN as the WAN interface reset/forced connection drop quite often killed v6 completely (as there is no prefix available to be used).

[bringha]

All,

I am getting meanwhile somewhat puzzled where this discussion shall lead to and what the expectation towards opnsense shall result in.

My view is:
Simply forget about that Opnsense can fix something which is more than obviously originated from the network side. There are myriads of reasons why reconnects are triggered from network side, and this even on several layers (DSL, PPPoE, ...(10(..)000x) ... (up to) even problems in your in-house cabling), and there are myriads of combinations thinkable that this happens when (one of) the sides are not in a well defined state where a golden rule can apply which fixes everything with a single finger tip. And even if we can find 10-ish issues where some workarounds on opnsense can circumnavigate some network issues, still myriads of reasons will stay.

Even for officially authorized router devices from Telekom, the fora are FULL of stories, reports, complaints, angryness around this Zwangstrennungs beast. Lets not try to chase a phantom on opnsense side which is not helping to get things improved.

The best proposal when experiencing such a thing has been meanwhile mentioned 100 times: Reconnect from client side once this situation occurs. Three layers to try:

1.) Reconnect on PPPoE - if fail
2.) Reconnect DSL including reconnecting PPPoE - if failing again
3.) Reboot opnsense and Modem (which includes again DSL and PPPoE reconnect, incl. ipv6)

If there was no physical line problem or a problem on a relevant device on network side out of service, I could reach with that a stable ipv6 connection again in 100% of the cases.

Just my 10 cents

Br br
 

[sbellon]

Ok, but then the solution is easy:

OPNsense (plus DSL modem like Vigor) are not trouble-free compatible with Deutsche Telekom. If you have Deutsche Telekom, use their Speedport Smart and be done with it.

I had hoped for a nice OPNsense-based solution that is reliable. Again, it's not about "blaming". It's about understanding ... and perhaps admitting that OPNsense cannot do it for whatever technical or non-technical reason.

[bringha]

... as said in my 3rd paragraph - they are neither AND they have by far less functionality in almost all areas

The decision is to be made dependent from what your requirements are and what to balance out against what.

"Trouble free" is a big illusion - as simple as that

br br

[sbellon]

I maintain the internet access at my parents' home. Provider is also a Deutsche Telekom and they use a vanilla Speedport Smart and the LAN also has IPv6 (with static MAC/IP reservations). I have never experienced any issues there. If you argue about forums FULL of problems, the same can be said about this OPNsense forum here. Of course, forums are FULL of issues.

I do not say that a Speedport Smart can do what a OPNsense can, don't get me wrong, far from that. But a Speedport Smart is able to maintain a stable DSL connection with Deutsche Telekom including IPv6. I would not have expected that to be exclusive to Telekom, but perhaps I was too optimistic regarding PPPoE.

[skywalker007]

I run the same constellation (Deutsche Telekom, Vigor , OPNSense) and I have the same issue.
You can't blame OPNsense for the unstable PPPoE connection because it is the Vigor dropping it. And yes, I have tested the Speedport and it is more stable. I had tickets open with Vigor and tested several firmware releases with varying success but never solved it completely.
That after a reconnect the IPv6 is not established is indeed in my opinion an OPNsense issue. And I feel it is a timing issue. because when I manually force a reload of the PPPoE connection then IPv6 works perfectly.
The only thing that would be needed in my opinion, is some task that monitors if IPv6 addresses are assigned after PPPoE is up and if not bounce the connection again and re-establish.
I wonder if that can be done via monit?

[Patrick M. Hausen]

Anyone tried the Zyxel modem with official Telekom firmware?

I manage a couple of Telekom DSL lines, one with Zyxel, most with some Vigor - but they are all business contracts with a fixed /56, so I configure LAN statically. If I am not mistaken, they still disconnect the PPPoE every 24 hours, but at least in this scenario that never hurt me.

Wonder if the Zyxel works better for the consumer line with changing prefix.

[meyergru]

That after a reconnect the IPv6 is not established is indeed in my opinion an OPNsense issue. And I feel it is a timing issue. because when I manually force a reload of the PPPoE connection then IPv6 works perfectly.

After reading a lot about this issue, I would think so, too.

Glacing over what is involved, it seems like mpd5 is handling the PPPoE reconnection event via /usr/local/opnsense/scripts/interfaces/ppp-linkup.sh, which indirectly calls rc.newwanip and rc.newwanip6, which then start radvd and dhcpd on the LAN interfaces.

I do not know exactly, but to me, it looks like the IPv6 addresses on the LAN interfaces are not yet ready when rc.newwanip6 is being called, which may have to do with dhcp6c running asynchronously and not having received an IPv6 over the freshly established PPPoE link yet.

So maybe the better option could be to restart dhcp6c in /usr/local/opnsense/scripts/interfaces/ppp-linkup.sh or actively wait for an address to be gathered by it, but as I said, I am unsure about the exact order of events. I do not imagine that the DSL modem could have anything to do with this, because it can hardly discriminate or hold back dhcp packets after the PPPoE link is actually up. Probably Telekom is just a little slow to respond to the dhcp requests for an IPv6.

Alas, I cannot help with this, as none of my OpnSense installations is with Telekom.

[astronaut]

I am also using a Deutsche Telekom DSL line with nightly forced disconnect, and I am also having an issue with IPv6. OPNsense assigns wrong (deprecated) IPv6 prefixes for delegation to downstream routers with DHCPv6 after each disconnect. IPv6 addresses assigned directly by OPNsense seem to be fine.

My situation is different to the one described here because I am using an additional modem/router (FritzBox) for establishing the DLS connection , so I am not using the PPPoE function in OPNsense. OPNsense is connected to the LAN port of the FritzBox.

Things have been working fine until OPNsense 22.7.x, with the upgrade to 23.1, I need to reboot OPNsense each morning. (At least I didn't find another fix, simply restarting DHCPv6 doesn't help.) It seems there is some issue with detecting the IPv6 change in OPNsense 23.1 and then changing the delegated prefix.

 I originally described my issue here: https://forum.opnsense.org/index.php?topic=32313.0 I am not sure if it is related to what is being discussed in this thread, but it sounds as if it could be.