No IPv6 default route despite SLAAC addresses and received RA's (TrueNAS 13.0-U4)

[entheogenesis]

If you're using pfSense, you may find this bug report to be helpful.

 

[CSylvain]

I have exactly the same problem at Hetzner from a dedicated server, so the problem is definitely related to TrueNAS-SCALE !
I did several searches there, until helping me with Webmin, I managed to make the IPV6 work by manually adding a Default IPv6 Route of the server.

By comparing from another Hetzner server with an IPV6 which pings outwards, I think I have put my finger on the problem, TrueNAS-SCALE seems to be creating an IPv6 Route by default, but on the "lo" interface !

The IPV6 gateway is obviously defined in TrueNAS-SCALE, but it attaches to the wrong interface.

By issuing this command:

Code:

ip -6 route add default via fe80::1 dev enp3s0

I have instead of the "lo" interface the "enp3s0" interface and it pings !

Waiting for a next correction, I defined this route in Webmin.

 

[Patrick M. Hausen]

I have exactly the same problem at Hetzner from a dedicated server, so the problem is definitely related to TrueNAS-SCALE !

This thread discusses TrueNAS CORE.

I did several searches there, until helping me with Webmin,

You installed Webmin on TrueNAS SCALE? You know that anything configured outside of the TrueNAS UI will not be persistent?

 

[CSylvain]

This thread discusses TrueNAS CORE.

So the problem seems very similar, I also remember that every time I insert the IPV6 gateway in the form, I had an error that I can't remember too much, but contained an error format in Python that talk a failure with the add argument, even with DHCP deactivation and then a server reboot.
But it is sure that the problem is indeed in the codes of TrueNAS.

You installed Webmin on TrueNAS SCALE? You know that anything configured outside of the TrueNAS UI will not be persistent ?

It's even thought out to anticipate future updates with a script that redoes the installation of FirewallD and Webmin, then restores the internal paths to the confs files with symbolic links.

Small bonus to have it fix the problem under TrueNAS with a command that runs before it starts.

Code:

cli -c "system init_shutdown_script create comment=\"[FIX] Default IPv6 Route\" type=COMMAND command=\"ip -6 route add default via fe80::1 dev enp3s0\" when=POSTINIT enabled=true"

It will obviously be necessary to change the gateway as well as the name of the interface before pasting it into the Shell.

 

[Patrick M. Hausen]

Autoconfiguration through SLAAC including the default gateway works for 6 TrueNAS system I maintain. 1 SCALE, 5 CORE. Leave the global defaultrouter setting empty, activate autoconfiguration for one interface only. Simply works. I don't debate there might be a bug lurking. Did you set anything in the global defaultrouter? I don't get where the route to lo0 might come from.

 

[rungekutta]

For what it’s worth, I have the same issue too (talking about Core now). And there are many bug reports on it, including ones where iX closed without action and recommending Scale instead. Pretty clear signal to me that it’s time to start thinking about migrating… Either iX are focussing all their efforts on Scale (and deprioritise Core to only fix critical bugs) and/or they don’t give IPv6 enough weight - it’s been a slow burn, but it’s moving quickly now, including into data centres, and it’s not acceptable for an enterprise product in 2023 not to have proper support for it (IMHO).

TrueNAS - Issues - iXsystems TrueNAS Jira

ixsystems.atlassian.net

 

[Patrick M. Hausen]

Could you try setting IPv4 statically instead of using DHCP and autoconfiguration for IPv6 only?

 

[rungekutta]

In my case that’s exactly what I do - fully static config of IPv4, autoconfig IPv6 via SLAAC but that sets everything except default gateway.

 

[Patrick M. Hausen]

Damn. Worked for me ever since I started using IPv6 - some 10 years ago or even more. We run dual stack everywhere. It's so natural, I forgot when we ran only IPv4.

So ... what is the f* difference?

 

[CSylvain]

Could you try setting IPv4 statically instead of using DHCP and autoconfiguration for IPv6 only?

Both are static from the TrueNAS SCALE interface, it is not possible to put IPV4 or IPV6 if one of these two options is active.

 

[rungekutta]

Yeah dual stack here too and generally works well, TrueNAS the odd one out. ;-) iX are aware and won’t prioritise looking into it so neither will I, and will move to Scale eventually anyway. Not for virtualisation - I have dedicated hypervisors for that already which already do the job perfectly.

 

[CSylvain]

Small addition that confirms that it is a network interface error, since I put the fix, I see the IPV6 gateway appear, something that I did not see before, there was only the IPV4 in static good recess.

 

[Patrick M. Hausen]

If you're using pfSense, you may find this bug report to be helpful.

Thanks for pointing to that one. But I think you got it the wrong way round. This bug entry complains that pfSense also drops default routes advertised in RFC4191 fashion. Which is consistent because pfSense, OPNsense and TrueNAS CORE are all based on FreeBSD 13.

So the difference seems to be that the routers of the people who do not receive a valid default route send RA messages with option 24 set while mine in all my locations don't.

This needs to be fixed upstream by FreeBSD. Not much either *sense nor iX can do about that in my opinion.

Now could someone with a deeper knowledge of the Linux source code maintenance and bug tracking procedures check what a current Debian would do with such an RA (with option 24)?

Kind regards,
Patrick

 

[rungekutta]

Support for RFC4191 is optional/configurable on Linux kernels since 2.6.17. I can’t easily tell whether it’s compiled into the default kernel in Debian or not. In any case, Linux distributions typically compile their own kernels, including those downstream from Debian (e.g. Ubuntu). But I am also not certain that this is the actual issue (with TrueNAS). It could be something much more benign and related to state, particularly as some have reported that it works when you toggle autoconfig on/off and until next reboot.

So yes, it doesn’t look like FreeBSD supports RFC4191 at all whereas Linux optionally does. But how frequently is this actually used? The use case seems to be when there are several possible routes in complicated IPv6 environments, not the typical vanilla case. So as mentioned, not sure this is the actual issue.