interfaces: VIPs sometimes reorder, taking higher priority as "real" interfaces IPs

[gizahNL]

Perhaps it was the order in which things have been configured on my machine but I ran into a bug where the interface displays one subnet while in reality another is being stored into config.
I took the following steps:
->configure public IPv6 adress on interface
->enable RA
->create virtual IP for interface with ULA adress
->try to enable DHCPv6 for interface, see that it defaults to public subnet and allows no choice for ULA subnet (perhaps in this step enable and leave enabled DHCPv6 server)
->switch public and ULA adresses (ULA becomes interface adress, public one becomes virtual adress)
-> enable DHCPv6 server
-> configure ULA range and get confronted with message that range is outside of subnet, while it is displayed above as available range.

I've commented out the subnet checking bits to see what was happening, and I noticed that instead of my private subnet being written to file my public one was being written to file. So for some reason the public subnet overrides everywhere but in the interface.

Repeatedly fidling switching and deleting interfaces has allowed me to get a correct config written out, however I'm now unsure whether it will remain there after reboots.

[marjohn56]

@gizahNL

I have created a static global address on my LAN, then created a virtual interface ( VLAN ), on that VLAN I created a ULA address and dhcp6 server using the range as posted in your forum message, It's all working perfectly, I cannot reproduce your issue, perhaps someone else can?

[gizahNL]

@marjohn56 the issue is not with VLAN afaik but with virtual IP (the OPNSense lingua for FreeBSD alias, Firewall->Virtual IP's), which allows multiple IP adresses to be configured on the same device.
My guess would be that by setting a ipv6 adress on the device, going to the dhcpv6 server and enabling it it stores already that subnet in a config.
Then I guess changing the main interface subnet to a different one, but at the same time configuring configuring the old subnet on a virtual ip and then modifying the dhcpv6 settings will not result in the stored subnet getting changed, as it is still associated with the device.
While at the same time the dhcpv6 configuration page pulls it's info from the configured main subnet.

Hope it all makes sense ;)

[fichtner]

@gizahNL still an issue?

[draggeta]

@fichtner I'm having this issue as well. I've posted it on the pfSense issue tracker as well. Hopefully you guys can take a better look at it then they do.

Basically the current workaround seems to be this:

• change the order of the IP's on the interfaces so the ULA is below the tracked IP
• update the radvd.conf file
• restart radvd

As I said in their issue tracker, I don't really know how to do step 2 from the CLI. It seems to have to do wit the services.inc file and the first function.

[fichtner]

@draggeta The IPv6 side of things has given us trouble in that area before, the sense of a "primary" address on the interface is already trashed by the concept of link-local addresses, but that's a bit of a side story. Since dhcp6 kicks in later we get an address too late and the alias is already pushed to the interface... the only solution that seems doable is make IPv6 aliases "second class" addresses and flush + reapply them on new IPv6 address delegations. How does that sound?

[draggeta]

@fichtner That is a completely reasonable implementation. In those cases you may notice a small hiccup when using the ULAs for communication, but it's better miles better than having the connection to the internet be unavailable after a reboot/PD change.

I'll be happy to help with this issue, but I'm not sure I could contribute code directly.

[fichtner]

@draggeta no worries. Testing is appreciated as well... hopefully can look at it next week in more detail.

[perryflynn]

The problem I described in #2821 ist gone since 18.7.6. All service bind since then on the primary interface address.

[fichtner]

I'm unable to see an issue at the moment. No new data since Dec 2018.