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

Add option to ignore virtual IPs for WebGUI and SSH #4541

Closed
wants to merge 1 commit into from

Conversation

fraenki
Copy link
Member

@fraenki fraenki commented Dec 22, 2020

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

  • It wastes three ports (i.e. 22, 80, 443) on any virtual IP (for the selected interfaces). They cannot be used for any other service or application.
  • It makes it easy to introduce a security risk. Just by adding another new virtual IP the firewall WebGUI/SSH may be exposed to insecure networks.

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.

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

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.

@fichtner
Copy link
Member

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. 😔

@fichtner
Copy link
Member

The best approach would still be bind to link local and use nat rules. Besides, SSH has a hard limit of 16 IPs anyway...

@fraenki
Copy link
Member Author

fraenki commented Dec 22, 2020

I wonder whatever happened to Management Port only configurations

What does this mean?

The best approach would still be bind to link local and use nat rules.

How could this be achieved?

@AdSchellevis
Copy link
Member

easy, add a loopback, bind to it and forward traffic to the loopback :)

@fraenki
Copy link
Member Author

fraenki commented Dec 22, 2020

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 :)

@mimugmail
Copy link
Member

But beware to never run pfctl -d ;)

@AdSchellevis
Copy link
Member

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).

@fraenki
Copy link
Member Author

fraenki commented Dec 22, 2020

you can always use the defaults and let the firewall do its work

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.

@fraenki
Copy link
Member Author

fraenki commented Dec 22, 2020

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 :)

@AdSchellevis
Copy link
Member

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.

@mimugmail
Copy link
Member

you can always use the defaults and let the firewall do its work

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.

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

@fraenki
Copy link
Member Author

fraenki commented Dec 22, 2020

On a Sophos UTM when you enable email protection it binds postfix to every listening IP, quite toxic for an external audit

...would be interesting to see the audit results when the management interface is exposed to 40 virtual IPs :D

@fraenki
Copy link
Member Author

fraenki commented Dec 22, 2020

To provide some more context, our team faced the following issue multiple times:

  • add a new CARP VIP to OPNsense
  • use this CARP VIP for a service (i.e. HAProxy)
  • everything is working as expected :)
  • now reboot OPNsense (to apply an update, etc.)
  • on reboot the WebGUI binds to the new CARP VIP
  • the service (HAProxy) fails to bind, because the address/port is already in use
  • the service/application is down and there is no quick way to fix it

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.)

@AdSchellevis
Copy link
Member

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).

@fraenki
Copy link
Member Author

fraenki commented Dec 28, 2020

superseded by #4554

@fraenki fraenki closed this Dec 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants