OPNSENSE ND ignoring internal IPv6 routes advertised on the LAN

[jasonistre]

OPNSENSE seems to ignore any other RAs on my LAN and won't add routes.

OPNSENSE is running IPv6 RA on LAN interface for track GUA, but I also have other IPv6 RAs on the L2 LAN vlan for thread/matter that border dynamic ULA networks.  Pings to ULA devices behind the border routers, from OPNSENSE itself, try to go out WAN.  GUA Clients (windows/linux/macOS) on the L2 LAN vlan find those advertised ULA routes and can ping ULA devices behind those border routers because they see the RAs and update their route tables. Does something have to be enabled to allow OPNSENSE to accept IPv6 router advertisements on it's LAN interface for other internal IPv6 networks beyond the L2 vlan it is directly connected to?

I found this information online in regards to IPv6 route distribution:  The announcements are sent using the standard IPv6 Neighbor Discovery Protocol (NDP, or often ndisc) via RFC 4191 Route Information Option (RIO).

It may have something to do with net.inet6.ip6.no_radr, net.inet6.ip6.rfc6204w3, or something like ipv6_cpe_wanif, but I played with changing all those values and it didn't seem to change anything.  radvdump shows the router seeing the advertisement on the LAN interface:

radvd configuration generated by radvdump 2.19
based on Router Advertisement from fe80::49e:xxxx:xxxx:xxxx
received by interface ix0
interface ix0
{
        AdvSendAdvert on;
        # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
        AdvManagedFlag off;
        AdvOtherConfigFlag off;
        AdvReachableTime 0;
        AdvRetransTimer 0;
        AdvCurHopLimit 0;
        AdvDefaultLifetime 0;
        AdvHomeAgentFlag off;
        AdvDefaultPreference medium;
        AdvSourceLLAddress on;

        route fd4c:43e9:xxxx::/64
        {
                AdvRoutePreference medium;
                AdvRouteLifetime 1800;
        }; # End of route definition

}; # End of interface definition

...However it does not get added to the ipv6 FreeBSD route table like all the other ipv6 hosts on the L2 vlan.  Static routes aren't an option as these ULA networks can dynamically change and are not directly under my control.  Maybe I could force this by running an IPv6 routing protocol like OSPFv3 or BGP on my switches, but that's a poor workaround and not something I want to maintain when ND should be working.

Maybe I'm missing something simple? Any ideas???

[meyergru]

Usually, a router like OpnSense will think of itself as being mandatory for distributing IPv6 routes, so the ACCEPT_RTADV flag will only be set on upstream interfaces. All the sysctl variables seem to be set correctly, though.

All you would have to do is "ifconfig <lan-interface> inet6 accept_rtadv", but this can cause your general routing to fail, if, say, a default route is being received.

[jasonistre]

I tested "ifconfig ix0 inet6 accept_rtadv". After some time my IPv6 default route changed from the fe80::21c:xxxx:xxxx:xx%igc0 (ISP WAN gateway) on igc0 (WAN) to fe80::2f0:xxxx:xxxx:xxxx%ix0, which is the LL of OPNSENSE LAN interface itself.  This broke IPv6.
It also added one route to the IPv6 route table:
fd11:yyyy::xxxx:xxxx:xxxx:xxxx          link#6                        UHS         lo0

fd11:yyyy::1/64 being an OPNSENSE VIP on LAN (ix0), and xxxx:xxxx:xxxx:xxxx being the same mac/duid or suffix of the ix0 LL fe80.

So it looks like it added itself, but still ignored ix0 LAN ND messages from border routers.

Any workarounds?  Is this a bug I should report, or something FreeBSD won't be able to handle, or something else?

[meyergru]

I said that this setting was dangerous and I doubt that you can limit what happens if wrong routes are advertised from anywhere (and so it seems). So, it is either you want that or you do not.

Because most people would not want to have something like that happening, I doubt that there should be a checkbox to enable it without any safeguarding and I also do not see how that could be done.

You can issue a feature request on Github (it sureöy is not a bug), but I would not expect that to be implemented anytime soon.

[jasonistre]

The setting didn't actually allow the processing of announcements for NDP per RFC 4191 on internal networks behind the router though. It only allowed the processing of it's own NDP annoucements from interface lo0 via ix0. This is an issue for the support and usage of IPv6 in the product.  I assume nearly everyone with Apple, Google, Amazon, or really any vendors home hubs for Matter/Thread is affected and just doesn't know it because reach-ability isn't an issue in their use case yet. It would become a bigger issue for those with interfaces in multiple internal networks as you wont be able to add the dynamic IPv6 routes and cross the L3 boundary. 

[troplin]

In my case the Thread Border Router (AppleTV) simply requests a prefix from OPNsense via PD. Isn't that how it's supposed to work with IPv6?

[jasonistre]

You're using the DHCPv6 to delegate a prefix? ULA or GUA? 

I was using DHCPv6 to give out ULA prefixes and since its a track interface clients use DHCPv6 to get GUA addresses.  I had some issues with the lease table being empty though it seemed to work.  ...but when OPNSENSE would reboot or a switch sometimes the apple Tvs would change prefixs and not agree and matter/thread would not be happy.  Letting them just dynamically create their own backend ULA prefix works well.

If your delegating ULA prefixes are you seeing lease table problems in the GUI or anything off in the logs? Is the interface you are using a GUA or track wan or ULA?

[dseven]

If the prefix is delegated by OPNsense DHCPv6, there should be a route added for it automatically (without need for RA discovery), but only if either the router requesting the prefix also requests (and obtains) an address (IA_NA) for itself or you have defined a static mapping for it - i.e. the DHCPv6 server needs an address to point the route at.