IPv6: No route to host

[KagurazakaNyaa]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

After the upgrade from 21.7.7, there is a problem with IPv6 routing, unable to assign v6 addresses to LAN devices, and found a lot of Error dhcpd send_packet6: No route to host in the DHCP log.

At the same time, the default IPv6 route for the WAN interface becomes a link-local address. Testing the connection using either the WAN or LAN interface for this address will return an error. Even though both the WAN and LAN interfaces have acquired valid IPv6 addresses. But the router itself can access the IPv6 network normally whether it is the LAN or the WAN interface. That said, I suspect that only other devices on this router's LAN interface are affected.

To Reproduce

Steps to reproduce the behavior:

1. Do upgrade from 21.7.7
2. Make a device on the LAN re-request a dhcp address
3. Navigate to /ui/diagnostics/log/core/dhcpd
4. See error
5. Navigate to /system_gateways.php
6. Copy WAN_DHCP6 (active) gateway, it start with fe80::
7. Navigate to /diag_ping.php
8. Paste the gateway to host
9. Select protocol to IPv6 and src to WAN or LAN
10. Ping
11. Got error ping6: sendmsg: No route to host both WAN and LAN
12. Try ping 2001:4860:4860::8888
13. Everythin OK

Expected behavior

The router itself and other devices it routes should normally obtain IPv6 addresses and access the IPv6 network normally.

Describe alternatives you considered

Reinstalling back to 21.7.7 or earlier fixes the issue, but it's not a good solution as we need to get updates for functionality and security.

Screenshots

Relevant log files

Using the opnsense-log tool seems to only get the system log, i.e. the contents of /var/log/system/latest.log, I checked its contents and it doesn't seem to help with the issue.

Additional context

The WAN interface uses DHCPv6 to obtain addresses, and the LAN interface uses the tracking interface.
The WAN interface obtains a prefix of /56, and the DHCPv6 service shows that the available prefix delegation size is 57.

Environment

OPNsense 22.1.4_1-amd64
FreeBSD 13.0-STABLE
OpenSSL 1.1.1n 15 Mar 2022

Intel(R) Celeron(R) CPU J3455 @ 1.50GHz (4 cores, 4 threads)

I211 Gigabit Network Connection

[KagurazakaNyaa]

#5626 maybe related to this issue.

[fichtner]

@KagurazakaNyaa if you want to ping link-local please use link-local setting from ping GUI utility. There's no reason it shouldn't work and I don't think it was ever possible to ping from GUA to link-local...

[KagurazakaNyaa]

OK, then it looks like it shouldn't be related to this issue, the reason I mentioned it is that before the upgrade the default IPv6 route started with 240e:

[fichtner]

Can you try a connectivity audit from the firmware GUI first to see if IPv6 works internally or not?

[KagurazakaNyaa]

Can you try a connectivity audit from the firmware GUI first to see if IPv6 works internally or not?

Yes, it works and the router itself can access the IPv6 network just fine.
Then I think, the crux of the problem should be that the IPv6 communication from the router to the LAN device cannot work properly.
I noticed that the LAN interface does not currently have a link-local address. Is this normal?

[fichtner]

If dhcpd is erroring it would complain about an address no longer in use, which is definitely strange. Can you share an ifconfig on your LAN device?

[fichtner]

Also what's in /var/etc/dhcp6c.conf ?

[KagurazakaNyaa]

On router:

root@router:~ # cat /var/etc/dhcp6c.conf
interface pppoe0 {
  send ia-na 0; # request stateful address
  send ia-pd 0; # request prefix delegation
  request domain-name-servers;
  request domain-name;
  script "/var/etc/dhcp6c_wan_script.sh"; # we'd like some nameservers please
};
id-assoc na 0 { };
id-assoc pd 0 {
  prefix-interface bridge0 {
    sla-id 1;
    sla-len 8;
  };
};

On an arch linux vm:

╭─root@dev in ~ 
╰$ ifconfig 
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        inet6 fe80::42:5dff:fef1:f52a  prefixlen 64  scopeid 0x20<link>
        ether 02:42:5d:f1:f5:2a  txqueuelen 0  (Ethernet)
        RX packets 115928  bytes 78381851 (74.7 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 172847  bytes 211387185 (201.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ens192: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.10.10.31  netmask 255.255.0.0  broadcast 10.10.255.255
        inet6 fe80::e29:7387:6bff:ad6c  prefixlen 64  scopeid 0x20<link>
        ether 00:50:56:ad:6f:f1  txqueuelen 1000  (Ethernet)
        RX packets 4620951  bytes 3141730854 (2.9 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1284993  bytes 681487754 (649.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 674911  bytes 1030230797 (982.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 674911  bytes 1030230797 (982.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

veth356a6fc: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::f074:97ff:fe80:c6f3  prefixlen 64  scopeid 0x20<link>
        ether f2:74:97:80:c6:f3  txqueuelen 0  (Ethernet)
        RX packets 37552  bytes 35408193 (33.7 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 94918  bytes 35555360 (33.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

veth826d544: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::ce7:39ff:fe47:1d9f  prefixlen 64  scopeid 0x20<link>
        ether 0e:e7:39:47:1d:9f  txqueuelen 0  (Ethernet)
        RX packets 7  bytes 858 (858.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 52764  bytes 26111386 (24.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Devices on the LAN can now only obtain IPv4 addresses.

[fichtner]

bridge0 is your LAN? bridges don't have link-local addresses unless set in GUI. But if bridge0 isn't your LAN you should change the tracker to use LAN interface really and not the bridge. This stuff can be bridged, but depending on what is being bridged it can get fragile really quickly.

[KagurazakaNyaa]

Yes, bridge0 is the LAN interface and it contains three physical interfaces.
It worked, after I enabled the link-local of bridge0.
Thank you very much!

[fichtner]

ok happy to hear :)