OPNsense Forum

I have this pair of firewalls and a link local address as a CARP VIP for my DMZ. Also the router advertisement service is enabled on that interface as "unmanaged", because I rely on SLAAC throughout. See screen shots for the CARP and RA configuration, please.

The CARP state looks good - one node is master, the other one backup for all addresses on all interfaces.

Unexpectedly my Ubuntu server in that DMZ receives and uses two default routes - and with the node link-local address instead of the CARP address as the gateway. Is this intentional?

::/0                           fe80::f690:eaff:fe00:6506  UGDAe 1024 9     0 eth0
::/0                           fe80::f690:eaff:fe00:6500  UGDAe 1024 1     0 eth0

The generated radvd.conf looks identical on both nodes:

# Generated RADVD config for manual assignment on opt2
interface vlan0.15 {
AdvSendAdvert on;
MinRtrAdvInterval 200;
MaxRtrAdvInterval 600;
AdvLinkMTU 1500;
AdvDefaultPreference medium;
prefix 2a00:b580:a000:4000::/64 {
DeprecatePrefix on;
AdvOnLink on;
AdvAutonomous on;
};
};

Shouldn't the configured CARP address as source appear somewhere in the config?

Kind regards and thanks in advance,
Patrick

Since I remember this used to work and I questioned the notion that another regression could have been introduced in the code after shaking out the last kinks with respect to link local CARP and HA some time in 20.x or 21.x versions I tried to figure out what I had changed in the configuration when I updated and overhauled the entire cluster.

So the CARP VIP does not make it into radvd.conf. From that point on the observed behaviour is to be expected. But why?

I looked at https://github.com/opnsense/core/blob/master/src/etc/inc/plugins.inc.d/dhcpd.inc

and then found the culprit.

I created the CARP VIPs with a /128 prefix length following the lead of IPv4 where /32 is recommended for all alias addresses (and seems to work well, no observed problems so far). When I changed the CARP VIP to /64 the radvd confguration changed to:

interface vlan0.15 {
AdvSendAdvert on;
MinRtrAdvInterval 200;
MaxRtrAdvInterval 600;
AdvLinkMTU 1500;
AdvDefaultPreference medium;
AdvRASrcAddress {
fe80::15;
};
AdvSourceLLAddress off;
RemoveAdvOnExit off;
prefix 2a00:b580:a000:4000::/64 {
DeprecatePrefix off;
AdvOnLink on;
AdvAutonomous on;
};
};

So operator error, although a little bit surprising, since I could select the VIP from the RA config form without any error or warning message.

Comments? Why does this line of code exist, i.e. why are /128 VIPs explicitly skipped? (line 254 ff. in the dhcpd.inc)

           if ($vip['interface'] != $dhcpv6if || !is_ipaddrv6($vip['subnet']) || $vip['subnet_bits'] == '128') {
                continue;
            }

For now I changed all link local CARP addresses to /64 while keeping the GUA ones at /128. They should not be the source of RA in my network, anyway.

And lo and behold! On the Ubuntu server:

::/0                           fe80::15                   UGDAe 1024 2     0 eth0

Kind regards,
Patrick

Hi Patrick,

I agree about the missing validation. Can you create a ticket?

In general radvd/SLAAC can only operate on /64 and will complain if not, but continue. We kept this due to not wanting to break people's setup.

The /128 exclusion is a special case when the VIP is supposed to be used for services listeners only and the actual /64 should not be advertised to clients.


Cheers,
Franco

Quote from: franco on December 13, 2024, 02:33:19 PMI agree about the missing validation. Can you create a ticket?

Sure - but one more question first ;)

Quote from: franco on December 13, 2024, 02:33:19 PMIn general radvd/SLAAC can only operate on /64 and will complain if not, but continue. We kept this due to not wanting to break people's setup.

The prefix advertised on the wire is of course a /64:
prefix 2a00:b580:a000:4000::/64
Only the VIP isn't. I assume although I have no quick way to test it (the cluster in question is in production) that the same radvd.conf cited above will work just fine even with a /128 VIP. That's only the default gateway, not the prefix.

What do you think?

/128 is ignored on purpose for radvd. /128 makes no assumptions about belonging to a particular network so radvd should not impose a larger subnet from the address to advertise. It would otherwise force the /128 to mean /64 which is not ideal.


Cheers,
Franco

But currently it ignores the setting based on the default GW VIP prefix length, not the length of the prefix it actually advertises. I did change the code to:
            if ($vip['interface'] != $dhcpv6if || !is_ipaddrv6($vip['subnet']) || (!is_linklocal($vip['subnet']) && $vip['subnet_bits'] == '128')) {
                continue;
            }

So link local VIPs with /128 are allowed. The generated config is still this:
# Generated RADVD config for manual assignment on opt2
interface vlan0.15 {
AdvSendAdvert on;
MinRtrAdvInterval 200;
MaxRtrAdvInterval 600;
AdvLinkMTU 1500;
AdvDefaultPreference medium;
AdvRASrcAddress {
fe80::15;
};
AdvSourceLLAddress off;
RemoveAdvOnExit off;
prefix 2a00:b580:a000:4000::/64 {
DeprecatePrefix off;
AdvOnLink on;
AdvAutonomous on;
};
};

And it works as expected.

Ok fair point. How about this? https://github.com/opnsense/core/commit/c7036be53c


Cheers,
Franco

Looks good and a bit cleaner than mine. What about the code starting at line 481 for "track interface" configured subnets? The logic seems to be a bit different and I admit I did not understand it right away ;)

That's the automatic code. It does not support CARP source address or any settings. Historically it has been its own code block.


Cheers,
Franco

Thanks a lot! I would have sent a merge request but you were quicker. Case closed.

Yes I'll get this into 24.7.11. Thanks for the report!


Cheers,
Franco

Hi,

can`t find "Router Advertisments" is this still valid in 24.7 / 25.1 ?

Regards

Tx

It's fixed since 24.7.11 as @franco wrote.