Link local address on Lan and Opt are overwritten when using interface tracking

[guest19228]

I stumbled over that problem when dealing with this one https://forum.opnsense.org/index.php?topic=9986.0. And this leads to my question why need the lan and opt interface LL addresses generated be the kernel to be overwritten with fe80::1:1 and why does this happen only when using interface tracking for obtaining an IPv6 address? From my tests I found that this is not necessary. Interface tracking will also work when not overwriting the LL address. Whta makes me most unhappy, is that this behaviour is hardcoded. This gives you no chance to change that without messing with the code.
Now imaging a scenario as shown in attached picture network example.png. In this example we have to opnsense firewall connected to the same internal network. While one is the default router the other one will act as a router for a specific network range. (Do not ask for the sense, the decision was made to do it that way)  Because both are using interface tracking for obtaining an IPv6 address on the lan interface the LL address on the lan interface of both machines will become fe80::1:1 and this leads to an duplicated IP address conflict.

Currently there is no chance to set a LL address for an interface manually in the webinterface, so there is not much you can do without changing the code. Also in the topic mentioned above that it is commonly used to give the default gateway the addres fe80::1 so that they can say the default gateway is alway fe80::1. I a scenario were you are using a static IPv6 address the LL address is not overwritten and you cannot change it to fe80::1.
I suggest the developers should add  an option to add and LL address or to overwrite the existing one like shown in attached picture ll-config.png. This would give the user the possibility to change the LL addressing bevaviour to their needs.

[bringha]

Hi emwe

Although you would like to have this solved via different LL Addresses  ;)  I would suggest however to consider the following two options as an alternate possibility

If I have understood your target config correctly, there are eg:

Option 1: Route traffic to WAN 2 via Router 1.

Imho Router 2 (WAN 2) does not need to send RA. If for what reasons ever RA should be required, then the relevant config in radvd.conf should look like (eth0 is the Interface to your internal subnet):

Code Select Expand


interface eth0 {
  AdvSendAdvert on;
  AdvDefaultLifetime 0;
  MinRtrAdvInterval 3;
  MaxRtrAdvInterval 10;
  route 2006:cadf:485e::/48 {};
};


AdvDefaultLifetime 0 prevents that router 2 advertises a default gateway and confuses the client by overwriting the default gateway being advertised from Router 1. You don't need to advertise the prefix option on eth0 of Router 2 because Router 1 is already doing that. Router 1 needs furthermore a (static) route to Router 2 for the WAN subnet behind it. Clients that don't understand the route option will use Router 1 as default gateway, and then Router 1 needs to know where to send those packets.

Option 2: Have second routing table on each client as well as (virtual) dedicated NICs connecting to the WAN 2 router.
In Linux, this function is provided eg via iproute2; here you can add an additional routing table and assign it to the related NICs.(see also suggestion from Franco in the other post)

Should work ....

Further options indeed possible ....

Br br

[franco]

https://github.com/opnsense/core/issues/817

I would consider this nice to have. Not a lot of feedback over the years. The first time that this issue is actively pushed by a user. Bear with me, please...

There was an comment in the code for many years noting issues with CARP setups and fe80::1:1 usage. It was recently purged because there were no corresponding reports but it is the same class of problem indeed as it would cause clashing link-locals in a bridged scenario between the LAN ports of both CARP boxes.

As a hybrid alternative, it would maybe be better to be able to disable the old link-local switcheroo for the tracking specifically as it would make the code impact and implementation smaller.

What do you think?


Cheers,
Franco

[bringha]

Hi Franco,

what do you mean with the 'old link-local switcheroo for the tracking' specifically' ?

Br br

[franco]

Pardon the wording. I meant making this opt-out as it only pertains to tracking:

https://github.com/opnsense/core/blob/8c83f70f1fadb43b51c5a54cd25df0cb8b7fe323/src/etc/inc/interfaces.inc#L2582-L2587


Cheers,
Franco

[bringha]

Hi Franco,

Imho its a question of philosophy OPNsense wants to follow in future:

Alternative 1: Full flexibility with LL Addresses as being  assigned by Kernel
But then, simply removing the code would not be enough, there should be an option to set LL addresses manually as emwe has suggested to support the convention model as discussed earlier

Alternative 2: Leave the code in and have a kind of 'built in hard coded' support of the mentioned conventions

The current model supports the 'OPNsense-is-a-router' philosophy and obviously the use cases the today users have can be served (as you rightfully said, there was no momentum for a change since 2016). On the other hand for the price that some configs are then 'limited'.

I personally don't miss yet the additional possibilities of Alternative 1 would be able to offer but others might see this differently. I prefer a rather clear model as Alternative 2 is showing. If going for Alternative 1, the extensions in the GUI are from my perspective mandatory ....

Just my 10c

Br br

[franco]

Hi bringha,

I tend to agree, though we must be realistic about the unknown amount of work required to implement alternative 1.  I can't say it's hard or easy. The only indicator is that nobody did it yet so it must either be harder than expected or less likely to be of value, and in both scenarios cost-benefit is not great.


Cheers,
Franco

[guest19228]

Hello bringha,
for your first reply... the requirements are very strict. All traffic dedicated to the network served by router2 must not be handled by router1. In fact it is forbidden that router1 will handle any packet dedicated to the network on router2. On the other hand traffic that not is meant for the network behind router2 must never go to router2. Routers 1 and 2 should not advertise anything. The client configuration should be done via dhcp only as described here https://www.isc.org/blogs/routing-configuration-over-dhcpv6-2/ (SLAAC is not wanted). However this all is still in evaluation, who knows where it will end.

[franco]

The requirements tell me that you need to check "Allow manual adjustment of DHCPv6 and Router Advertisements" and both DHCPv6 and RADVD will be turned off until you manually configure them.


Cheers,
Franco

[guest19228]

Hello Franco, bringha,
for replay #8  from Franco: yes, that's the plan so far.
But back to the original topic, if it is best practice to set the link local address to fe80::1 and the plan of the developers was to fullfill this then it should  had be done consistently and not only when using  interface tracking. It's a fact that the LL address is overwritten with fe80::1:1 only when using interface tracking. When using static address, SLAAC or dhcp the kernel generated LL address is left untouched and also no additional LL address is configured. Interface tracking works also when not overwriting the LL address, so I do not understand the reason why it is done in this case and only this case.
example opt1 with static addressing:

Code Select Expand

vtnet2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=6c00b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 fe80::5054:ff:fe8d:d137%vtnet2 prefixlen 64 scopeid 0x3
        inet6 fd30:5678:ad45:ddaa:: prefixlen 64
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
and now when activating interface tracking:

Code Select Expand

vtnet2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=6c00b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 fe80::1:1%vtnet2 prefixlen 64 scopeid 0x3
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
To be consistent you can simply remove the few code lines. Adding the possibility to change/add the LL address via the web interface is then the icing on the cake.

[bringha]

To be consistent you can simply remove the few code lines. Adding the possibility to change/add the LL address via the web interface is then the icing on the cake.

Here I disagree - The result of the current interface tracking implementation leads to a convention compliant address scheme with fe80::1:1%<zoneid> result on the internal interface as a router should have. We may dispute whether the current chosen hardcoded method is the most elegant one, however, if this is no longer generated automatically, there must be a possibility to add/modify this address manually (best) via the GUI. The one without the other does not make sense to me.

Br br

[guest19228]

Hello bringha,
probably I was not clear. If overwriting the LL address to use a

convention compliant address scheme with fe80::1:1%<zoneid> result on the internal interface as a router should have.

then it should be done also when using a static IPv6 address, dhcp or SLAAC. But it's done only when using interface tracking. This is inconsistent. The better  and consistent way would be doing it for all or for none.

[bringha]

Thats for sure true!

In all cases, this would mean that a provided LL address must be possible to be changed manually then ... ideally via GUI.

Br br

[franco]

I don't think this is a very goal-oriented discussion. It hinges on the premise that everything is done wrong now while making a simplified gambit about the user's intent.


Cheers,
Franco

[franco]

PS: Relevant commits that are being speculated about. Use the source...

https://github.com/pfsense/pfsense/commit/e90c833ad
https://github.com/pfsense/pfsense/commit/919ff1f070
https://github.com/pfsense/pfsense/commit/55909a9ad