Allow Separate Prefix-Specific Router Advertisement Options on a Single Interface

[TymanLS]

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

Is your feature request related to a problem? Please describe.

I would like to preface this by saying that I am not a networking or IPv6 expert, but I want to use my learning experiences to help improve OPNsense. This problem came up during one of my experiments. I am on OPNsense version 24.1.8.

I have a LAN interface configured with IPv6 to track from WAN, but also configured with a static ULA address using a Virtual IP. The purpose is to allow the servers on this subnet to have a statically configured, stable ULA address used for internal access within my home network while also having a privacy-enabled SLAAC address for internet connectivity (e.g. to pull updates); my ISP may change my prefix at any time so using GUAs for the server addresses is not ideal, and I would strongly prefer to avoid using NPT/NAT.

I want all the ULAs on this network to be statically configured on the servers that need them, and client devices should not get a ULA address. However, both client devices and servers should get a SLAAC address; the clients can use its SLAAC-obtained GUA to connect to the static ULA of the servers, and both the clients and servers can use their SLAAC-obtained GUAs to access the internet. The purpose of this is to make firewall rules easier: a ULA address can automatically be assumed to be a server address.

In my Router Advertisement Settings, I have the mode set to "Unmanaged", which allows clients and servers to obtain an address through SLAAC from the delegated WAN prefix, but also allows clients and servers to obtain an address through SLAAC from the ULA prefix. Clients now have one GUA and one ULA, whereas servers now have one GUA and two ULAs (one static, one through SLAAC); the goal is for clients to only have one GUA, and servers to have one GUA and one ULA (static). The "Unmanaged" RA mode seems to be applied to all prefixes on the LAN interface, and there are no options in the UI to specify different prefix-specific router advertisement options for the two different prefixes.

Describe the solution you like

I would like the /services_router_advertisements.php page in the web interface to include options for specifying different prefix-specific options for different prefixes on the same interface.

Describe alternatives you considered

I have considered manually modifying the /var/etc/radvd.conf file on the system, but was dissuaded by the comments stating not to manually modify the file. If there is a valid way to specify these options outside of the UI, then I would love to hear it.

Additional context

The OPNsense documentation and manual page for radvd explains these configurations in further detail. The AdvManagedFlag and AdvOtherConfigFlag flags are specified for the interface as a whole, while the AdvOnLink and AdvAutonomous can be different depending on the prefix. This means some configurations would be invalid (e.g. having "Router Only" and "Managed" for two prefixes on the same interface), but others (e.g. "Router Only" and "Unmanaged" for two prefixes on the same interface) are valid configurations. I'm not sure of the best way to enforce these restrictions in the UI.

[fichtner]

It's a complex setup, but there are options provided you only allow the ULAs to be statically configured.

1. "Deny service binding" setting for the ULA VIP., or
2. Set the ULA VIP subnet mask to 128.

Any of these two options will not advertise the ULA subnet to the clients through radvd.

Cheers,
Franco

[TymanLS]

Thank you, that setting was able to solve my use case and it appears that the ULA addresses obtained through SLAAC have disappeared after restarting radvd.

I am still thinking that it could be useful to allow setting different per-prefix flags as described in the original post. In the scenario I originally described, I could simply disable binding to the radvd since my VIP was intended to follow the "Router Only" configuration, which doesn't set any relevant RA flags. However, I have also considered a similar use case where I distribute a GUA and ULA to my servers using DHCPv6, and distribute GUA only to client devices using DHCPv6. Some client devices like Android phones do not support DHCPv6, so I would need to set the delegated prefix as "Assisted" so those devices could still get a GUA through SLAAC; however, I want to prevent any possibility of ULAs being configured through SLAAC and would like to set the ULA prefix to "Managed" mode. In this scenario, setting the "Deny service binding" setting or changing the VIP subnet mask would disable RA rather than setting the correct mode.

I do not want to come across as confrontational by posing a different use case that renders your previous solution invalid, but as I learn more about IPv6 networking, I would like to understand the capabilities of OPNsense and try to help improve it to provide flexibility where I think it could be useful. Please let me know if the new scenario I described above makes sense as a use case to implement the per-prefix options in OPNsense. Thank you for your assistance!

[fichtner]

I could simply disable binding to the radvd since my VIP was intended to follow the "Router Only" configuration, which doesn't set any relevant RA flags.

We've discussed per-service binds before but they create more code and require every service to be patched and managed separately. The extension of VIPs makes this much easier to use and maintain.

I actually don't even know why prefixes are in the configuration in the cases where SLAAC is disabled. That seems odd, but it's always been this way. Are you sure clients still grab a prefix in router-only mode? It would mean the clients invalidate the RFC or radvd invalidates it by sending the prefixes, but that's whole lot of not adhering to standards that I would doubt it for now.

Some client devices like Android phones do not support DHCPv6, so I would need to set the delegated prefix as "Assisted" so those devices could still get a GUA through SLAAC.

Yes, Android phones omission of DHCPv6 clients has been a source of problems in the past. Unfortunately SLAAC has no filter mechanism so you cannot limit the scope of which client you want on which system. Effectively you'd have to separate the phones to a separate interface via APs or so... which in practice nobody does because it's too much network setup for too little benefit.

however, I want to prevent any possibility of ULAs being configured through SLAAC and would like to set the ULA prefix to "Managed" mode. In this scenario, setting the "Deny service binding" setting or changing the VIP subnet mask would disable RA rather than setting the correct mode.

I don't really understand this bit. Not having the prefix in the radvd.conf should do what you want here unless you talk about separation of ravd.conf for separate interfaces which are on top of a single interface which isn't how RAs work.

I do not want to come across as confrontational by posing a different use case that renders your previous solution invalid, but as I learn more about IPv6 networking, I would like to understand the capabilities of OPNsense and try to help improve it to provide flexibility where I think it could be useful. Please let me know if the new scenario I described above makes sense as a use case to implement the per-prefix options in OPNsense. Thank you for your assistance!

Don't worry. It's good to talk about these things and IPv6 always has room for improvements. We just need to come to a shared understanding first in order to work out what makes sense and what doesn't.

Cheers,
Franco

[OPNsense-bot]

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository,
please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue,
just let us know, so we can reopen the issue and assign an owner to it.