[SOLVED] 24.7.4 Erratic PPPoE IPv6 Problems

[REB00T]

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!

[REB00T]

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.

[REB00T]

Also, running opnsense-revert -r 24.7.3 dhcp6c fixes my ipv6 issues...

[REB00T]

The IPV6 issue seems erratic, will continue monitoring for the time being. The dashboard timeout issue remains.

[REB00T]

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.

[franco]

> 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

[REB00T]

> 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.

[franco]

>  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

[REB00T]

>  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.

[REB00T]

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

[franco]

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

[REB00T]

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...

[franco]

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

[REB00T]

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.

[franco]

What's the reason for the WANPARENT interface if I may ask? And what IPv4/IPv6 config does it have?


Cheers,
Franco