Feature #3718
open
radvd - enhancement proposal: ability to advertise routes and some fixes - patches attached
0%
Description
Hi,
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:
<dhcpdv6>
...
<wan>
<ramode>managed</ramode>
<rapriority>medium</rapriority>
<rainterface>wan_vip31</rainterface>
<radomainsearchlist/>
<subnets>
<item>fdfd:3f23:25b0:128::/64</item>
</subnets>
<routes>
<item>
<destination>fdfd:3f23:25b0:101::/64</destination>
<priority>high</priority>
</item>
<item>
<destination>2001:xxxx:xxxx:101::/64</destination>
<priority>high</priority>
</item>
<item>
<destination>::/0</destination>
<priority>low</priority>
</item>
</routes>
</wan>
...
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).
Regards,
Marc
Files
| services_router_advertisements.png (56.8 KB) services_router_advertisements.png | Screenshot showing the added ability to define routes and priority | ||
| services_router_advertisements.php.patch (9.73 KB) services_router_advertisements.php.patch | |||
| services.inc.patch (5.25 KB) services.inc.patch | |||
| radvd-routes-enhancment.patch (17.1 KB) radvd-routes-enhancment.patch | |||
| radvd-routes-enhancment-2.3.2.patch (17.6 KB) radvd-routes-enhancment-2.3.2.patch | |||
| radvd-routes-enhancment-2.3.4.patch (18 KB) radvd-routes-enhancment-2.3.4.patch | |||
| pfSense-radvd.patch (16.9 KB) pfSense-radvd.patch | radvd-routes-enhancement-2.4.4.patch |
Updated by Chris Buechler about 8 years ago
- Category set to IPv6 Router Advertisements (radvd/rtsold)
Updated by Marc Posch over 7 years ago
Hi,
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 had to replace 'event.target.id' with 'this.id' in some places of the helper script. The reason is, that I noticed an inconsistency when using Chrome or Chromium: the browser would add a row to the first row group, even though the correct addrow button of the second row group was clicked. This happened in these browsers only, Firefox did not expose such behavior. I am no javascript or dom expert, but 'this.id' fixed this glitch, I hope it will not have side effects on other places.
- 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.
Regards,
Marc
Updated by Marc Posch over 7 years ago
Updated the patch for version 2.3.2.
Updated by Marc Posch over 6 years ago
Updated the patch for version 2.3.4.
Updated by Magnus Holmgren over 4 years ago
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.
Updated by Magnus Holmgren over 4 years ago
- File pfSense-radvd.patch pfSense-radvd.patch added
I've tried to update the patch for version 2.4.4 here.
Updated by Jim Pingle over 4 years ago
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
Updated by Magnus Holmgren about 4 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 4 years ago
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
Updated by Marc Posch about 4 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.
Regards,
Marc
Updated by Marc Posch about 1 year ago
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