rc.newwanipv6 exits early if ISP only provides a prefix (no WAN ipv6) unless "Request only an IPv6 prefix" is checked

[emesterhazy]

Important notices

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

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

I am running version 24.1_1, but this also affected me on 23.7.12. I'm new to opnsense, so I don't have data from earlier releases.

If the ISP only provides an ipv6 prefix, but not an address to the WAN interface, the rc.newwanipv6 script exits early and does nothing. The main issue I'm having with this is that radvd is not reconfigured to advertise on the LAN, so clients do not get ipv6 addresses. If dhcp6 is enabled on LAN, it is also not reconfigured. Manually restarting radvd in the GUI fixes the issue and it begins advertising on the LAN.

The WAN ipv6 check in rc.newwanipv6 is here:

core/src/etc/rc.newwanipv6

Lines 81 to 84 in 0ab7a96

	list ($ip) = interfaces_primary_address6($interface);
	if (!is_ipaddr($ip)) {
	log_msg("Failed to detect IP for interface {$interface}", LOG_INFO);
	return;

Inside interfaces_primary_address6 there is a call to interfaces_has_prefix_only and if it returns true, the link-local ipv6 address is returned. Otherwise the function looks for a non-link local ipv6 address on the interface.

core/src/etc/inc/interfaces.inc

Line 4192 in 0ab7a96

if (interfaces_has_prefix_only($interface)) {

The problem is that the interfaces_has_prefix_only function only looks at the config. As far as I can tell it doesn't actually determine whether the ISP only assigned a prefix. In particular it looks for a dhcp6prefixonly tag in the dhcp6 section of the interface's config in /conf/config.xml.

core/src/etc/inc/interfaces.inc

Line 4106 in 0ab7a96

isset($interfaces_a[$interface]['dhcp6prefixonly']));

That tag is only present if the user checks the "Request only an IPv6 prefix" option in the interface configuration page of the GUI.

To Reproduce

Steps to reproduce the behavior:

1. Make sure that "Request only an IPv6 prefix" is unchecked in the WAN interface configuration.
2. Make sure that the ISP or upstream router only delegates a prefix to the opnsense machine and not a WAN ipv6 address.
3. Set LAN to "Track Interface". Optionally allow manual dhcpv6 adjustments and set to "Unmanaged" mode for SLAAC only.
4. "Reload" the WAN interface in Interfaces > Overview or restart opnsense.
5. radvd will not be advertising a /64 on the LAN interface and you will see complaints from rc.newwanipv6 in the logs.

2024-02-04T12:46:40   Notice   opnsense   /usr/local/etc/rc.newwanipv6: Failed to detect IP for interface wan

Expected behavior

I expected the "Request only an IPv6 prefix" to only affect the solicitations opnsense sends to the ISP. I didn't expect it to be necessary to set this option for ipv6 to work correctly if the ISP only provides a prefix and no GUA wan ipv6.

Relevant log files

I have previously shared some logs in this thread on the forum.

Here's an excerpt where you can see that rc.newwanipv6 fails after dhcp6c_script sends a renewal request on the WAN interface (vtnet1 here). This is with the "Request only an IPv6 prefix" option unchecked.

2024-02-04T02:27:48   Notice   opnsense   /usr/local/etc/rc.newwanipv6: Failed to detect IP for interface wan   
2024-02-04T02:27:45   Notice   opnsense   /usr/local/etc/rc.newwanipv6: Failed to detect IP for interface wan   
2024-02-04T02:27:45   Notice   dhcp6c   dhcp6c_script: REQUEST on vtnet1 renewal   
2024-02-04T02:27:45   Notice   dhcp6c   dhcp6c_script: REQUEST on vtnet1 executing

2024-02-04T02:27:43   Warning   opnsense   /usr/local/etc/rc.configure_interface: dhcpd_radvd_configure(auto) found no suitable IPv6 address on lan(vtnet0)

2024-02-04T02:27:41   Notice   dhcp6c   RTSOLD script - Sending SIGHUP to dhcp6c   
2024-02-04T02:27:41   Notice   dhcp6c   dhcp6c_script: RELEASE on vtnet1 executing   
2024-02-04T02:27:41   Notice   opnsense   /usr/local/etc/rc.configure_interface: ROUTING: entering configure using 'wan'   
2024-02-04T02:27:41   Notice   dhcp6c   RTSOLD script - Sending SIGHUP to dhcp6c

Environment

OPNsense 24.1_1 (amd64).
Running in a VM with VirtIO network interfaces
The ISP is Verizon Fios

[fichtner]

Just as a preliminary question: if request only a prefix is checked it works as intended?

[emesterhazy]

Yes, if "Request only an IPv6 prefix" is checked then everything works properly, or at least I have not been able to reproduce the issue with that option checked.

I'm not sure if this is a bug or WAI. I will say that I burned up many many hours trying to figure out what the issue was before I dug into the code to figure this out. At a minimum we should update the documentation for this option to say that it must be checked if the ISP only delegates a prefix.

[fichtner]

Thanks for clarifying. We did remove a couple of technical edge cases over the years and detecting the link local as valid was one of the simplifications relatively recent. Maybe we can simplify this further. From what we know now there’s no downside of the approach.

[fichtner]

Can you try f1fbf81 + c7d6f53?

# opnsense-patch f1fbf81 c7d6f53

(revert again using same command)

I'll test this myself on my main setup the coming week. This might solve reported issues with PPPoE as well..

Cheers,
Franco

[fichtner]

Apparently also needs c7d6f53, I'll fix up the instructions above.

[emesterhazy]

I applied these patches and tried two things.

First, I disabled the "Request only an IPv6 prefix" and rebooted the machine. radvd seems to be advertising properly on the LAN and my devices have ipv6 GUAs.

Next I tried reloading the WAN interface through Interfaces > Overview. This also worked and radvd is advertising properly.

I'm also not seeing any logs like this now:

/usr/local/etc/rc.newwanipv6: Failed to detect IP for interface wan   

[fichtner]

Yep, looks good so far. There may be a tweak or two that we could make still, but need to ponder a bit about it and wait for other people's feedback.

[fichtner]

Due to lack of further feedback and generally working fine in real world environments let's put this in 24.1.5.

[emesterhazy]

Thanks for fixing :)