IPv6 Gateway Issue (see issue 11454)
-
Plain old ethernet, no PPPoE.
Here are my settings for the WAN DHCP6 config:
What other debug/output can I get you?
-
First, uncheck all those boxes and save/apply, then reboot and see if the behavior changes.
At a minimum you won't need that first box as that's just for PPPoE weirdness.
About the only two you might need are the prefix hint and release option but those may not affect it either.
It's entirely possible it's a difference in your upstream as well, there was an
rtsold.cpatch on the Redmine issue which may be related to your case but unrelated to many of the others affected. We might be getting two different bugs with similar results confused here. -
Unchecked all of the boxes and rebooted, the IPv6 behavior did not change.
My WAN IPv6 address changed, my PD did not. Neither the /tmp/em0_routerv6 or the /tmp/em0_defaultv6 exist. The IPv6 default route exists in the routing table.
-
I think I'm seeing the same issue and almost any change to WAN interface triggers this error:
There were error(s) loading the rules: /tmp/rules.debug:311: no routing address with matching address family found. - The line in question reads [311]: pass in quick on $LAN1_PRIMARY $GWDefaultIPv6 inet6 from 2601:xxx:xxx:xxx::/64 to any tracker 1436634070 keep state label "USER_RULE: LAN1 -> any Default IPv6" @ 2021-03-16 16:30:47On reboot, the IPv6 gateway appears up, both WAN and LAN get IPv6 address, but there is no routing of IPv6 traffic. pfSense can ping IPv6 hosts, but no LAN side clients can.
Dashboard shows Pending, Pending, Pending, Unknown for the Gateway,
If I mark the IPv6 gateway as down, Apply, and then Mark it is Up I can get it to route IPv6 traffic correctly. Until I reboot and then it reverts to not routing IPv6.
-
Copying some info back here from Redmine for good measure:
There were two components that we found and fixed:
- A gateway learned via RA (without M or O) could be clobbered by later invocations of the script that lacked gateway information
- The script when invoked from M flags needed the gateway parameter added to pass the gateway through to the script processing the gateway data
The fix for #1 is in current RC snapshots, the fix for #2 was just committed and will make it into builds overnight.
I've been testing a patched
rtsoldwith the fix for #2 and have been able to confirm it works for me when RA is set to M+O and it did not work without the patched binary. I replicated the conditions and tested the fix on three separate lab systems.Hopefully this fixes it for you and others experiencing one or both of these problems.
-
FYI- This fix is in the current builds and is working for me as mentioned above.
-
It did fix the gateway problem, but now i don't have any states registered on Floating, LAN and WAN rules despite having traffic from WAN to LAN. The rules on WAN and LAN still seems to work as i can get online and the port forward i have seems to work, but fq_codel set up with floating pass rules doesn't work after upgrade to 2.6.0.a.20210318.0100. Anyone else seeing the same?
-
@jimp Thanks, Jim. As always, you’re awesome.
-
@bobbenheim said in IPv6 Gateway Issue (see issue 11454):
It did fix the gateway problem, but now i don't have any states registered on Floating, LAN and WAN rules despite having traffic from WAN to LAN. The rules on WAN and LAN still seems to work as i can get online and the port forward i have seems to work, but fq_codel set up with floating pass rules doesn't work after upgrade to 2.6.0.a.20210318.0100. Anyone else seeing the same?
No, please start your own thread with more information in the 2.6.0 category, this one is for 2.5.1/21.02.2 and any problems on 2.6.0 are likely unrelated to this.
-
@jimp
It has fixed the IPv6 Gateway issue, Thanks! But, I'm now seeing issues with Track Interface, I'll open up another thread.
