[Solved] Clients don't get an IPv6 address

[ozboss]

Since the upgrade to OPNsense 22 my clients do not get an IPv6 address anymore.
I'm now on 22.1.6, with OPNsense 21 everything was working fine.

For the setup I followed this guide: https://docs.opnsense.org/manual/how-tos/ipv6_dsl.html
My WAN interface has a prefix delegation size of 56.
The IPv6 configuration type of the LAN interface is 'Track Interface' with WAN as 'IPv6 Interface' and 'IPv6 Prefix ID' 0 (I also tried 1 as I read somewhere that 0 might cause issues but that didn't fix it).
With these settings my LAN interface gets one of the public IPv6 subnets (public IPv6 with prefix size 64).
Still none of my clients get an IPv6 address.

I ran radvdump and this is the result:

Code Select Expand


#
# radvd configuration generated by radvdump 2.19
# based on Router Advertisement from fe80::1
# received by interface igb0
#

interface igb0
{
AdvSendAdvert on;
# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
AdvManagedFlag on;
AdvOtherConfigFlag on;
AdvReachableTime 0;
AdvRetransTimer 0;
AdvCurHopLimit 64;
AdvDefaultLifetime 120;
AdvHomeAgentFlag off;
AdvDefaultPreference medium;
AdvSourceLLAddress on;
AdvLinkMTU 1500;
}; # End of interface definition


There is no prefix being advertised...
I'm kind of lost on this and not really sure on how to even start debugging this.
I would be great if somebody could help me out  :)

[hescominsoon]

it's an ongoing issue..you are one of many that have commented on ipv6 being broken in OpnSense.

[i81b4u]

it's an ongoing issue..you are one of many that have commented on ipv6 being broken in OpnSense.

I'm afraid I can not agree  ;)
IPv6 is working just fine for me.

Perhaps you can use a tool like tcpdump or wireshark to look into the problem?

Best regards.

[Greelan]

I agree that a blanket statement that "IPv6 is broken in OPNsense" is a silly one.

OP: what RA mode is set under Services/Router Advertisements? You might need to select "Allow manual adjustment of DHCPv6 and Router Advertisements" on the LAN interface IPv6 config to see this option for LAN. I use "Unmanaged" (for SLAAC only) and it works absolutely fine.

[meyergru]

@ozboss: You should login to your box and look at /var/etc/radvd.conf to see if there are any prefixes.

If not, then obviously something must be wrong with the dhcpv6 client configuration on your WAN interface. like wrong prefix delegation size or wrong settings of flags. With my ISP, the whole DHCPv6 request goes wrong whenever I try to get more than an IPv6 prefix. Also, flags for prefix hints, VLAN priority and whether IPv4 is used to get IPv6 info can be relevant. You should try different combinations, rinse and repeat.

In my case, only one specific combination worked - but it did, so it is definitely not like IPv6 is not working at all.

[robgnu]

Hi,

I also can confirm. I have a Network with some VLANs. After Upgrading from 21.7 to 22.1.6 one VLAN lost IPv6 connectivity. All VLANs get the correct RA from radvd, but only one VLAN doesn't get any IPv6 addresses.

The radvd confg file for these two VLANs is correct. VLAN11 works, VLAN20 does not work. The VLAN interfaces have correct IPv6 addresses from their subnets...

Code Select Expand


# Generated for DHCPv6 server opt1
interface igb0_vlan11 {
        AdvSendAdvert on;
        MinRtrAdvInterval 200;
        MaxRtrAdvInterval 600;
        AdvLinkMTU 1492;
        AdvDefaultPreference medium;
        prefix 2003:a:XXXX:XX11::/64 {
                DeprecatePrefix on;
                AdvOnLink on;
                AdvAutonomous on;
        };
        RDNSS 2003:a:XXXX:XX11:20d:b9ff:fe4d:efbc {
        };
        DNSSL office.XXXX.berlin {
        };
};
# Generated for DHCPv6 server opt2
interface igb0_vlan20 {
        AdvSendAdvert on;
        MinRtrAdvInterval 200;
        MaxRtrAdvInterval 600;
        AdvLinkMTU 1492;
        AdvDefaultPreference medium;
        prefix 2003:a:XXXX:XX20::/64 {
                DeprecatePrefix on;
                AdvOnLink on;
                AdvAutonomous on;
        };
        RDNSS 2003:a:XXXX:XX20:20d:b9ff:fe4d:efbc {
        };
        DNSSL office.XXXX.berlin {
        };
};


Any ideas?

Bye
Robert.

[meyergru]

I have "AdvManagedFlag on" and "AdvOtherConfigFlag on;" in all of my interfaces, and I think the latter is neccessary for stateless configuration, but that does not explain why one of your vlans works and one does not...

[ozboss]

OP: what RA mode is set under Services/Router Advertisements? ... I use "Unmanaged" (for SLAAC only) and it works absolutely fine.

I have tried 'Stateless' before as I also want the DNS server to be advertised. Without success, same for 'Unmanaged'.
Anyway the default should be fine for me, as I think it is basically 'Stateless'. Therefore I disabled 'Manual configuration' again for the interface.

@ozboss: You should login to your box and look at /var/etc/radvd.conf to see if there are any prefixes.

Ah so that's where the config file is stored :D
This looks interesting. It does have a prefix (the prefix delegated to my WAN interface with size /64), and the interface is the one assigned to my LAN interface: bridge0
So I'm running everything over a bridge, could this be the problem? Should radvdump not also advertise this interface instead of igb0?

[meyergru]

Yup. That might well be the case. Look here (and read the whole thread). For starters: Does your bridge interface have a MAC? Is it needed for SLAAC to work?

Since the time of that thread, even the quoted "unconfigured VLAN master" requirement has changed. Also, the settings "net.link.bridge.pfil_bridge = 1" and "net.link.bridge.pfil_member = 0" (plus a reboot) are recommended.

However, I cannot say for sure, since I gave up on bridged interfaces while still on 21.x.

[ozboss]

Yup. That might well be the case. Look here (and read the whole thread). For starters: Does your bridge interface have a MAC? Is it needed for SLAAC to work?

Yes my bridge interface has a MAC and also not a blank one as seems to have been the case for you.

Since the time of that thread, even the quoted "unconfigured VLAN master" requirement has changed. Also, the settings "net.link.bridge.pfil_bridge = 1" and "net.link.bridge.pfil_member = 0" (plus a reboot) are recommended.

I'm not (yet) using any VLANs. All the member interfaces have configuration type 'None' for both IPv4 and IPv6. I also enabled those two tunables. Basically I followed this guide for the creation of the bridge: https://docs.opnsense.org/manual/how-tos/lan_bridge.html
Also IPv6 was working with v21, I have not changed any settings since then.

[meyergru]

FreeBSD is very peculiar about how it handles different layers of networking and their interaction (much more than I am used to with Linux). In the thread I mentioned is a specific reference (https://docs.freebsd.org/en/books/handbook/advanced-networking/#network-bridging). The difference you may be expecting may be one between older and newer kernels were something subtle gets handled differently.

That is not to say that the upgrade from 21.x to 22.1 was not responsible for your specific problem, but it probably would not even arise if you did not use a bridge.

[robgnu]

Hi,
the problem seems to be solved for now. One more reboot after the update from 22.1 to 22.1.6 solved the issues with the vlans. ...interesting... :)

Bye
Robert.

[ozboss]

... The difference you may be expecting may be one between older and newer kernels were something subtle gets handled differently.
That is not to say that the upgrade from 21.x to 22.1 was not responsible for your specific problem, but it probably would not even arise if you did not use a bridge.

I'd like to first make sure that everything else works properly before blaming the kernel. Disabling the bridge would be last resort. I do not want to add an additional switch just to leave the other ports on my firewall unused.

Hi,
the problem seems to be solved for now. One more reboot after the update from 22.1 to 22.1.6 solved the issues with the vlans. ...interesting... :)

Bye
Robert.

Thanks Robert.
FYI me the problem persists after rebooting  ::)

I had a deeper look in the logs and noticed this message:

Code Select Expand

/usr/local/etc/rc.bootup: Warning! dhcpd_radvd_configure(auto) found no suitable IPv6 address on bridge0

When I look in 'Interfaces > Overview' I can see that there is a proper IPv6 address assigned. How is it not 'suitable'?
Are there any more logs that I can provide? Any way to enable more debug information?
How is radvd even being executed on OPNsense? I see it listed as a service on the web interface but running 'service -e' does not return radvd.

[meyergru]

Since the error occured in rc.bootup, I would think that at boot time, the WAN was not up, so that no IPv6 prefix was assigned at that time. I see that same message for multiple interfaces, but only at boot time.

[dinguz]

I am having similar issues with IPV6 intermittently not working as well. I was fiddling with some settings, and suddenly things started working again.
Not sure, but IIRC the last change was disabling 'Prevent interface removal' on all interfaces and reboot. Can anyone try if this makes a difference?