interfaces: allow tracking the WAN itself in DHCPv6 mode

[meyergru]

Important notices Before you add a new report, we ask you kindly to acknowledge the following:

• [x] I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
• [x] I have searched the existing issues, open and closed, and I'm convinced that mine is new.
• [x] When the request is meant for an existing plugin, I've added its name to the title.

Is your feature request related to a problem? Please describe. When using dhcp6c over a PPPoE link, if the ISP hands out IPv6 prefixes only, but no IPv6 interface address (i.e. "send ia-na 0" is not honored), the WAN interface gets no IPv6 assignment at all. Thus, one is limited to the IPv6 addresses of other interfaces that use "track6".

However, without an IPv6 on the WAN interface, FreeBSD does not honor the "highest address" rule of IPv6 in case that several other IPv6 addresses are available for use as a source address. Thus, you basically have no control over which interface's address will get used for outgoing connections from the firewall itself - e.g., assigning a higher IPv6 prefix ID does nothing.

If you register with a dynamic DNS service, you probably want to identify the IPv6 prefix for a specific VLAN interface. The prefix will be arbitrary, though.

Describe the solution you'd like It would be nice if track6 and dhcp6c were not mutually exclusive. If the interface configuration that originates from "track6" could also be generated for "dhcp6c" via a GUI checkbox, one could hand out an IPv6 prefix to the WAN interface even if the ISP does not offer a separate IPv6 for the interface itself. In that case, the WAN IPv6 would get used unconditionally before any other IPv6 addresses.

Describe alternatives you've considered I can see no option to assign IPv6 to the WAN interface in this situation.

Additional context It would also be nice to be able to use IPv6 privacy extensions from the firewall itself. This is not possible with dhcp6c or track6, I believe.

[kevinchalet]

@kevinchalet ok can you try this?

I gave it a try shortly after you posted your message and so far, it's been working like a charm: after setting the prefix ID and rebooting the machine, the WAN interface gets a lovely GUA (that even serves as the preferred source address when communicating with remote IPv6 machines, which is perfect!).

Just to be sure it wasn't a fluke, I rebooted it a few times and the GUA was correctly attached after each reboot 🤣

Since I'm going to use that new configuration in production, I decided to update my VTI-based IPsec site-to-site connection to use the GUA assigned to the WAN interface instead of the one set on LAN: so far, it's been working just fine. I also updated my dynamic DNS settings to monitor the WAN interface instead of the LAN interface and it seems to work flawlessly 😄

To nitpick, I suspect there's a minor omission/bug in the interfaces_has_prefix_only helper that prevents the GUA assigned to the WAN interface from being displayed on the dashboard when setting a prefix ID and using an advanced configuration (dhcp6-prefix-id is only checked when using basic configuration): https://github.com/opnsense/core/blob/bc34a38c02b12a89447c6adb45d918190c3d8e19/src/etc/inc/interfaces.inc#L4150-L4168

I manually updated interfaces.inc to add a !isset($interfaces_a[$interface]['dhcp6-prefix-id']) condition for the "advanced configuration case" and it seems to fix that, as the GUA is correctly shown on the dashboard :smiley:

Do you use the "Prefix Interface Site-Level Aggregation Length" option? What's your input there? I tied it to the setting like the tracking LANs do, but I was wondering what the complication with this is all about.

I do: since Orange France gives us /56 prefixes, I instinctively set it to 8, but to be honest, I'm not super familiar with this setting and not totally sure what scenarios it enables 😅

Thanks a lot for this brilliant job! ❤️

[fichtner]

@kevinchalet c'est chouette, happy to hear! And fair point -- you're missing 51d75b6 because it was late and I was lazy. Sorry about that :D

I have one thing about autoconf handling to check out and then the whole thing seems solid and done (note to self).

Cheers, Franco

[meyergru]

Sorry guys, I can only try with my own setup and the wife is using the line 24/7. One question: If I try the revert, would it work for pppoe WAN as well?

[fichtner]

it's just DHCPv6 being affected but as far as it looks not in a bad way. The only trick is to restart the dhcp6c binary for minimal downtime since it's using SIGHUP in the system once up, hence the reboot suggestion for a clean apply.

[fichtner]

(I'm running this here too with no issues. Not that I need the additional WAN address but we all know people want it.)

[meyergru]

So, I did:

opnsense-patch 18803127e54 bc34a38 51d75b6 b747e4a && opnsense-revert -z dhcp6c
reboot

Afterwards, I configured dhcp6c with "config file override" and put in the missing part for pppoe0:

interface pppoe0 {
  send ia-pd 0; # request prefix delegation
  request domain-name-servers;
  request domain-name;
  script "/var/etc/dhcp6c_wan_script.sh"; # we'd like some nameservers please
};
id-assoc pd 0 {
  prefix ::/56 infinity;
  prefix-interface ixl1_vlan5 {
    sla-id 5;
    sla-len 8;
  };
  prefix-interface ixl1_vlan4 {
    sla-id 4;
    sla-len 8;
  };
  prefix-interface ixl1_vlan7 {
    sla-id 7;
    sla-len 8;
  };
  prefix-interface ixl1_vlan10 {
    sla-id 16;
    sla-len 8;
  };
  prefix-interface ixl1 {
    sla-id 6;
    sla-len 8;
  };
  prefix-interface pppoe0 {
    sla-id 1;
    sla-len 8;
  };
};

Alas, the configuration file cannot be parsed:

<27>1 2024-06-05T13:40:02+02:00 OPNsense.mgsoft dhcp6c 79858 - [meta sequenceId="176"] failed to parse configuration file

On a side note, my pppeo0 interface shows two (!) inet6 LL addresses:

pppoe0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: WAN (wan)
        inet6 fe80::5a47:caff:fe73:338b%pppoe0 prefixlen 64 scopeid 0x13
        inet6 fe80::5a47:caff:fe73:338c%pppoe0 prefixlen 64 scopeid 0x13
        inet 93.104.123.101 --> 82.135.16.28 netmask 0xffffffff
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

[fichtner]

I don't think the scope and point was to try the file override. I've worked on the basic and the advanced DHCPv6 mode with the "Optional Prefix ID" setting. I can't make any guarantees about undefined content in the override file.

Cheers, Franco

[meyergru]

I did not see the option... now that I enabled it, I do not get any IPv6 assigments (neither on the other VLANs).

What is interesting is that dhcp6c is started now, but when I kill the process and start it again (via "/usr/local/sbin/dhcp6c -c /var/etc/dhcp6c.conf -p /var/run/dhcp6c.pid"), it does not start and I get the same error message as before. And the content of /var/etc/dhcpd.conf is the same as I had before (modulo interface order):

interface pppoe0 {
  send ia-pd 0; # request prefix delegation
  request domain-name-servers;
  request domain-name;
  script "/var/etc/dhcp6c_wan_script.sh"; # we'd like some nameservers please
};
id-assoc pd 0 {
  prefix ::/56 infinity;
  prefix-interface pppoe0 {
    sla-id 1;
    sla-len 8;
  };
  prefix-interface ixl1_vlan5 {
    sla-id 5;
    sla-len 8;
  };
  prefix-interface ixl1_vlan4 {
    sla-id 4;
    sla-len 8;
  };
  prefix-interface ixl1_vlan7 {
    sla-id 7;
    sla-len 8;
  };
  prefix-interface ixl1_vlan10 {
    sla-id 16;
    sla-len 8;
  };
  prefix-interface ixl1 {
    sla-id 6;
    sla-len 8;
  };
};

I am almost certain that it must be timing-related. At the time my WAN and dhcp6c gets restarted, the file contents are probably different. Otherwise, how could it start?

[meyergru]

When I disable the "Optional Prefix ID" by leaving it blank, I get IPv6 prefixes on all VLANs. The config file then lacks the pppoe0 prefix-interface section and with that content, a manual restart works and gives no config file parsing error.

So something is fishy about pppoe0. For starters, it does not have a MAC, but two LL ipv6s...

[meyergru]

The debug message for the failing dhcp6c is:

# /usr/local/sbin/dhcp6c -d -f -c /var/etc/dhcp6c_new.conf -p /var/run/dhcp6c.pid
Jun/05/2024 15:53:22: link layer address is too short (pppoe0)
Jun/05/2024 15:53:22: failed to get default IF ID for pppoe0
Jun/05/2024 15:53:22: failed to parse configuration file

This also seems to indicate that the EUI-64 derivation is not possible without the MAC. There was a discussion about something similar for localhost interfaces here: https://forum.opnsense.org/index.php?topic=37045.msg181433#msg181433

I have tried to set the MAC for the pppoe0 interface with and without promiscuous mode, it is not possible. It seems my scepticism about PPPoE was justified,,,

[fichtner]

I now remember that you had this problem the last time too. Let me see if I can fix that as well in dhcp6c while we are at it.

[meyergru]

Yes, should be possible, because apparently, there are some derived EUI-64 addresses there that could be used for this. They look as if they are somehow based on the MAC of the parent VLAN interface (not exactly, but 1 or 2 less than the actual MAC). Lots of trickery going on there.

I am stuck with PPPoE on my ISP (M-Net) for testing as I dare not test with any of my remote instances using DHCP only. Their ISP (Deutsche Glasfaser) uses DS-Lite and CGNAT, so if I lose IPv6 connectivity on them, I cannot fix it anymore. :-(

[kevinchalet]

@kevinchalet c'est chouette, happy to hear! And fair point -- you're missing https://github.com/opnsense/core/commit/51d75b6302acd54e7e5b8933eeb8f21cbd9578bd because it was late and I was lazy. Sorry about that :D

Haha, no worries! ❤️

@meyergru I guess one way to fix the issue you describe would be to port the ifid/ifid-random options from Debian's dhcp6c port:

• https://sources.debian.org/src/wide-dhcpv6/20080615-23/debian/patches/0007-Adding-ifid-option-to-the-dhcp6c.conf-prefix-interfa.patch/
• https://sources.debian.org/src/wide-dhcpv6/20080615-23/debian/patches/0020-Adding-option-to-randomize-interface-id.patch/

It would also be a great way to assign static "suffixes" to specific interfaces, which would be very useful in some scenarios (e.g a web server for which you don't want the IPv6 address to change when replacing the NIC) 😃

[fichtner]

I didn't know Debian had a stash of patches for wide-dhcpv6 ... this is great, thanks a ton for the hint!

[kevinchalet]

I didn't know Debian had a stash of patches for wide-dhcpv6 ... this is great, thanks a ton for the hint!

Amusingly, I heard of the Debian port for the first time last night when trying to learn more about that sla-len option you mentioned yesterday: I first read the Debian version of the dhcp6c docs and got very confused by the ifid/ifid-random options that didn't seem to be supported in FreeBSD/OPNsense 🤣

[fichtner]

Nice catch... actually I was a bit wrong and we were tackling a bug with a patch from there a while back https://github.com/opnsense/dhcp6c/issues/25

I've created a branch with what I would consider relevant including the ifid/ifid-random: https://github.com/opnsense/dhcp6c/commits/debian_stuff/

For now I'll just run this branch locally and see if this has any visible regression.

[fichtner]

So far so good, played with ifid-random:

dhcp6c 7618 - [meta sequenceId="66"] add an address 2003:cd:8712:61f8:f690:eaff:fe00:d30c/64 on igb0
dhcp6c 7618 - [meta sequenceId="5"] remove an address 2003:cd:8712:61f8:f690:eaff:fe00:d30c/64 on igb0
dhcp6c 7618 - [meta sequenceId="16"] add an address 2003:cd:8712:61f8:a282:d14a:3201:b439/64 on igb0
dhcp6c 7618 - [meta sequenceId="63"] remove an address 2003:cd:8712:61f8:a282:d14a:3201:b439/64 on igb0
dhcp6c 7618 - [meta sequenceId="74"] add an address 2003:cd:8712:61f8:496e:2610:cf3b:9fde/64 on igb0

So you can see the lower address part shift with each SIGHUP to the daemon... :)

[meyergru]

Nice. A kind of "privacy extensions". I personally would use ifid, because my own dynamic DNS has the EUI-64 part configured statically and only the prefix is taken, so I need predicatle EUI-64s.

[kevinchalet]

So you can see the lower address part shift with each SIGHUP to the daemon... :)

Excellent! Using a static/arbitrary ifid (at least on my WAN interface) is definitely something that would be nice to have, so let me know if you need additional testers 😄

[fichtner]

I’ll publish a snapshot tomorrow. This looks good.

Thinking about GUI access the basic config should probably get a random checkbox. The advanced can have both. And then for optional prefix tracking on wan we could validate for PPPoE that random is used.

Or we could make ifid-random a fallback in the PPPoE failure case in dhcp6c although that makes things less transparent for the user with the GUi option unchecked…

Thoughts?

[meyergru]

If I understand this right, there is no predictable EUI-64 for PPPoE if ia-na is honored by the ISP, so using the ifid-random option per default would not do harm anyway - if you can apply it only if there is no ia-na and with the "Optional Prefix ID" active, it is all the better.

In that case, we would only need an ifid field (a MAC?) to set this static, like with the MAC input on the interface page. Matter-of-fact, from a user perspective, I would expect to be able to set the MAC exactly there, even if it turns out to be more tricky under the hood, because the method to set the MAC varies by interface type.

BTW: Sure this will not be in 24.7? When it will be finished, it will consist of mostly backwards-compatible, non-intrusive changes AFAIK.

[fichtner]

If I understand this right, there is no predictable EUI-64 for PPPoE if ia-na is honored by the ISP

The issue is simply that when assigning a PD slice to a PPPoE device it currently fails because the device doesn't have a MAC address property by itself and this ends up as a hard failure for the daemon config parser.

That's the reason why I mentioned it could be fixed by enabling a random ID in the daemon in this case as an automatic fallback. It would work then, better than refusing operation.

In that case, we would only need an ifid field (a MAC?) to set this static, like with the MAC input on the interface page.

For a numeric field in the config I'd rather not start computing and translating user input by "pretending" to assign a MAC address.

Sure this will not be in 24.7?

Why should it not? The only complication as of now is the PPPoE tracking itself which we already have the code in dhcp6c to fix.

Cheers, Franco

[meyergru]

+1, as ifid seems to be numerical (strange as its default is the EUI-64 of the interface if present as per documentation)

W/R to 24.7: Nice - I thought I remembered that the 24.7 label was removed, but it's there.

[fichtner]

I made a small thing in https://github.com/opnsense/dhcp6c/commit/419939b1c70 so we could just allow special keywords in the input for ifid... either:

ifid 1234;

or

ifid random;

which is the same as

ifid-random;

which would have been nicer from the start ;)

[fichtner]

I extended the backport to allow specification of the ifid option for the WAN side only for now:

# opnsense-revert -r 24.1.8 opnsense && opnsense-patch b474cd7 && opnsense-revert -z dhcp6c

So putting "0" or "random" into the field should fix the PPPoE case and "0" will actually give you a "::" lower part address on the WAN.

I will extend this to the tracking side later, but I also think dhcp6c should auto-cope with the problem of not being able to generate an EUI-64, which also requires us to make this mode explicit for consistency before we change the default behaviour.

Cheers, Franco

[fichtner]

One more binary update coming tomorrow. I've reworked the ifid handling considerably in https://github.com/opnsense/dhcp6c/commit/f5422a8eb4

TLDR: it can now fall back to random interface ID generation if the EUI-64 fails in the default configuration (unless explicitly specified)

I'll couple this with allowing the interface ID in the tracking configuration as well and then we should be all done here :)

[meyergru]

I did not see the ifid field in the GUI, before a reboot.

I first have set ifid in the manual configuration file and that works. Excellent work!

It is quite difficult to modify the advanced configuration tab in order to mimic basic options, in my case:

• Send Options = ia-pd 0,
• Request Options = domain-name-servers,domain-name,
• Prefix Delegation = true,
• id-assoc pd ID = 0,
• Prefix IPv6-Prefix = ::/56,
• Preferred Lifetime = infinity,
• Prefix Interface Site-Level Aggregation Length = 56.

So I vote for having the "Optional interface ID" on the basic tab as well, where all these options are much easier to set by just clicking boxes.

[meyergru]

Forget my nonsense. I found the field on the basic tab, too. And that works.

But, when I do the above settings on the advanced tab (which are neccessary for my ISP), I do not get "ifid" in dhcp6c.conf,

So, the basic tab works, manual config file works, too, but advanced tab skips "Optional interface ID" in the config file.

[fichtner]

Well it's in basic and advanced mode in the latest backport:

https://github.com/opnsense/core/commit/b474cd70cb8d0c99978204b6e2cfff98c86ba19d#diff-8bda10faf6dc1b2eed1742ad25598b60e7f23d7934e9cc58802f517198bbed9aR2762 https://github.com/opnsense/core/commit/b474cd70cb8d0c99978204b6e2cfff98c86ba19d#diff-8bda10faf6dc1b2eed1742ad25598b60e7f23d7934e9cc58802f517198bbed9aR2775

I don't want to improve advanced mode. It's quite hard to use, but the addition is the same.. .you need the prefix ID and the interface ID set. Same for basic mode actually.

[meyergru]

Yes, I found it now. But advanced tab does not work, see above, I edited it.

[fichtner]

You are right, it was a typo. Sorry. 0dc1f2186

[meyergru]

NP. That is what tests are for. Works fine now.

[kevinchalet]

I just gave the updated bits a try (only the static ID for now) and it's working great. Good job! 👍🏻

For a numeric field in the config I'd rather not start computing and translating user input by "pretending" to assign a MAC address.

IMHO, using a decimal input in the UI looks a bit weird (note sure why the dhcp6c folks went with decimals for things like sla-id in the first place 😅): for instance, if you want an address that ends with ::1111:2222:3333:aaaa, you first need to remove the : and convert the result from hexadecimal to decimal (in this case, 1229801703532112554, which looks a bit... cryptic 🤣).

Wouldn't an hexadecimal input - like the prefix ID - be a better solution here? (in this case, 0x111122223333aaaa).

[fichtner]

Fair point, yet there is a bit of a problem inherent in the parser code that won't accept the highest bit of the interface ID input either way. I'm afraid users will notice once that is in hex and doesn't do what they want ;)

Some of this aversion to readable input is the avoidance of string parsing complexity in C I believe...

I'll think about it. There is time to fix this later as well. The presentation in the GUI can be hex even if the value is stored numerically.

Cheers, Franco

[kevinchalet]

The presentation in the GUI can be hex even if the value is stored numerically.

Ah yeah, that's exactly what I had in mind (I should have been clearer, sorry 😄). Having a decimal ifid in the configuration file is probably the best option: it's the format used by the Debian port - so users familiar with this option won't be confused - and it's consistent with the existing fields, like sla-id 😅

[kevinchalet]

BTW, since Christmas is really coming early this year with all these nice IPv6 changes, would it make sense to revive https://github.com/opnsense/core/issues/4430? It's something I hit when configuring a spoofed MAC address on my WAN interface two years ago and it's still present in the 24.1 branch: using net.inet6.ip6.auto_linklocal=0 and assigning VIPs to all your interfaces works but:

• Since it's a global setting, it affects all the interfaces, so you need to add "link local IPv6 VIPs" for all of them, which isn't super convenient.
• During my tests, the IPv6 connection was not operational immediately after booting as the IPV6 DHCP gateway wasn't properly registered (maybe because the router sollicitation was sent before the VIP was attached to the interface?). You can restart the WAN interface to fix that after booting, but it's not ideal.

[fichtner]

I can briefly check the code relevant to #4430 in the kernel but it is difficult to fix from the configuration end if the kernel is unwilling or inconsistent in its behaviour.

[fichtner]

7c18937b should make the highest bit usable in ifid... to my surprise negative numbers(minus sign) were not accepted by the parser so that's an easy change. I'll work on the GUI parts now.

[meyergru]

I will be unable to test until.next thursday.

[fichtner]

Yeah, no rush, now intval() in PHP is giving me the same trouble while conerting hex to decimal

[fichtner]

Decided to not offer random at the moment other than for the PPPoE case where dhcp6c does that on its own. You can still make that address static using the interface ID override, even in valid EUI-64 format if you will... except for that PHP long long integer limit but I can't fix that so it's in the help text.

The options may need better names and some documentation updates, but I will do this post 24.7 beta images.

[kevinchalet]

I can briefly check the code relevant to #4430 in the kernel but it is difficult to fix from the configuration end if the kernel is unwilling or inconsistent in its behaviour.

You mean the approach mentioned here? Might be worth giving a try 😃

... except for that PHP long long integer limit but I can't fix that so it's in the help text.

😅 Really? It was already a stupid limitation when I moved from PHP to .NET 15 years ago, but it's crazy to see the situation hasn't improved in any way! (in comparison, .NET already had a BigInteger for arbitrarily-large numbers but has recently introduced new dedicated Int128 and UInt128 types for 128-bit integers...)

I'll give the latest commit a try 😃

[fichtner]

Last version for a while:

# opnsense-revert -r 24.1.8 opnsense && opnsense-patch 30df142 && opnsense-revert -z dhcp6c

@meyergru @kevinchalet thanks for all the input and testing!

Cheers, Franco

[kevinchalet]

@meyergru @kevinchalet thanks for all the input and testing!

My pleasure! Thanks a lot for the time you dedicated to these nice - but niche? - features. Much appreciated! ❤️

On a related note, one cool side effect is that it also simplifies the DynDNS configuration story: I just moved back to the ddclient backend (which is something I wanted to do for a long time, as the native backend sadly doesn't support forced updates) and a single entry using Interface + WAN as the IP resolution mechanism is now enough to support both IPv4 and IPv6 since the WAN interface can now have a GUA 👏🏻

Edit: I applied https://github.com/opnsense/core/commit/30df1423464981bd392af1fe21fe4fb0a03ac4ff and rebooted, still working fine 👍🏻

[fichtner]

You mean the approach mentioned https://github.com/opnsense/core/issues/4430#issuecomment-715911376? Might be worth giving a try 😃

No, now the kernel says if auto_linklocal is set and the link-local is removed and the interface brought down and up again it will assign a new link-local automatically. I tested this with a faked ether MAC address and it does indeed use faked one rather than the original hwaddr MAC address. So addressing this loophole in the configuration code should be easy enough. I don't see a big need for removing auto_linklocal. It's just not going to end well. The bridge is a special case where it't not on by default so the option was added there to enable a defined use case.

Really? It was already a stupid limitation when I moved from PHP to .NET 15 years ago

Yes. Seems to be the law of the land... there's only so much space in a signed integer and since we don't have 28 bit architectures it is what it is. This can all be improved/worked around but the time is better spent elsewhere at the moment.

Thanks a lot for the time you dedicated to these nice - but niche? - features. Much appreciated! ❤️

Not that niche judging by the questions over the years, but also not well researched and implemented in open source. This is pretty cutting edge now.

Edit: I applied https://github.com/opnsense/core/commit/30df1423464981bd392af1fe21fe4fb0a03ac4ff and rebooted, still working fine 👍🏻

Perfect. Ready for the 24.7 beta images then. :)

Cheers, Franco

[kevinchalet]

No, now the kernel says if auto_linklocal is set and the link-local is removed and the interface brought down and up again it will assign a new link-local automatically. I tested this with a faked ether MAC address and it does indeed use faked one rather than the original hwaddr MAC address.

Nice, I'll keep an eye on the other thread then 😃

Not that niche judging by the questions over the years, but also not well researched and implemented in open source. This is pretty cutting edge now.

Yeah, definitely. AFAIK, only systemd-networkd currently has a pretty well-integrated and simple story for that (by simple, I mean you don't have to write custom scripts 🤣).

Should be something like...

[Match]
Name=wan

[Network]
DHCP=yes
IPv6AcceptRA=yes
IPv6SendRA=no
DHCPPrefixDelegation=yes

[DHCPv6]
UseDelegatedPrefix=yes
PrefixDelegationHint=::/56
WithoutRA=solicit

[DHCPPrefixDelegation]
UplinkInterface=:self 
SubnetId=0x01 # Equivalent of sla-id in dhcp6c
Announce=no
Token=::1111:2222:3333:aaaa # Equivalent of ifid in dhcp6c

But of course, it's a Linux thing, so not something OPNsense could benefit from (unless you plan to work on a Linux version at some point? 🤣)

[meyergru]

I checked the last version now and it works nicely. So it's ready for 24.7. Closing this issue now.

[fichtner]

I still have to tweak the wording and update the docs :)

[Starkstromkonsument]

Last version for a while:

# opnsense-revert -r 24.1.8 opnsense && opnsense-patch 30df142 && opnsense-revert -z dhcp6c

@meyergru @kevinchalet thanks for all the input and testing!

Cheers, Franco

It works perfectly. Thank you very much for addressing this!

BTW: It doesn't seem to be a niche issue. My Vodafone VDSL in Berlin doesn't work properly without this fix either.

[Zerwin]

@meyergru Did you manage to get Opnsense to work with M-Net and IPv6 after the update ? I had problems after updating that it would connect successfully via PPPoE and give me a link local address but then never gave me a public routable one. Had to go undust the AVM router as a workaround for now.