Adding IP Alias to tracking LAN interface breaks tracking

[maurice-w]

Describe the bug
TL;WR: Adding an IPv6 Alias to a LAN interface which is configured to track an IPv6 WAN interface causes the LAN interface to stop tracking after a reboot. It subsequently only uses the IP Alias and hosts in the LAN lose Internet connectivity.

To Reproduce
Steps to reproduce the behavior:

1. Set the WAN interface IPv6 configuration type to DHCPv6.
2. Configure the LAN interface to track the WAN interface and enable Manual configuration. (The ULA prefix which we add in the next step won't be advertised unless we "allow the manual adjustment of DHCPv6 and Router Advertisements", although we don't actually adjust anything manually. This might be considered another bug, but let's not get into this here.)
3. Add a Virtual IP to the LAN interface: Type IP Alias, address fd01:2:3:4::1/64 (ULA)
4. On the Dashboard, restart the radvd service. This seems to be required to make it pick up the additional interface address and advertise the additional prefix.
5. Check that hosts in the LAN have both GUAs and ULAs and working Internet connectivity. In my tests this worked fine at this point.
6. Reload DHCP on WAN interface or reboot the router.

Expected behavior
LAN interface has an auto-generated GUA as well as the manually added ULA and advertises both prefixes. LAN hosts have GUAs and ULAs and working Internet connectivity.

Actual behavior
After a WAN DHCP Reload or a router reboot, the LAN interface doesn't track the WAN interface, uses the IP Alias as its only address and only advertises the ULA prefix. Hosts in the LAN only have ULAs and lose Internet connectivity.

Additional context
This has been mentioned on the forum here and here but I couldn't find a matching bug report.
This is important because using an IP Alias seems to be the only way to add ULAs to a tracking LAN interface. Using both GUAs and ULAs is recommended when the prefix delegated by the ISP isn't static. (For example, OpenWrt adds ULAs to all LANs by default.)

Environment
OPNsense 19.1.3-amd64

Update
I initially mixed up advertising prefixes and routes. I updated the steps to reproduce the behavior accordingly. This doesn't change anything about the bug itself.

[fichtner]

@maurice-w would you mind testing this on 19.1.7's development version (19.7.a_701)?

[maurice-w]

@fichtner, thanks for looking into this. I've tested with the development version and the issue has shifted: Tracking seems to keep working after a DHCP reload or reboot. But the IP Alias doesn't seem to be applied correctly. I don't get a response when pinging the IP Alias, the web interface isn't reachable via the IP Alias etc. Also, I got this error message (which I've never seen in 19.1.x); not sure whether it is related:

PHP Warning: escapeshellarg() expects exactly 1 parameter, 2 given in /usr/local/etc/inc/interfaces.inc on line 1667

After rolling back to 19.1.7 the IP Alias works again (but of course the original issue is back).

[fichtner]

@maurice-w uhh, my bad, can you try devel again with 8427198 on top?

# opnsense-patch 8427198

Cheers,
Franco

[maurice-w]

@fichtner, with devel + patch it's back to the original issue: No GUA on the tracking LAN interface after a DHCP reload on the WAN. Also, new error messages (right after DHCP reload):

[04-May-2019 15:43:28 Europe/Berlin] PHP Warning:  vsprintf(): Too few arguments in /usr/local/etc/inc/util.inc on line 984
[04-May-2019 15:43:39 Europe/Berlin] PHP Fatal error:  Uncaught Error: Call to undefined function lookup_gateway_interface_by_name() in /usr/local/etc/rc.dyndns:46
Stack trace:
#0 {main}
  thrown in /usr/local/etc/rc.dyndns on line 46
[04-May-2019 15:43:45 Europe/Berlin] PHP Warning:  vsprintf(): Too few arguments in /usr/local/etc/inc/util.inc on line 984

(BTW, in 19.1.7 the "no GUA on LAN" issue is 100% reproducible on WAN DHCP reloads, but not on reboots. After a reboot it often works, but sometimes doesn't. Seems like some kind of race condition.)

Cheers
Maurice

[fichtner]

the error is from not using os-dyndns-devel, but can be neglected for the purpose of this ticket. let me see if I can reproduce this locally...

EDIT: OK I don't have tracking at home. Need to try Monday at the office.

[fichtner]

Note: I wan't at work this week due to sick leave.

[maurice-w]

No worries and get well soon!
(Prefix tracking + ULAs essentially works as long as the delegated prefix doesn't change and you don't reboot or make configuration changes which cause a DHCP reload. For me it's currently mostly an extra step of sometimes having to remove and re-add the ULA IP Alias after reboots. It probably becomes a much bigger issue if the delegated prefix actually changes regularly.)

[fichtner]

I have to move this to the next version due to time constraints. My day job away from OPNsense is quite challenging at the moment. Sorry. :(