OPNsense Forum
Archive => 23.1 Legacy Series => Topic started by: sbellon on February 02, 2023, 07:21:56 am
-
Hi all,
I have a virtual OPNsense running on Proxmox VE connected to a Draytek Vigor 167 on a VDSL100 from Deutsche Telekom running with dual stack.
Every few days there's a disconnect and sometimes afterwards IPv6 is dysfunctional (DHCPv6 is not runnig). With 22.7 I could use the DHCPv6 Reload button in Interfaces -> Overview -> WAN, but now with 23.1_6 this does not work for my any more. Even Reload PPPoE does not work reliably and I have to reboot everything.
My configuration:
WAN:
IPv4: PPPoE
IPv6: DHCPv6
Request only an IPv6 prefix
Prefix delegation size 56
Send IPv6 prefix hint
Use IPv4 connectivity
LAN:
IPv4: Static IP
IPv6: Track interface (WAN)
What kind of logs should I provide to further track this down? Pressing a "DHCPv6 Reload" button every now and then was "ok", but the situation right now is really starting to get a nuisance, I have to say. :-(
Edit: To clarify, my last sentence was not meant as a complaint against the developers. I understand how hard it is to cater for all scenarios, especially without the exact setup to reproduce the issues. It was rather meant to express how desperate I am and that I am willing to debug it in order to come to a solution once and for all.
-
23.1_6 should work as 22.7 did. A problem with Telekom is that they seem to require a Dual-dual stack where you get an IPv6 via PPPoE and then you have to use that address to get a DHCPv6 delegated prefix.
Did you reboot since applying 23.1_6?
Cheers,
Franco
-
Yes, I rebooted several times because that's currently how I can get back the IPv6 address.
-
So it works for a while and then stops? Logs would be useful. Let's start with System: Log Files: General with "notice" level.
I think the main problem might be there is some sort of soft reset and afterwards you get the same address and some parts of the system do not reload although they should.
Cheers,
Franco
-
It stops when there was a forced disconnect (mostly at night, sometimes daily, sometimes after two weeks, I have not yet detected a pattern).
Can I also just post /var/log/system/latest.log? Post it here or send it to you?
-
23.1_6 should work as 22.7 did. A problem with Telekom is that they seem to require a Dual-dual stack where you get an IPv6 via PPPoE and then you have to use that address to get a DHCPv6 delegated prefix.
I do not have Telekom, my ISP really only gives me an IPv6 prefix, so if I request more, I get nothing at all.
However: If it is like you describe, then @sbellon should probably disable "request IPv6 prefix only" in order to be able to get the prefix for delegation.
-
Prefix is always delegated if given, unless using advanced options. The actual IPv6 cones from PPPoE as I said. Assuming Telekom didn't change anything in the same time frame.
It would probably be beneficial to use Interfaces: Settings: Prevent release. Usually the infamous "Zwangstrennung" disconnects the line, but not the leases...
Cheers,
Franco
-
What I meant is that if the IPv6 for the WAN interface itself comes from PPPoE, and in a second step the delegation prefix is fetched via IPv6, then in order to get that via IPv6, you must ask for a WAN IPv6 and exactly that is not being done when "Request only an IPv6 prefix" is checked on the WAN interface, as @sbellon wrote.
But as I said, I have a different ISP.
-
Isn't there a "definitive" way of how to configure it for Deutsche Telekom dual stack? I think there must be some people out there using the intersection of Deutsche Telekom and OPNsense. ;-)
-
I don't understand. If it worked before it should still work with PD and unchecking "Request only an IPv6 prefix" might not make it work at all with Telekom since they already funnel the address through PPPoE.
So: if you request an address and a prefix you get nothing.
-
Deutsche Telekom, DSL/PPPoE - I get e.g.
Single address: 2003:a:d7f:d938:3eec:efff:fe00:5432 with a /64 prefix length on pppoe0
Prefix: 2003:a:d59:3800::/56
Kind regards,
Patrick
-
And what IPv6 related settings are mandatory to have ticked or unticked to make it work reliably?
Remember: It's not that I do not get IPv6 at all. It's just that often after a "Zwangstrennung" I'm IPv4 only. With 22.7 a "Reload DHCPv6" in Interfaces Overview cured it, now with 23.1 it doesn't.
I now have additionally checked "Prevent release" - which I hadn't before, let's see whether that makes a difference.
-
That's all I have:
(https://forum.opnsense.org/index.php?action=dlattach;topic=32259.0;attach=25583;image)
-
Hi there
@sbellon I have exactly the same set up as you have and still the good old description of
https://forum.opnsense.org/index.php?topic=21839.0 (https://forum.opnsense.org/index.php?topic=21839.0)
fits also for 23.1 in so far. From my view close to the "definitive" way you seem to look for.
However, "Zwangstrennung" due to the many different reasons it is carried out from network side is a somewhat different animal which is hard to be addressed from client side in all its (often unknown and intransparent) cases. Zwangstrennung is done for maintenance, new customers on the same line bundle and after-optimization, incident resolution, construction work, and many more. Btw. also all my fritzboxes lost ipv6 after Zwangstrennung pretty often.
I can confirm that I saw also in several old versions of Opnsense that IPv6 did not come up properly after Zwangstrennung. I could then recover ipv6 by manually storing the WAN config again and ipv6 was back. Other than that, playing around with the settings on the client side did not bring any improvement for the Zwangstrennung case.
I also did not see that I got the same ipv6 prefix after a Zwangstrennung that I had before - was always different.
Br br
-
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 ... :-|
-
You can try but I think it's missing the point of what causes this.
Cheers,
Franco
-
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?
-
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.
-
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"?
-
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.
-
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
-
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 (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).
-
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
-
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.
-
... 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
-
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.
-
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?
-
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.
-
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.
-
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 (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.
-
Anyone tried the Zyxel modem with official Telekom firmware?
Not sure, what Zyxel modem you are referring to specifically. However, I'm running the Zyxel DX3301-T0 (https://geizhals.de/zyxel-dx3301-t0-dx3301-t0-de01v1f-a2753549.html) in bridge mode with Supervectoring and as I said, I experience the v6 prefix dropouts (the Github issue is mine).
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?
This was also a suggestion I made in the issue as a temporary workaround to at least make it stable. However, I'm not sure if DTAG has a rate limiting or if that would break other parts as well. Also, I did not receive any comment on the idea by the maintainers.
-
It would probably be beneficial to use Interfaces: Settings: Prevent release. Usually the infamous "Zwangstrennung" disconnects the line, but not the leases...
It looks like *this* makes a big difference indeed.
The "Request only IPv6 prefix" does change the behaviour regarding whether the WAN gets its own IPv6 address or not (and actually works like advertised), however it has no influence on the dhcpd6 sometimes not running after a forced connect.
However ticking "Prevent release" makes a difference. Since I did that ~10 days ago, I have not yet run into that situation again. Let's keep it that way. :-)