Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
2 tasks done
TymanLS opened this issue Jun 5, 2024 · 3 comments
Open
2 tasks done
Labels
support Community support

Comments

@TymanLS
Copy link

TymanLS commented Jun 5, 2024

Important notices

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

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 fichtner added the support Community support label Jun 6, 2024
@fichtner
Copy link
Member

fichtner commented Jun 6, 2024

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
Copy link
Author

TymanLS commented Jun 7, 2024

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
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
support Community support
Development

No branches or pull requests

2 participants