interfaces: SLAAC WAN improvements

[maurice-w]

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

If the WAN IPv6 Configuration Type is set to SLAAC, /tmp/$if_routerv6 doesn't get created - unless a (stateless) DHCPv6 server exists upstream. Without /tmp/$if_routerv6, features like gateway monitoring, gateway groups and policy-based routing don't work.
This might have never worked and is probably not a recently introduced issue.

To Reproduce

Steps to reproduce the behavior:

1. Set up two OPNsense instances. Connect the OPNsense2 WAN interface to the OPNsense1 LAN interface.
2. OPNsense1 LAN interface: IPv6 Configuration Type 'Static IPv6', IPv6 address '2001:db8::1/64', Router Advertisements mode 'Unmanaged', DHCPv6 server disabled
3. OPNsense2 WAN interface: IPv6 Configuration Type 'SLAAC'
4. See error on OPNsense2: WAN interface gets an IPv6 address, but /tmp/$if_routerv6 doesn't exist and 'System / Gateways / Single / WAN_SLAAC' doesn't show a gateway address.
5. On OPNsense1, change the Router Advertisements mode to 'Stateless' and enable the DHCPv6 server (you don't have to specify an address range).
6. See result on OPNsense2: /tmp/$if_routerv6 exists and 'System / Gateways / Single / WAN_SLAAC' does show a gateway address.

Expected behavior

For SLAAC WAN interfaces, an upstream DHCPv6 server should not be required for proper functionality.

Describe alternatives you considered

Configure the gateway address statically, but this isn't always possible.

Additional context

SLAAC without DHCPv6 is common on mobile (4G / 5G) connections. I encountered this issue when trying to set up a dual WAN system where WAN2 is tethered to an Android phone.

Environment

OPNsense 22.1.10 (amd64, OpenSSL).
Hyper-V Gen2

[maurice-w]

Turns out you don't even have to enable the DHCPv6 server in step 5, just switching the RA mode to 'Stateless' is sufficient. So it seems OPNsense only creates /tmp/$if_routerv6 if the O flag is set in RAs. Weird.

I tried to figure out what creates the /tmp/$if_routerv6 file for SLAAC interfaces but couldn't find anything in core. Does rtsold do that by itself?

[fichtner]

The router file is indeed only supplied by rtsold or mpd5 (pppoe linkup). For fringe use case of 6RD and 6to4 it is written statically.

[maurice-w]

Thanks, @fichtner. So does rtsold write the /tmp/$if_routerv6 file itself or does it pass the router address to a script or something which then writes the file?
I did dig through interfaces.inc but that only seems to handle the router file creation for the special interface types you mentioned. Should I look in the rtsold source code?

[fichtner]

It’s a little harder to track down since „ifctl“ helper was introduced.

core/src/etc/inc/interfaces.inc

Line 2860 in b8c6c18

/usr/local/sbin/ifctl -i \${1} -6rd -a \${2}

[maurice-w]

rtsold is started with the -M and -O options, which invokes rtsold_script.sh if the M or O flag is set in RAs:

core/src/etc/inc/interfaces.inc

Lines 2709 to 2715 in b8c6c18

	'/usr/sbin/rtsold -p %s -M %s -O %s -R %s -a',
	array(
	'/var/run/rtsold.pid',
	'/var/etc/rtsold_script.sh',
	'/var/etc/rtsold_script.sh',
	'/usr/bin/true', /* XXX missing proper script to refresh resolv.conf */
	)

Neither of these flags are set in this use case. Could this lead into the right direction?

[fichtner]

Yeah, that’s how it works. I don’t know if this makes sense historically for different flags or if rtsold isn’t fully implemented or wasn’t at the time it was integrated. The rtsold manual page would certainly shed more light on this.

[maurice-w]

Hey @fichtner, so it seems we've established how this is currently implemented:
When rtsold receives a Router Advertisement with the M or O flag set, it invokes rtsold_script.sh with the receiving interface name and the sending router as arguments. rtsold_script.sh then passes these arguments to ifctl, which creates the router file.

This works for DHCPv6 (where the M flag should always be set), but is hit-or-miss for SLAAC (where we can't make any assumptions about these flags).

We could use the rtsold -R option to invoke a script when a Router Advertisement contains RDNSS / DNSSL information (which is usually the case in scenarios without a DHCPv6 server). This script could then use ifctl to create the router file (just like rtsold_script.sh, but without the dhcp6c stuff).
It still would fail if RAs have neither the M or O flag nor RDNSS / DNSSL information. Unlikely, but possible. And if RAs have these flags and RDNSS / DNSSL, we would invoke ifctl -6rd twice. Could this be an issue? Other / better ideas?

[maurice-w]

Proof of concept patch: https://github.com/maurice-w/core/commit/62cb980d2c323ffe2e8aac32351603d254f3e2b6
Initial tests were successful.

Question: rtsold_script.sh also creates /tmp/$if_defaultgwv6. What's this file for? Should the new script create it, too? My test systems seem to work fine without it.

core/src/etc/inc/interfaces.inc

Lines 2861 to 2862 in b8c6c18

	# XXX stop modifying defaultgw files in scripts
	echo \${2} > /tmp/\${1}_defaultgwv6

So far I haven't seen any side effects of invoking ifctl -6rd twice. Do you think there could be any or is it meant to handle this?

[fichtner]

Thanks for the patch as a base for discussion. I would think we only write if router file is empty to keep a somewhat mandatory value in there that we know works. You can read the contents from the ifctl utility as well.

about default gateway file that should be emulated too but requires further work later on to streamline that file‘s purpose and handling as it lies outside the scope of ifctl.

to extract router address we should use a separate var just for style reasons and maybe the extraction can be made with shell internals instead of using sed. I can help with that if you make a PR for it.

furthermore, the XXX is somewhat wrong as ifctl already does handle DNS so the script could do it. It just needs the right parameters and variable to add.

[maurice-w]

@fichtner, quick update: I've addressed your points and also added support for passing RDNSS / DNSSL information from RAs to ifctl. I'll make a PR once testing with 22.7 is completed.

Only writing the router file when it's empty would prevent router address changes from being processed. I'm working on a way to only run the new script if the existing rtsold_script.sh hasn't run before. That should avoid any side effects.

[fichtner]

@maurice-w don't need to overcomplicate., something like this will suffice:

if [ -z "$(ifctl -r6 -i igb1)" ]; then
   # XXX add it if empty
fi

there's still a risk of race in the tool itself but I think we need to improve ifctl anyway to avoid adding duplicates for DNS servers (if we start having multiple sources for the same interface)