core: Adding IP Alias to tracking LAN interface breaks tracking
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:
- Set the WAN interface IPv6 configuration type to DHCPv6.
- 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.)
- Add a Virtual IP to the LAN interface: Type IP Alias, address fd01:2:3:4::1/64 (ULA)
- On the Dashboard, restart the
radvdservice. This seems to be required to make it pick up the additional interface address and advertise the additional prefix. - Check that hosts in the LAN have both GUAs and ULAs and working Internet connectivity. In my tests this worked fine at this point.
- 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.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 3
- Comments: 92 (92 by maintainers)
Commits related to this issue
- interfaces: wrong brace, wouldn't happen with mwexecf() :P PR: https://github.com/opnsense/core/issues/3310 — committed to opnsense/core by fichtner 5 years ago
- interfaces: wrong brace, wouldn't happen with mwexecf() :P PR: https://github.com/opnsense/core/issues/3310 — committed to KontextWork/opnsense_core by fichtner 5 years ago
- interfaces: wrong brace, wouldn't happen with mwexecf() :P PR: https://github.com/opnsense/core/issues/3310 — committed to KontextWork/opnsense_core by fichtner 5 years ago
- dhcp: blacklist aliases in IPv6 case #3310 This code is probably relevant in other parts as well. — committed to opnsense/core by fichtner 4 years ago
- dhcpd: refactor, needs second caller #3310 — committed to opnsense/core by fichtner 4 years ago
- interfaces: typo in previous #3310 — committed to opnsense/core by fichtner 4 years ago
- dhcp: fix refactor issue and scope hiccup #3310 — committed to opnsense/core by fichtner 4 years ago
- dhcp: same for radvd #3310 — committed to opnsense/core by fichtner 4 years ago
- dhcp: fix page info #3310 — committed to opnsense/core by fichtner 4 years ago
- dhcpd: get realif if not specified otherwise #3310 — committed to opnsense/core by fichtner 4 years ago
- interfaces: turn dhcpd function into generic function #3310 — committed to opnsense/core by fichtner 4 years ago
- interfaces: sneak in primary IPv6 info before it defaults to "something" #3310 — committed to opnsense/core by fichtner 4 years ago
- interfaces: typo #3310 — committed to opnsense/core by fichtner 4 years ago
- interfaces: actually... #3310 — committed to opnsense/core by fichtner 4 years ago
- interfaces: use primary IPv6 and support VIP tracking #3310 — committed to opnsense/core by fichtner 4 years ago
Whilst playing with the combined WAN dhcp6c stuff I noticed there is one more cleanup, console only shows the first v6 address, if there is an alias it’s only showing that one. Can we make it show all alias and GUAs?
I didn’t think it was President Trump, I blame him for most things, but in this case…
Morning all… had a look at this and I have it behaving now. I was able to replicate the issue that @maurice-w gave in his bug report, namely that on reboot the VIP came up on the interface before the dhcp6 address, of course this will also happen when the prefix changes. What I’ve done to cure it, at least it works on my test system, is in the call to interface_track6_configure() I remove the VIP from the interface, carry on with the dhcp6c routine and then before it returns is re-apply the VIP to the interface, this appears to work OK and the dhcp6 server is now showing the proper address and the VIP is shown on the interface. I cannot fully test this as I need someone who has a silly ISP that doesn’t do static to check this. I guess we overlooked this issue when we refactored the dhcp6c stuff last year.
@fichtner - thoughts, is this a valid solution?