-
Notifications
You must be signed in to change notification settings - Fork 700
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
Comments
It's a complex setup, but there are options provided you only allow the ULAs to be statically configured.
Any of these two options will not advertise the ULA subnet to the clients through radvd. Cheers, |
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 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 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! |
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.
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.
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.
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, |
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. TheAdvManagedFlag
andAdvOtherConfigFlag
flags are specified for the interface as a whole, while theAdvOnLink
andAdvAutonomous
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.The text was updated successfully, but these errors were encountered: