radvd - enhancement proposal: ability to advertise routes and some fixes - patches attached
I was configuring radvd on two back-to-back firewalls with an in-between subnet and I was missing the feature to be able to push static IPv6 routes for subnets behind the back firewall to the clients in this subnet - which I was doing with DHCP option 121 and 249 in the IPv4 world.
My research led me so far, that I needed to configure radvd to push out the routes to the clients, and I set out to enhance pfsense with this feature.
While patching the code, I also noted, that radvd.conf would not include any additional RA subnets and and DNS suffixes configured on the web interface, so I fixed that on the way.
My changes would introduce a new sub-section called "routes" under the section "dhcpdv6" in config.xml as shown in this example:
I would be very happy if my enhancement and fix proposals would be help-/useful and if they would make their way in some form into a future release. Please do not hesitate to ask me if there are open questions.
My version is 2.1.3-RELEASE (i386).
Updated by Marc Posch almost 6 years ago
I have upgraded my pfsense box to 2.3.1 finally, since I have seen that there were major changes in the web interface, which would need a major rework of the patch.
Finally I have updated my enhancement patch to the current 2.3.1 version, I plan to update this ticket every time with a new patch version if the new pfsense version needs an updated patch. I will look into Github and how to officially submit it to the pfsense project in near future, as some have suggested this in the other tickets I had before.
Some words about the changes/additional features in pfsense-helpers.js:
- I needed a second repeatable groups on services_router_advertisements.php. So this patch adds the support for multiple repeatable row groups.
If one needs to create a second repeatable group on a page, he will just need to add a suffix to the control's id/name.
In this example the 'addrow' becomes 'addrow_routes', the 'deleterow' becomes 'deleterow_routes' and the 'repeatable' class becomes 'repeatable_routes'. You can use any name, just be sure it is suffixed with an underscore. The getRowGroupName contains a regex which will look for the underscore.
- I know I should file a separate bug report about this, but this happens only if using more than one repeatable group - so it only fits here.
If someone else comes across this feature request and wants to try it out:
If you have the "System Patches" package installed you can cleanly apply and remove this patch with version 2.3.1 - provided you don't have other patches installed, which modifies one of the following files: services.inc, services_router_advertisements.php, or pfsense-helpers.js.
Updated by Jim Pingle over 2 years ago
Can you submit this as a pull request on github, rather than attaching patches?
Updated by Magnus Holmgren about 2 years ago
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.
Updated by Marc Posch about 2 years ago
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?
Updated by Marc Posch about 2 years ago
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.