pfSense

Any interest in implementing this? I find it a bit lacking that the UI doesn't support configuring what routes to advertise. In the case of DHCPv4, you can at least add raw options.

Can you submit this as a pull request on github, rather than attaching patches?

https://docs.netgate.com/pfsense/en/latest/development/submitting-a-pull-request-via-github.html

I'm about to submit a PR now. However, there's one issue I'd like to figure out first:

The info text added by the patch says "If you need a default route, specify it with ::/0 here. If no routes are specified here, the Router Advertisement (RA) Daemon will advertise only the default route.". Indeed, no ::/0 block will be added to the generated radvd.conf if specific routes are defined here, and no ::/0 route is advertised. However, the Linux VMs getting the RAs add a default route via the router anyway. Is there some other option that needs to be toggled or is Linux doing it wrong? Router mode is set to Router Only.

OK, I figured it out. AdvDefaultLifetime needs to be set to 0 (i.e. the Router lifetime box). Should the info text mention this?

Pushed as https://github.com/millnet-maho/pfsense/commit/radvd-multiple-routes for now.

Hello Magnus,

I am glad that you found my enhancement useful and updated it for the 2.4.4 version.
I didn't mention that I have applied your updated patch as soon as I have received the status update on this enhancement request, and everything is working fine since last year.

I am sorry for not having replied so far - spare time is rare time :)
I have created a GitHub account in December and was planning to do what you just did, but I ran into on some theoretical issues and open questions, and didn't find enough time in the Christmas holidays to seek answers, therefore I had to suspend things.
It was clear that you would advance at some time, so your update now was something like a wakeup call ;)

Regarding your question: I have checked things more thoroughly and have the same behaviour: I always get the default route on the client, regardless if it is in the config file or not. And I cannot reconstruct the behaviour with the Router lifetime box set to 0. The client always gets a default route, even if there is a frontend firewall radvd advertising the default route with priority high and a backend firewall advertising only routes to particular subnets - the client always gets an additional default route to the backend firewall. Maybe that's the reason why I had configured a default route with priority "low" on the backend firewall.

Maybe this behaviour needs to be tested more thoroughly with different operating systems, as I was not able to turn it off here.

One last request: could you please contact me at mposch-at-gmail-com before submitting your pull request?

Regards,
Marc

A short update:
The Router lifetime/AdvDefaultLifetime point tortured my mind last night.
Today I did some experiments with the setting set to "0" and found, that it really helped with the backend firewall:
According to the radvd man page and additional Wireshark traces, the backend firewall expectedly stopped advertising a default route, when no default route is configured in the routes section and the above value is set to 0.
This also helped to generally stabilize IPv6 in my back-to-back firewall setup with the client being in between both. It seems that when the backend firewall adverstised a default route albeit with low priority, this sometimes confused the client and triggered a loss of both default routes every now and then until the next router advertisement arrives. Although, from time to time I could also see both default routes with different priorities/metrics in the routing table.
But since I have set this to 0 on the backend firewall, IPv6 is much more stable on the client (Win 10).
Thank you for bringing this up.

I would therefore suggest some additional info as you suggested at the Router lifetime label, something like: "Set this to 0 if you don't want a default route to be advertised. Else, set a lifetime in seconds or leave this blank to use the default value (3*Maximum RA interval)".

I would submit the next patch for this here, but I don't want to be cautioned again.
We should really find a way to work together on this patch set.

Regards,
Marc

Finally did my homework to learn some github terminology and find out how to edit code and submit pull requests - yay!
This feature request would have celebrated its 10th birthday if it would have lasted another year. :)

Submitted pull request https://github.com/pfsense/pfsense/pull/4631.
Tested with several different pfsense versions before including the current 2.6.0 version.
Hope I did everything correctly.

Best regards,
Marc