Regression #14072
closed
No working IPv6 gateway if upstream RA does not contain M or O flags because rtsold does not execute script
100%
Description
On 23.01, rtsold is not firing the script at /var/etc/rtsold_<if>_script.sh unless the router advertisement received contains either the M or O flags.
On 22.05, the O script was executed even when the RA didn't have M or O set.
Because the script isn't executed, the router information doesn't get placed into /tmp/<if>_routerv6 or /tmp/<if>_defaultgwv6, so the firewall doesn't have connectivity through the interface.
Arguably the old behavior was a bug of sorts, because the parameters for rtsold only specify a script for -M and -O. There isn't a parameter to rtsold to execute a script when the RA is only a router, even though that should be usable as a gateway. Unfortunately users have no control over the messages sent by their ISP, so changing the upstream isn't a viable workaround.
The only relevant src change I see is in usr.sbin/rtsold/rtsol.c in the FreeBSD src repo, where due to a change in where a bracket was placed, the script is now only executed when it is O and not M, whereas before it was executed any time M was not set. See 4cf4fd60dad3d6eb5ed50962aa58d157873a9f16 in the src repo which is the only commit I see making that change. It may have been from a previous local patch.
The easy fix would be to restore the old behavior, but we could also add a new flag to rtsold for a script to execute no matter which flags are set, or something along those lines. We execute the same script for M and O, so a combined parameter to always execute would also simplify things that way.
To replicate, set the upstream router mode to "Router Only" and put 22.05 and 23.01 systems behind that. 22.05 will have a working gateway, 23.01 will not.
Updated by Louis B over 1 year ago
I also think the RA behavoir is not OK! See my form post https://forum.netgate.com/topic/178423/some-doubts-about-router-advertisements/6
Updated by Jim Pingle over 1 year ago
Louis B wrote in #note-1:
I also think the RA behavoir is not OK! See my form post https://forum.netgate.com/topic/178423/some-doubts-about-router-advertisements/6
Your thread is not related to this issue. That thread is about RADVD behavior, this issue is for rtsold.
Updated by Ricardo Mendes over 1 year ago
Hi there,
I initially posted about this issue on the forums and would like to leave a suggestion here;
Since the current behaviour introduced by the update is what we'd consider to be the "correct" behaviour, I would suggest adding an option to override the default behaviour and run the above mentioned script regardless.
So the default behaviour "as is", and selecting the option overrides that default behaviour.
Updated by Jim Pingle over 1 year ago
Ricardo Mendes wrote in #note-3:
Since the current behaviour introduced by the update is what we'd consider to be the "correct" behaviour, I would suggest adding an option to override the default behaviour and run the above mentioned script regardless.
So the default behaviour "as is", and selecting the option overrides that default behaviour.
That's part of what I proposed in the description above with the additional script to run unconditionally. Using a script is the only way we have to get the router info from rtsold to a format usable by pfSense code, so ideally we'd run a script no matter what the flags are there and then maybe only optionally run the usual non-default-gw dhcp6c parts when M/O flags are present (with an option to force that to always run).
We should always at least get the router info since that is correct so long as the packet has a router flag set for the prefix (which IIRC it would or rtsold wouldn't consume it, but I'm not 100% sure on that). The debatable part is whether or not we should always launch dhcp6c without M or O since by the spec there shouldn't be DHCP on the link without M or O.
Updated by William Blew over 1 year ago
This issue impacts Canadian Telus PureFibre [native IPv6 over fibre to the house] residential customers.
Telus implements DHCPv6 Prefix Delegation, but without Individual Address Assignment.
Thus pfSense provides a GUA address to the LAN side interfaces, while the WAN interface has only its link local address. In this case, would pfSense require dhcp6c, even (presumably?) without either the 'M' or 'O' flags?
I ask, because I am a Telus PureFibre customer, and am affected by this bug.
I would be happy to do some testing. With some instructions, I'd be happy to provide a WAN pcap capture of my use case.
I have put a watch on this issue...
Updated by Jim Pingle over 1 year ago
If it worked before but does not work on 23.01, then it probably does require forcing dhcp to launch when M/O are not present. If you want to dig into specifics, the forum is a better place to discuss that in case it ends up not being directly related.
Updated by Kristof Provost over 1 year ago
Proposed rtsol change: https://reviews.freebsd.org/D39931
(We'll also need a change in the PHP code to set '-A' rather than '-M' and '-O' once this gets merged.)
Updated by Jim Pingle over 1 year ago
- Status changed from New to In Progress
- Assignee set to Kristof Provost
Updated by Kristof Provost over 1 year ago
I've merged the rtsol change to our branches and propose this PHP tweak: https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/1035
Updated by Kristof Provost over 1 year ago
- Status changed from In Progress to Feedback
- % Done changed from 0 to 100
And Jim merged that, so this should be fixed in the next snapshot.
Updated by Jim Pingle over 1 year ago
- Status changed from Feedback to Resolved
Tested latest Plus (23.05.b.20230503.0600) and CE (2.7.0.a.20230503.0600) snapshots and both are working well with the new option/behavior. Before upgrading, none of the four test systems had a working IPv6 gateway, after upgrading all four showed the expected gateway and were actively monitoring it as online.