The setup I was using before was a PPPoE interface on top of a plan specified by my ISP. I would then configure IPv6 for that interface with DHCPv6 with a /56 PD size and use ipv4 connectivity checked. Then I would configure my LAN interfaces using track interface for ipv6. After 24.7.4 none of the interfaces or the devices in their respective subnets receive an ipv6 address. The wan interface itself has a /64 as it did before.
Should also note that clicking "Apply changes" on an interface configuration screen results in a timeout, a behaviour it did not exhibit before. Lastly, the firewall is reachable from the Lan after about 2 and a half minutes of uptime. Before that not even pings are returned. I do not believe that happened before.
Happy to provide more details!
While the other interfaces not getting an IPv6 address could happen before, it was very rare and a reload of the PPPoE interface usually fixed it.
Also, running opnsense-revert -r 24.7.3 dhcp6c fixes my ipv6 issues...
The IPV6 issue seems erratic, will continue monitoring for the time being. The dashboard timeout issue remains.
Can confirm the described issues persist.
Even after applying:
# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/snapshots/misc/dhcp6c-20240907_2.pkg
The wan interface gets no "Dynamic assigned prefix" from my ISP using the same configuration that was working before 24.7. Any help is appreciated.
PS. It seems to get a prefix after an hour or so. Still seems like a regression considering the previous behaviour.
> opnsense-revert -r 24.7.3 dhcp6c fixes my ipv6 issues...
That's weird. Because it won't do anything if you don't reboot.
To be honest I'm not sure what your issue even is. 24.7.4's dhcp6c should be fine. You may have an operational issue with your router or provider.
Cheers,
Franco
Quote from: franco on September 17, 2024, 08:19:17 PM
> opnsense-revert -r 24.7.3 dhcp6c fixes my ipv6 issues...
That's weird. Because it won't do anything if you don't reboot.
I did a reload on the WAN interface right after applying that and it picked up a prefix right away. With the (I believe) newest patch applied it needs a lot of time after a reboot to pick it up. I am leaning towards a firewall issue instead of an ISP one based on the fact that this behaviour didn't exist before, and remains consistent even with back to back tests between versions.
My ISP is a greek one named COSMOTE.
Since it seems to sort itself out after admittedly a fairly big delay it is nothing show-stopping for now. If it gets worse I will provide an update.
> did a reload on the WAN interface right after applying that and it picked up a prefix right away.
My point here is you replace the binary but it is not restarted, only SIGHUP is used. So whatever you see is an inherent issue and you're not seeing the effects of a revert because the new binary is not run.
Get everything on 24.7.4 (health audit to check), then reboot and provide the system log.
Thanks,
Franco
Quote from: franco on September 19, 2024, 09:49:04 AM
> did a reload on the WAN interface right after applying that and it picked up a prefix right away.
My point here is you replace the binary but it is not restarted, only SIGHUP is used. So whatever you see is an inherent issue and you're not seeing the effects of a revert because the new binary is not run.
Good to know. Will do.
This is right after a reboot with all patches reverted and a health audit run, confirming everything is as it should be. No prefix has been picked up yet.
PS. IPs have been censored
The only thing that pops out is that you have at least four tracking LANs for the IPv6 which isn't bad by itself, but may be problematic the way it's currently resolved in an iterative fashion. Currently working towards reloading all in one go which can help with timing.
Can you repeat the log with a clean reboot with the debug mode set for DHCPv6 (Interfaces: Settings). The relevant information on prefixes and what the upstream router thinks about the requests is not included in the last log.
Cheers,
Franco
Quote from: franco on September 19, 2024, 04:49:30 PM
The only thing that pops out is that you have at least four tracking LANs for the IPv6 which isn't bad by itself, but may be problematic the way it's currently resolved in an iterative fashion. Currently working towards reloading all in one go which can help with timing.
Should I go about providing IPv6 addresses to those vlans another way? Do you have any suggestions? Still learning...
Oddly enough what happens is that the server initially answers your solicit with an advertise of a PD but never replies to the actual request for the lease. After the 10th time the request times out as per maximum count of retransmissions of the RFC.
Maybe something blocks ICMPv6 in this case. I'm seeing crowdsec here, worth a try without it.
Another thing to try would be to see if the firewall discards these packets for whatever reason.
Also you are using DHCPv6 on the parent hardware interface and the PPPoE at the same time?
Cheers,
Franco
I will try without crowdsec. I am using PPPoE and DHCPv6 on the pppoe0 interface, not on the parent plan of the pope interface nor the parent (physical) interface of both.
What's the reason for the WANPARENT interface if I may ask? And what IPv4/IPv6 config does it have?
Cheers,
Franco
At least in previous versions, if the interface wasn't assigned Hardware CRC, LRO and TSO remained enabled. Ipv4/Ipv6 is none/none. With crowdsec disabled and having reloaded the interface no ipv6 prefix is picked up.
Ok, fair point. Though that is no longer needed today.
Next step would be to add an IPv6 pass rule for ICMPv6 on the WAN interface for testing purposes to see if the traffic is silently dropped somehow. You could also enable logging of default rule blocking (Firewall: Settings: Advanced) to see if it pops up in the live log.
Cheers,
Franco
So after just waiting, no prefix is picked up. But upon hitting save and applying in the interface configuration screen a few times it does get a prefix. Having left it alone for a long time it did not seem to work without the above procedure.
PS. No ipv6-icmp traffic gets logged as dropped/rejected and the allow rule did not get hit.
Curiously, subsequent reloads and the above procedure do seem to work. The prefix gets picked up again fairly consistently.
After a reboot with crowdsec enabled, after a significant amount of time though, the problem appeared again. Then another reboot after disabling crowdsec, the problem persists. I do not think it is some kind of rate limiting from my ISP because the back to back tests before behaved fine. Anything stand out in the logs?
Can you share the PPP log as well? Maybe it's similar to https://github.com/opnsense/dhcp6c/issues/39
Thanks,
Franco
Left it alone last night with crowdsec disabled. Nothing has changed. Attached the pppoe log.
This is a bit odd:
2024-09-19T22:22:05 Informational ppp [opt3] IFACE: Rename interface ng0 to pppoe0
2024-09-19T22:22:05 Informational ppp [opt3] IFACE: Up event
2024-09-19T22:22:05 Notice ppp ppp-linkup: executing on pppoe0 for inet
2024-09-19T22:22:05 Informational ppp [opt3] xxx.xxx.xxx.xxx -> xxx.xxx.xxx.xxx
2024-09-19T22:22:05 Informational ppp [opt3] IPCP: LayerUp
According to the log ppp-linkup is calledbefore ng0 is renamed to pppoe0, but it's already told the interface name is pppoe0. In theory that's asking for trouble, but I've never seen someone raise such an issue before.
Cheers,
Franco
Quote from: franco on September 22, 2024, 09:57:06 AM
This is a bit odd:
2024-09-19T22:22:05 Informational ppp [opt3] IFACE: Rename interface ng0 to pppoe0
2024-09-19T22:22:05 Informational ppp [opt3] IFACE: Up event
2024-09-19T22:22:05 Notice ppp ppp-linkup: executing on pppoe0 for inet
2024-09-19T22:22:05 Informational ppp [opt3] xxx.xxx.xxx.xxx -> xxx.xxx.xxx.xxx
2024-09-19T22:22:05 Informational ppp [opt3] IPCP: LayerUp
According to the log ppp-linkup is calledbefore ng0 is renamed to pppoe0, but it's already told the interface name is pppoe0. In theory that's asking for trouble, but I've never seen someone raise such an issue before.
Cheers,
Franco
I don't think I have a peculiar configuration. There is a vlan on top of the physical WANPARENT interface, with pppoe0 on top of that.
I know, just something weird being observed there. Merging the ppp log into the system log would provide the means to fix that longterm. :)
Cheers,
Franco
I remember you writing that the relevant patch won't be in 24.7.5, but just to confirm, the behaviour seems to be the same. Otherwise smooth as always!
This was about the other dhcp6c fix, right?
Cheers,
Franco
I believe so
Ok you are still running that successfully or you need another build for it?
The update may have scrubbed the test package due to version change.
Cheers,
Franco
Haven't applied the patched build. The work around of requesting just a prefix works for now. Do you want me to test it?
Ok, can we retest to be sure? I built a new package and cleared the older dhcp6c test builds from the directory to avoid future confusion:
# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/snapshots/misc/dhcp6c-20240919_1.pkg
(and reboot)
Thanks,
Franco
Doesn't seem to get a prefix anymore (with request prefix only disabled). It used to with 24.7.4 with the same config.
Scratch that, it did pick up a prefix after 8 mins. Used to be much quicker. Don't think it is an ISP issue, as it is the first time I've seen it take this long.
> Used to be much quicker. Don't think it is an ISP issue
It's impossible to tell at this point with the random nature of reports even after shipping confirmed fixes. Mind you, you are testing the exact same source code.
Cheers,
Franco
I know. It hasn't occurred much since that report and is really minor. I consider this solved as the patch works. Thanks for the help and the work you are putting in the project! Good luck with the issue reports and I will probably be available to test anything that comes up. Cheers!
Ok, please be on the lookout for further CFTs for PPPoE or dhcp6c and thanks for your time. :)
Cheers,
Franco