dhcpd6: missing route with two prefixes delegated to the same DUID

[aque]

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/core/blob/master/CONTRIBUTING.md
• [x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug I have a lab OPNsense downstream from my production OPNsense system - both are running 24.1.7_4. The lab system requests 2 /62 prefixes and were successfully delegated two. But, the upstream system only shows 1 route entry instead of 2. “Delegated Prefixes” on the upstream system shows the same exact DUID with one prefix having IAID = 0, and the other IAID = 1. The higher IAID seems to consistently win in getting its route entry added. I suspect the same DUID value causes one prefix to overwrite the other.

To Reproduce Steps to reproduce the behavior:

1. Set up the upstream system to delegate multiple /62 prefixes
2. Create a custom /var/etc/dhcp6c_wan.conf file with the following:

interface em0 {
  send ia-na 0;
  send ia-pd 0;
  send ia-pd 1;
  request domain-name-servers;
  request domain-name;
  script "/var/etc/dhcp6c_wan_script.sh";
};
id-assoc na 0 { };
id-assoc pd 0 {
  prefix 2603:3018:xxxx:xx34::/62 infinity;
};
id-assoc pd 1 {
  prefix 2603:3018:xxxx:xx38::/62 infinity;
};

3. Set up the downstream WAN interface to use the custom dhcp6c_wan.conf file.
4. Reboot downstream system and confirm prefix delegation
5. IPv6 route table of upstream system only shows one route entry instead of two.

Expected behavior Two route entries - one per delegated prefix.

Environment Production/Upstream system: OPNsense 24.1.7_4-amd64 Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz Network igb driver

Downstream/Lab system: OPNsense 24.1.7_4-amd64 Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz Network em driver

[fichtner]

Hey @aque,

So this is a custom dhcp6c config file mode WAN? In that case we have at least 2 issues that we need to unpack.

I know there’s an issue with multiple PD given by the ISP where we really only use one, but the larger problem is getting you off the custom config if possible because we can’t make any guesses about its content and derive action for tracking interfaces.

Cheers, Franco

[aque]

Hey @fichtner,

Yes, this is using a custom dhcp6c config file mode WAN. I pasted its contents above with part of my prefixes obfuscated. I am trying to lab how I can use multiple prefixes. The downstream system with the custom dhcp6c is not where the problem lies though. In this case, the delegating system is also running OPNsense so my ISP is not involved. That is where the single route entry problem is.

I hope this diagram helps. OPNsense A only has one route entry and it is unable to route traffic destined for the other prefix.

+---------------+                         
|  OPNsense A   | Route entry:            
|  delegating   | 2603:3018:xxxx:xx38::/62 -> OPNsense B WAN
+-------+-------+                         
        |LAN                              
        |                                 
        |                                 
        |WAN                              
+-------+-------+ Delegated:              
|  OPNsense B   | 2603:3018:xxxx:xx34::/62
| custom dhcp6c | 2603:3018:xxxx:xx38::/62
+---------------+                         

[fichtner]

So we are missing the second entry in OPNsense A? That would be a problem in prefixes.php then

[fichtner]

Can you grep for this please?

# opnsense-log dhcpd | grep -i iaprefix

It might be logging the PDs in a single line and we're missing the other one therefore.

[aque]

I got no results grepping for iaprefix, but prefixes.php looks to be the problem area.

I have the following in /var/dhcpd/var/db/dhcpd6.leases:

ia-na "\000\000\000\000\000\001\000\001,4\230\021\000\014)X\345\226" {
  cltt 1 2024/05/27 17:19:54;
  iaaddr 2603:3018:xxxx:xx20::a1b1 {
    binding state active;
    preferred-life 4500;
    max-life 7200;
    ends 1 2024/05/27 19:19:54;
  }
}

ia-pd "\000\000\000\000\000\001\000\001,4\230\021\000\014)X\345\226" {
  cltt 1 2024/05/27 17:19:54;
  iaprefix 2603:3018:xxxx:xx34::/62 {
    binding state active;
    preferred-life 4500;
    max-life 7200;
    ends 1 2024/05/27 19:19:54;
  }
}

ia-pd "\001\000\000\000\000\001\000\001,4\230\021\000\014)X\345\226" {
  cltt 1 2024/05/27 17:19:54;
  iaprefix 2603:3018:xxxx:xx38::/62 {
    binding state active;
    preferred-life 4500;
    max-life 7200;
    ends 1 2024/05/27 19:19:54;
  }
}

I think $duid = implode(':', $iaid_duid[1]); pulls DUID but not IAID causing the overwrite. $duid_arr only has one entry:

    [00:01:00:01:2c:34:98:11:00:0c:29:58:e5:96] => Array
        (
            [address] => 2603:3018:xxxx:xx20::a1b1
            [prefix] => 2603:3018:xxxx:xx38::/62
        )

But, since it relies on ia-na to set the [address] array element, it's not as simple as extending $duid to include IAID.

[fichtner]

Just means the log rotated and you don't have any results in latest.log. Can you check all of /var/log/dhcpd/*.log ?

[aque]

Do I need to increase verbosity somewhere?

root@gw:~ # grep -i iaprefix /var/log/dhcpd/*.log
root@gw:~ # 

[fichtner]

Argh, sorry I misread. iaprefix is in the leases file you posted! Let me take a closer look in a bit.

[aque]

All good @fichtner. I don't see a quick and easy solution though. But then again, I'm not a developer. 😁

Edit: Been thinking about this for a while...how about turning [prefixes] into an array with IAID as its index?

[fichtner]

Yep, see a45daec

 # opnsense-patch a45daec

Does this work for you?

Cheers, Franco

[aque]

Looks good! Here's the route table entries! That was quick. Now, I have to figure out how you did that. 😆

2603:3018:xxxx:xx34::/62          2603:3018:xxxx:xx20::a1b1     UGS        igb2
2603:3018:xxxx:xx38::/62          2603:3018:xxxx:xx20::a1b1     UGS        igb2

Thank you!

[fichtner]

I think address is a singular entry but I know that prefix can be dashed out in larger quantities if needed. Just turn the prefix into an array and expand it when scanning the routes. The DUID mapping was already perfect as far as I can tell (all three entries land in the same key).

This is easy enough to bring into the next release on Wednesday. Thanks a lot for the report and details!

Cheers, Franco