Core: LAN ipv6 track interface does not work when WAN v6 prefix changed

[gk998]

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md

[x] I have searched the existing issues and I'm convinced that mine is new.

My opnsense setup does receive its WAN v6 prefix via dhcpv6. Unfortunately my ISP gives me a dynamic v6 prefix.
LAN is configured as "track interface". Now everytime when there is a reconnect on ISP side, the LAN v6 connection doesn't work again. It still has the old prefix and advertises that to the LAN. The WAN interface is perfectly fine and ping6 google.com from the opnsense CLI works.
I found out that configctl interface reconfigure fixes the problem immediately. The only downside here is that the clients do not lose their old prefixes.
I already searched the forums and found similar issues, but no solution yet. I use the latest 20.7.7 version.

[buergi]

I have exactly the same problem from time to time. I'm not sure since when exactly, but I never noticed IPv6 related problems in the past and I haven't recently changed any configuration so either it might have been introduced with one of the last updates, or my provider changed something. I'm currently running 20.7.7_1-amd64.
The problem is very obvious in the network as all clients are extremely slow as they try connecting via IPv6 at first until a timeout happens and then possibly try again using IPv4.

Here the relevant section from the WAN interface when the problem is present. The WAN interface has two IPs, the old one (blue) and the new one (green). All clients in my LAN still use the old prefix and thus don't get any responses from foreign servers.

After pressing the DHCP reload button the old IP is gone and everything is working again for an undefined time

It might have something to do with preferred/valid IPv6 addresses. However, I'd expect even if the "old prefix" is not preferred any longer it should still work.

[ivwang]

I cannot be certain but suspect the issue partly is related to #4338 since the RA should be sent out with zero valid and preferred lifetime (RFC7084 sec. 4.3 L-13) when such prefix delegation change happens, so that LAN client knows the prefix is not in effect anymore. and subsequent Router Solicitation will supplement them with new prefix.

These actions hinge on a reliably working router advertisement daemon. My current workaround is periodically renew WAN and following with a radvd restart cronjob after a short delay. (the "invalidating old prefix" RA may still miss but at least RA with new prefix gets out as soon a possible)

Waiting for 20.7.8 or 21.1 to see if I can kill the workaround.

[fichtner]

So when using DHCP v6 there is no mechanism to look for a prefix change. I tried to research how other projects deal with this but you can find a lot of dead ends in discussions basically saying the prefix change is not working, especially when the prefix change is forced ahead of the end of the lifetime.

If anyone has any real world solution please let me know...

Cheers,
Franco

[marjohn56]

@fichtner .. PM me on this.

[fichtner]

@marjohn56 you on IRC?

[marjohn56]

Can be... gimme a mo

[gk998]

Would be great if there is a proper solution. Perhaps a cronjob running every minute that checks for changed dhcp prefix on wan side would be sufficient. It's not great, but at least it should work.

[fichtner]

It's not that simple I can assure you. :)

[gk998]

But at least it works. Just tried it on 21.1rc1. Script checks v6 on wanif every minute. If that changes, the script runs a 'configctl interface reconfigure' and the lanif gets its new address and so do the clients. I also tried just restarting radvd, but that did not help.

[fichtner]

The problem is assuming the issue is simple and fixing it will cause many complaints quickly with restarting connectivity every minute in a loop for users who didn't know they had an issue. ;)

[gk998]

@fichtner Ok, now I understand what you meant :) I fully agree with you: This is an ugly hack and should not be implemented in opnsense. It just works for me locally.