Messages

Just for reference there is already a competing PR open for that feature:

https://github.com/opnsense/core/pull/9401

You can read for the general feedback in there and compare it to your approach.

Thank you for providing info that helped to find a bug and verify the prefix delegation with KEA.

I feel like you were the first one trying (that I read), so the feedback was very valuable :)

I would use GUAs as well, maybe the Fritzbox is weird here.

Anyway if the following is true its not a routing issue anymore:

-> KEA leased IA_NA and IA_PD to Fritzbox
-> KEA installed a route targeting the link local address of the Fritzbox
-> There are Router Advertisements sent to the Fritzbox
-> The IPv6 default route of the Fritzbox points to the OPNsense router

Though I probably cannot help more now if there's no bug to hunt anymore. Routing should be clean now.

(Also, setting the /48 GUA prefix in KEA does not mean it takes authority over it. You can safely do that, just be careful with the range you use for IA_PD so it doesnt overlap with what you use on the interfaces of the OPNsense and you are good.)

Okay so the routing from OPNsense to Fritzbox should be okay now.

Are you having Router Advertisements set up on OPNsense, so that the Fritzbox gets a default gateway advertised on the link its connected on (igc0).

https://forum.opnsense.org/index.php?topic=1542.msg4774#msg4774

Sorry for being short, not NL speaking :)

Yeah oops there was a typo in the link (commits instead of commit)

https://github.com/opnsense/core/commit/e4cc9e7f4d55f63f6669dcb2a81d21b53fa1117a

Try this link, if it opens in your browser it will also work as patch.

Hello, thank you, could you test the above patch on 26.1.1?

Go into the opnsense root shell (same spot you e.g. executed netstat on OPNsense) and execute the following patch:

Code Select Expand

opnsense-patch https://github.com/opnsense/core/commits/e4cc9e7f4d55f63f6669dcb2a81d21b53fa1117a
Afterwards try to restart KEA, or reboot, and check if the route is added now.

Hello, which OPNsense version are you using right now?

I feel like the scope ID is missing here when adding the route, but I want to double check on which script version you run (since it changed recently)

If its 26.1.1, I think this could be the issue: https://github.com/opnsense/core/pull/9778

That's the intermediate plan right now:

https://github.com/opnsense/core/commit/a92b4725789092d22c2fe8beb2ae433ec45f05c7

A real life usecase would be a Chromebook running Android Apps on it as VMs. Thats already out there in the wild.

So I would say as soon as a client becomes more of a hypervisor.

Guess like:

ISP -> "Real" Router -> "Semi" Router (Client) -> Actual consumer (VM)

Its cool that the clients want to do all that stuff but where is the server software implementation (better would be a combined dhcpv6 client + server that internalises the full running state) that can do this out of the box?

KEA doesnt even install routes for PD without a watcher python script crawling its lease database.

IPv6 is being made consistently more convoluted by stacking more and more concepts on top of each other.

My argument is more grounded inside the deployment reality of this, not the RFC suggestions.

Though this right now is an emotional argument. Im happy in my own RA only world due to personal projects that allow that :D

Patrick is right.

And to make it even more precise, the IPv6 setup could be configured statically entirely.

Static IPv6 on LAN/vlan etc.

Static route of a subnet (prefix) to the fritzbox.

Static IPv6 configuration on the Fritzbox WAN port.

Router Advertisements is all thats needed to advertise the default route.

No DHCPv6 server needed anywhere, only the WAN DHCPv6 Client configuration.

Essentially this is completely normal manual subnetting almost the same as IPv4.

I think you are mixing up concepts.

The DHCPv6 client already handles IPv6 prefixes you receive from the provider.

KEA is a DHCPv6 server, it just needs the correct configuration and it will work, and set the correct routes into the routing table.

I tested and verified that myself with a PPPoE setup in the same constellation as you above.

I assume a configuration error for now.

Hello, we can offer something soon. To track this better, could you maybe open an issue here:

https://github.com/opnsense/ports/issues

Our port is located here:

https://github.com/opnsense/ports/tree/master/opnsense/dnsmasq

Just FYI
https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg18193.html

Stuff like this etc...