-
Notifications
You must be signed in to change notification settings - Fork 693
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
Add option to ignore virtual IPs for WebGUI and SSH #4541
Conversation
@@ -4539,7 +4539,7 @@ function make_ipv6_64_address($prefix, $suffix) | |||
return implode(':', $prefix_array); | |||
} | |||
|
|||
function interfaces_addresses($interfaces, $as_subnet = false, $ifconfig_details = null) | |||
function interfaces_addresses($interfaces, $as_subnet = false, $ifconfig_details = null, $include_vips = true) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don‘t want to complicate this any more like projects used to. The caller should do the necessary post processing with the help of a return value.
I wonder whatever happened to Management Port only configurations when we started to add this time consuming feature. The management port would not have these over-complications but then people ask for VIP binding or Tag it a bug and it gets added eventually. The original issues with it still stand and this simply proves it. 😔 |
The best approach would still be bind to link local and use nat rules. Besides, SSH has a hard limit of 16 IPs anyway... |
What does this mean?
How could this be achieved? |
easy, add a loopback, bind to it and forward traffic to the loopback :) |
OK, I'll give it a try. But it's way more complicated than it should be. Setting the "management IP" of a security device shouldn't be so hard IMHO :) |
But beware to never run pfctl -d ;) |
well, you can always use the defaults and let the firewall do its work, no complication at all. which is likely what most vendors do, since changing addresses will complicate your life a lot (there's a reason why quite some network best practices refer to loopback interfaces to assure a predictable setup for your services). |
But the default setting has severe drawbacks. I haven't seen another device that uses the "bind *" approach. I just want full control over the IP address of the management interface. That's not too much to ask for. |
And there's no offense intended... I'm aware that the "bind *" approach dates back to the 2000s and was inherited from the other project and was not designed by the OPNsense team :) |
no office taken, let's agree to disagree here, if I install a linux distribution, ssh binds to all interfaces in quite a similar fashion. I'm pretty sure it's not an advised design pattern from the larger vendors to bind services to addresses which can change caused by different events. Let's assume all services bind to local addresses (worst case) and an addresses changes, it would practically mean you're rebooting the device on acceptance of a new lease. Some probably generate rules for you, either to reflect to the loopback interface or (when binding to *) filter the inbound traffic. Just my two cents, if we would have designed it we would seek for separation of concerns, which is practically impossible when using addresses from all over the place. |
On a Sophos UTM when you enable email protection it binds postfix to every listening IP, quite toxic for an external audit when there are hundreds if notification cause of a couple IP addresses |
...would be interesting to see the audit results when the management interface is exposed to 40 virtual IPs :D |
To provide some more context, our team faced the following issue multiple times:
Maybe this demonstrates our pain a little bit better: our team was working on a new service, but unexpectedly added the VIP to the WebGUI/SSH. This does not only happen to me, but also to my teammates. It is hard to predict what will happen next with the "bind *" config, especially when the (firewall) configuration gets more complex. Although I proposed a workaround that solves this specific issue, I don't like to have workarounds for every specific use-case, because it makes the code more complex. But I assume that a redesign (of the bind/listen functionality) is probably not viable at this point in time. Hence the proposed workaround... (Granted, this issue will never happen for home users or when OPNsense is used in small branch offices.) |
The problem is we're risking an uphill battle here, and there are ways to prevent this from happening given the tools already available, bind to loopbacks, choose specific outbound management ports (or vlans) use different ports for management, .... Every addition costs time and risks others asking for the opposite, complaining about the behaviour or toggles being unclear. Sometimes the easiest road is the one to take, we really are trying to prevent pushing everyones edge-case into a new toggle and complicating choices for the others. Sometimes it's better to explain (document) how existing features should be used and what to take into account when designing networks (to prevent pitfalls like these). |
superseded by #4554 |
The WebGUI and the SSH service on any OPNsense firewall listens either on all interfaces or only on the specified interfaces. However, in both cases it will listen on all interface IP addresses, including all virtual IP addresses (IP aliases, CARP).
On large deployments with many virtual IP addresses this behaviour has several drawbacks
While this may sound like a negligible issue at first glance, it causes headaches when working with 40+ CARP VIPs. I've already implemented so many workarounds for this limitation that the configuratin is starting to get really messy.
Granted, one may be able to prevent this issue if the network is designed with this OPNsense-specific limitation in mind. However, the reality is that most networks are designed for other network equipment and are only later migrated to OPNsense. The OPNsense firewall should be able to work in any environment. This limitation looks very artificial to me.
I do not propose to change the default setting. The default setting ensures that the WebGUI is reachable and that users don't easily lock themselves out. That's a good thing.
However, expert users really should be able to configure this behaviour. My proposal adds a new option "Enable Strict Binding", which will ignore all virtual IP addresses. I've also added a warning box to inform novice users about potential damage.