DHCPv6 prefix not updated after nightly forced disconnect

[astronaut]

I have DSL internet with forced disconnect (access is provided by a DLS modem, not via PPPoE) and get new IPv6 address and prefix after each nightly reconnect. Since an update to 23.1, I am having issues with DHCPv6 PD after a disconnect. The obsolete IPv6 prefix is somehow still delegated, whereas downstream routers get a correct IPv6 address. Downstream clients (behind the downstream router) hence don't get a correct IPv6 address and have no IPv6 connectivity.  In my logs, I can find an error, I don't know if it is related:

Code: [Select]

/usr/local/opnsense/scripts/dhcp/prefixes.php: The command '/sbin/route add -inet6 '2003:d2:2018:f4e1::/60' '2003:d2:2018:f4d1:xxxx:xxxx:xxxx:xxxx'' returned exit code '1', the output was 'route: writing to routing socket: Network is unreachable add net 2003:d2:2018:f4e1::/60: gateway 2003:d2:2018:f4d1:xxxx:xxxx:xxxx:xxxx fib 0: Network is unreachable'
I suspect that OPNsense somehow misses the prefix change.

Restarting the DHCPv6 service doesn't fix the issue. Rebooting OPNsense solves the issue until some unknwon time after the next disconnect.

Other reported issues which might be related:

https://forum.opnsense.org/index.php?topic=32259.0
https://forum.opnsense.org/index.php?topic=32263.0

Anything I can do to help fix this issue?

[astronaut]

Things have not changed, I am rebooting OPNsense each morning to get IPv6 PD working again. Enabling "Interfaces: Settings: Prevent release" does not help.

Therefore, I am planning to revert to 22.7. Are there any specific logs and/or files I need to save to compare behavior in 22.7 and 23.1 and help finding the cause for my issue?

[Thorror]

I have the same issue.
The interfaces get the right IPv6 prefix but it does not reach the clients.
Only a restart of dhcpd6 and radvd after the disconnect/reconnect helps (or a reboot)
I reverted to 22.7

[agh1701]

Me to, after a cable modem reboot on v23.1_6.  dhcpd6 goes down.  Must restart radvd and dhcpd6

[sclevine]

I think this is also related to the issue I'm experiencing in:
https://forum.opnsense.org/index.php?topic=32231

I suspect it has something to do with these changes in rc.newwanipv6, but not sure:
https://github.com/opnsense/core/compare/22.7..23.1#diff-f75df381ea54006769fdb7e552994d8d709ff9f9d71eb739db6311b6179f44f7R87

[astronaut]

I reverted to 22.7.11_1, prefix delegation is working again.

[agh1701]

@franco, can you help? What logs should I collect to file a bug report?

Thanks,
Al

[guest34985]

I can confirm. Had a couple of resyncs of my cable modem because of maintenance the ISP did. Need to restart radvd now in order to have clients fetch an IPv6 address from the delegated Prefix (SLAAC). No DHCPv6 in use so I can't verify this part myself.

[agh1701]

did you have to start dhcpd6?

Never mind I see you are not using dhcpd6.  Duh!

[astronaut]

I updated to 23.1.2 two days ago.

Today, regular disconnect (and therefore new IPv6 prefix) happened at about 4:00 A.M. IPv6 connectivity came up at about 6 A.M. Everything seemed to be working o.k. during the day.

Then another (unregular) disconnect happened at around 21:00 due to some DSL issue. After reconnect (and new IPv6 prefix), IPv6 connectivity was lost again. I checked the OPNsense system, and it showed in WAN interface and in DHCPv6 the deprecated prefix. The WAN interface itself had an IPv6 address from the new, correct range, it was just the prefix which was deprecated. After approx. one hour, I restarted the WAN interface, and IPv6 connectivity was restored. The prefix was from the correct range. I verified by manually requesting a new IPv6 prefix in the DSL router, with the exact same behavior. Default routes stay in place, no issue there.

TL;DR: It seems that upstream IPv6 prefix updates take around two hours to reach the downstream systems. This seems quite long to me. Is there a way to speed up this process?

[astronaut]

Just an information for the afterworld: I am on 23.1.5_4 right now. The situation regarding IPv6 prefix update seems to be stable. There is still some delay until the new prefix is delegated each night. I estimate this delay to be 1-2 hours, and that seems a little long to me. Other than that, IPv6 is working reliably.

[astronaut]

Another update: Meanwhile, I'm on OPNsense 23.1.9. Also, I changed my setup and made the downstream router (OpenWRT) into an access point without any routing tasks. This means prefix delegation is not necessary anymore. I therefore can't tell if the original issue has been solved. Anyway, the nightly new IPv6 prefixes arrive at the clients much faster than before.

Sidenote: I have the impression that getting rid of the additional downstream router has made everything a bit "snappier", i. e. DNS lookups, browsing, etc. seem to be a little bit faster. Also, I'm having less complex setup with regards to routing, no double NAT, no double firewall rules etc. Many of my network devices still run OpenWRT, but without routing tasks.

Thank to the team for this nice piece of open source software!

[Cyberturtle]

Version 23.1.8 and 23.1.9 changed a lot for IPv6. If you’re interested in updating the prefix on the clients via router advertisements a bit faster I can share my settings. I have modified the default values according to RFC and dynamic prefixes (even it was initially designed for 6to4).

[Taunt9930]

Version 23.1.8 and 23.1.9 changed a lot for IPv6. If you’re interested in updating the prefix on the clients via router advertisements a bit faster I can share my settings. I have modified the default values according to RFC and dynamic prefixes (even it was initially designed for 6to4).

I'd be quite interested in learning what you have done, if you don't mind? Thanks.

Sent from my SM-S918B using Tapatalk

[Cyberturtle]

Here are my settings. The reason behind the values is to ensure that dynamic prefixes are changed a way more faster than with default settings. Especially sometimes a few wireless clients are not getting the advertisments on the first broadcast when the prefixes changes. The short values ensure that the prefix is being changed at least after five minutes. If the prefix is the same the client extends the valid lifetime.
Since upgrading to 23.1.8/23.1.9 using the short lifetimes ensures proper IPv6 handling with dynamically assigned prefixes (track interfaces).
According to RFC the short values are originally designed for 6to4 interfaces, but it also works for my (our) use case. 

Maybe we could improve the backend handling of prefix changes that way, that if the prefixes changes both prefixes are handed out via router advertisments for about 2-3 times. The deprecated one with AdvDeprecatePrefix and the new one like always. So that way we can use the default advertisment settings and take care that few wireless clients still receive the deprecated message on the second or third broadcast?