Messages

Hi dseven,

I doubt, but cannot proof it in any direction because it is a "production" (multi house hold + we live in home office times) system and I cannot change configs for testing right now.

What I can tell is, that the IP address before and after setting the range was identical.

Nevertheless, even when marking this a solved for now, I will have another look later.

Thanks so far and best regards
Robert

[an address range is specified in the DHCPv6 service settings]

It should be possible to do a static mapping with a dynamic prefix - you'd just specify the suffix part of the address only, e.g. ::0:0:0:abcd - but, so long as you have a pool of addresses available for dynamic leases, that should not be necessary in order for the route to get added.

I've played around with this a bit, and I did get it (prefix route added when using a dynamic lease) to work, but it wasn't exactly straightforward - possibly partly because I already had my prefix delegation configured for a static (not tracking) interface, and cleanup of my old config seemed incomplete.

I'd suggest that, for any interfaces using tracking for IPv6, you check the "Allow manual adjustment of DHCPv6 and Router Advertisements" box, and configure DHCPv6 (and RA) explicitly the way you want - it seems that the automatic mechanism may make some egregious assumptions when it comes to prefix delegation (possible topic for another thread).

Failing that, describe how your interfaces and the DHCPv6 service are configured, and how you're observing that the route is not getting added...

Hi dseven,

thanks for your reply. I did some more investigation as well in the meantime and came across one sentence in the DCPH documentation https://docs.opnsense.org/manual/dhcp.html:

Dynamic DHCPv6 address lease: If an address range is specified in the DHCPv6 service settings and the downstream router requests both an address (IA_NA) and prefix (IA_PD), the prefix will be routed to the leased address.

This was not the case in my configuration because it was (technically) not necessary. The IPv6 address was handed out by the DHCP server without it as well to my downstream router (based on the prefix ID setting in the "Track IPv6 Interface" config of my relevant interface of the OPNsense box). Nevertheless, to match the documentation I added a range and..now the route to my /57 prefix is created automatically targeting the router IP (v6).

Next thing I want to try is the static configuration part mentioned in the documentation as well. But I am unsure how the DUID must look like to be kind of dynamic for the (often) changing prefix. But..next year. :-)

Best regards
Robert

Found another related discussion: https://forum.opnsense.org/index.php?msg=174073

But not fully sure about Francos comment there relating to the static mapping approach and how this may work with an dynamic prefix from my ISP?

Hi all,

just to confirm I am not doing a stupid mistake.

This is my setup:
* I get a /56 delegated from my ISP
* the OPNsense box is directly behind the modem
* box is delegating a /57 to a downstream router

Until that point, all works as desired. What NOT works and I don't find the "why": OPNsense is never creating a route for the delegated /57 to my downstream router via the interface it is connected to. In consequence, IPv6 is not working at all in that network segment.

Is there anything specific I must know here or is this just a bug?

What I found is this: https://forum.opnsense.org/index.php?topic=7719.0 describing exactly my problem. But, I do request a IPv6 address from the downstream router already and it is handed out. But in that case, only a route for the /64 which contains the dhcp pools address range is created, not for the /57 which is delegated.

Thanks in advance
Robert

Hi all,

a question for understanding how ISC DHCPv6 configuration is desired to work. What I want is to delegate /57 out of my /56 prefix to a downstream router. I try the following configuration (see screenshot as well):

Code Select Expand


Prefix Delegation Range
from: ::80:0000:0000:0000:0000
to: ::ff:ffff:ffff:ffff:ffff


But, this is not working, I get a "network mask too short prefix6" error message in the log if trying. On the other hand a:

Code Select Expand


Prefix Delegation Range
from: ::80:0000:0000:0000:0000
to: ::80:0000:0000:0000:0000


is accepted.

Has someone experience here and can explain the logic behind to me?

From my understanding, the first config is correct while the last is not.

Thanks and best regards
Robert

Hi Robert,

Sorry for the response delay.  It's still true but the package moved to a new rebuild (but holds the same source code as discussed):

# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/snapshots/misc/dhcp6c-20240919_1.pkg

Just update to 24.7.5 and see how that goes as a separate data point. Then install the updated client and reboot again to see if that changes things.

Cheers,
Franco

Hi Franco,

good and bad news.

Did another series of tests to track this down further. Just as a recap, my setup is:
* OPNSense setting vlan7 (necessary for my provider Deutsche Telekom) and doing PPPoE dialing
* Modem directly connected to the OPNSense Box not setting a vlan7

1. installed 24.7.5 -> not working (see attached log)
2. installed patched dhcp6c client on top of 24.7.5 -> not working (see attached log)
3. connected a OpenWRT box in the exact way to the modem as the OPNSense box and let it set vlan 7 -> working
4. reconfigured OPNSense to NOT set the vlan (using the underlying interface directly) and let the modem set the vlan -> working (can provide log if needed, forgot to collect)

Based on this there are three new data points:
* it is no longer sure, that the problem was introduced with 24.x.x (I doubt so). But I reconfigured the vlan thing at the same time (mentioned it in earlier posts already)
* it is no provider side issue
* there is a problem with OPNSense and IPv6 PD when it is based on a vlan instead directly at the physical interface

What do you think how we should go on here, is there anything I can test for you?

I think a bug in the dhcp6 client is not longer likely, more one deeper in the network stack?

Best regards
Robert

Robert,

As per my earlier comments I wrote this patch to try https://github.com/opnsense/dhcp6c/commit/d2e5fb474f

# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/snapshots/misc/dhcp6c-20240907_3.pkg

Reboot to see if it helps.

Thanks,
Franco

Hi Franco,

is this still true for 24.7.5 or will things break if I apply the patch/install the package? Or in the other direction, needa the patch/package a adaption for 24.7.5 before trying it?

And should I install one by one and check the effect or both together?

Can do this now, my box has not that much critical traffic this weekend.

Best regards
Robert

Hi Franco,

Do you have "Request only a prefix" unset? It would be better to set this option if that's the case. If it's already set we need to try and ignore this zero lifetime NA that doesn't even provide an address.

Yes, this was unchecked. Never checked this the years before and it always worked. Nevertheless, gave it a try but without success (see attached log).

To me it looks like a server quirk to be honest.

If we follow this theory, then something must have triggered this server problem on the OPNsense side since 24.7.x. Before I always had IPv6 in use and no problems.

For mit it looks like all is fine, but it just isn't working and getting a prefix. Weird.

One small thing I changed with the migration to 24.7.x is, that OPNsense is now setting the Vlan ID (7) instead of the modem internally (that was the case before). But I cannot imagine how this can lead to the problem, IPv4 is working fine and I even get a IPv6 address for the "wan interface", just the prefix is not delegated.

Best regards
Robert

PS: The version you tested is going to be tomorrow's release version in 24.7.4 anyway.

Hi Franco,

tried again with 24.7.4. Unfortunately I still get no prefix delegated on my "wan" interface. I send a /56 prefix hint and use the IPv4 connectivity on the interface tagged with vlan 7. As all the years before.

I've attached the log again. Still no specialist in that topic, but I think the pattern of the log changed somewhat since 24.7.3. It repeats steps and contains multiple times a clear

Code Select Expand

create a prefix 2003:c3:xxxx:xxxx::/56

But later stopping with it and then a

Code Select Expand

advertise contains no address/prefix

Do you have another idea what to check?

Thanks and best regards
Robert

Can I apply this with opnsense-patch somehow

Nah. You can apply it with the command already posted:

# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/snapshots/misc/dhcp6c-20240907.pkg

Hi all,

how can I revert this to the production version? Is a

Code Select Expand

opnsense-revert dhcp6c

enough to do so?

Sorry, havn't that much experience in that direction and it is a quite productive system.:-)

Best regards
Robert

Hi Franco,

This is only the default value, but in all honestly it's a historic artefact and not even used anymore. The interface name is always passed.

This is purely a interpreted languange without compiling or poat processing build steps to check method calls against the existing signatures, right? So no chance to just remove the default without risk of breaking stuff.

I think we figured out the mix of commits that caused dhcp6c to regress the way it did in 24.7.2:

# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/snapshots/misc/dhcp6c-20240907.pkg

This will be in 24.7.4. Worth a test, but needs a reboot to activate.

Can I apply this with opnsense-patch somehow and is this different from the previous opnsense-patch 6b28dae2 82ea39b04c?

Or makes it just sense to wait for 24.7.4?

Thanks again and best regards
Robert

Hi Franco,

really stupid question and asked if at another point this thread already, but all I try to do should work with a which is not the original wan (mine is a custom created new interface, not ootb wan), right?

Just asking because I scrolled a little bit through the changed files in your commit and e.g. here:
https://github.com/opnsense/core/blob/6b28dae26cbadb9d25708685f590ee9af0506678/src/etc/inc/interfaces.inc#L2238

is a hard coded reference to "wan" and later this is used via "$wancfg".

But really didn't looked trough the whole code flow but stumbled over it and the question came up again for me.

Best regards
Robert

> Do you have a idea or at least a speculation what causes this? I mean, as written in the OP, ISP is the same and it worked before. As well with PPPoE and IPv6 together.

Most of this revolves around timing issues: PPP being a bit less reliable due to extra software in between (mpd5), dhcp6c code changes causing IPv4 and IPv6 sequence mismatches, additional use of Netmap (suricata and zenarmor) or modem interaction on the plugged WAN link.

6b28dae2 tries to address some of these issues by moving IPv6 setup to PPP linkup time, not generic IPv4 renewal time (which is called much more often).

6b28dae2 should be safe enough, you can run the patch command again and it will be removed. the patch is also cached so it's easy to recover from no connectivity due to patches. But this patch has been extensively tested so I don't think it would be worse than before.


Cheers,
Franco

Hi Franco,

unfortunatley a "opnsense-patch 6b28dae2" did not fix the problem. See attached dhcp6c log.

Not sure if it is worth mentioning, but my "wan" interface is getting a IPv6 address, just the PD part is broken.

Best regards
Robert

As I see it it's asking multiple times, also interrupted due to SIGHUP reconnect, getting multiple answers but eventually refusing to give out another prefix and that's where it stops as expected.

Do you have a idea or at least a speculation what causes this? I mean, as written in the OP, ISP is the same and it worked before. As well with PPPoE and IPv6 together.

Maybe really some hidden magic which is bound to the interface name "wan"? Thats the only config change I've done as far as I can see.

Seeing that PPPoE is involved I'd like to ask you to try the following:

Ok, will check tomorrow if this is applicable.

A simple "opnsense-patch 6b28dae2" should be enough?

How likely is this to break stuff or being irreversible?

Best regards
Robert

What's odd here is the claim that 24.7.1 is the bad version, when in reality only 24.7.2 changed dhcp6c and there is something weird going on there (see other thread). Sure, 24.7.1 introduced other problems, but the triage here just doesn't feel consistent.

As far as packet captures go that's pretty useless since we need to know what dhcp6c does. Enable debug under System: Interfaces: Settings and reboot. The dhcp6c logs tell us about all the communication that is being done (and why) and in most cases where a prefix is missing the server will likely not have sent it in the first place.


Cheers,
Franco

Hi Franco,

please find the requested log attached. As far as I can see there is a /56 prefix (I removed some parts of it, wasn't sure about privacy) occurring in the log, but later it says contains no prefix. Weird.

Do you have an idea how to go on?

Thanks and best regards
Robert